Vodia PBX

There is a setting "Explicitly list addresses for inbound traffic" (see http://vodia.com/documentation/trunk_settings) where you can tell the PBX where the inbound traffic comes from. You also need to set the outbound proxy (on the same page); then you should be able to send and receive calls.

This sounds like a compatibility problem with the agents phone. If it is reproducible, it should be easy to grab a PCAP for the call and look at the SIP traffic. Maybe you can do that for me and send me private message with a link to the PCAP, so that we can take a look.

Yea of course they don't need to be system admin, domain admin would be enough. But user will not be able to see it from their web interface. We need to check if we can recycle the existing audio prompts for this, it is quite a hassle to record them, in each language.

You can listen to them from the web interface; at least you don't have to "test" the prompts by dialing into auto attendant and so on.

Well we could work on allowing # also as non-special key. But the problem might go a lot deeper. If they just dial in, connect, hang up and repeat it (from a different DID) it will be really hard to turn them down. Is this what SPIT was all about? Ultimately it could become really hard to keep a toll-free number open, not only with our system but everywhere.

Well I would let them know about the problem even though it can be tedious to get to the right person there; what you can do is get a PCAP to see if there is anything that can be done on PBX side to get this working.

Hmm. So people deliberately keep the call up, just to tease you?! What you could do is to redirect the call into an IVR node e.g. when F is detected, where you can "kill" the all easily after a timeout. If you send the call to a mailbox, it will also eventually turn off the call, because the mailbox recording duration is usually max two minutes.

Is this a specific agent group (ACD) problem or do you have generally a problem transferring calls? Is this an attended call transfer or a blind transfer, or is it a call redirection when the call has not been connected yet?

Maybe it is that the provider has different software versions running on different servers. That would explain why it works with one domain and not with another. It is always something.

So the audio/no audio all happens on the same trunk? As the big carriers also start to migrate to VoIP they are also working on their RTP routing, with all sorts of SBC involved. It is actually a dynamic field, as those guys are also constantly working on their network.

In the "Banner" section there is a setting for that (available only on the hosted edition).

Looking at the RFC... The only thing I can think of right now is that the address must be in <>, but it seems that is the case in your log. Can you attach a TXT file, so that the message editor of the forum does not mingle it? Please make 100 % sure that there are no spaces, tabs or anything "invisible" in the account settings. That seems to be a problem.

Can you get a PCAP trace? Just to make sure that we see if there is any problem with the SIP messages and/or RTP. You never know. Also, does the same happen if you first call the auto attendant (then the call is technically connected) and from there call the extension?

Could be a problem with what you put into your from address. Is it in the form account@domain.com? You can also try "Name" <account@domain.com>. Maybe you can post here the exact FROM message (ok to change names, of course). Different email servers are more or less picky about the exact syntax.

Whow, thanks for sharing!

With the codec topic, of course we tried to have G.722 internally and G.711 outside. However the problem was the attended transfer: Call from A (trunk) comes in to B, B calls C, then transfers the call to C, where we ended up with transcoding... Ok we could try to re-invite and negotiate another codec and I even believe we do that. However what we have learned is that companies make their money with good sounding internal calls (who cares if the employees can talk high def ), what mostly counts is as-good-as impossible communication with clients. Transcoding between ulaw and alaw is loss-less, and it does not take much CPU; this is not a big problem. We included Australia simply because we have good business down there and want to make it possible to have the phone render Australian tones.

Well, this might get a little off topic, but the cert topic is a problem with most roll-outs. We were thinking about building our own little trust chain with the Vodia Root CA and providing certificates to PBX installations, at least for the hosted PBX installations. It would require that users have to add the Vodia Root CA to their trusted root list, but this way we could easily solve the problem. We might even convince some phone manufacturers to include the Root CA in the default list, making true plug and play and mutual authentication possible.

Actually I believe it would make sense to always go to port 443, as the user is about to enter sensitive information. OTOH the problem is that many PBX out there are not having valid certificates, so that WebView might not allow the connection.

In 5.3.1 there will be a flat for each stage where you can instruct the PBX to send a missed call to the phone or not. Default will be "not".

If we add a permission to edit the domain address book to the admin permission page, it will become quite complicated as that admin e.g. will also be able to edit the domain settings; things that you would probably not allow someone who is just maintaining the address book. I think it would be easier to have the user add the contacts and set a flag "visible in domain", so that everyone in the domain can see the contact (but not edit it).

The app is nothing else than a glorified version of the user portal running in a WebView on Android, with a few pages in the app itself, so that it can work. That means regarding ports you can treat the app just like a web browser.

Well we would have to add that. It might be an easier way to solve the problem than to work on granular permission control for what a domain administrator can do.

Thanks, this is excellent feedback. 1) yea it should really make it clear that the phone should not put that security warning on the screen. Anyway, 1x is enough. We'll change that. 2) The codec preference on the phone has only limited impact on what codec is actually selected. The PBX will always use it's own setting to determine the codec in the negotiation process. At the end of the day this helps keeping the SDP attachment shorter, which is important if the phone should use UDP where the MTU is typically 1492 bytes. The phones may propose more codecs, but the PBX does not support them. A side note on G722 and other high quality codecs: The problem is that most of the (important) calls eventually end up in the PSTN, where pcmu and pcma are still the prevalent codecs. When you use a G.722 codec to talk to the PSTN, it will eventually get transcoded down to G.711. Unfortunately every information transformation from one format to another reduces the quality of the call, the codecs can not "invent" information (at least not those codecs we are talking about here), that is why it is better to focus on G.711 as the primary codec and use high compressing codecs when bandwidth is a problem. We experienced this problem first hand when we happily started using G.722 and customers complained about damped call quality, which at first puzzled us but later when you think about it made sense. 3) Good catch, especially because the default on the phone goes very far across all sorts of countries. However it also means that PBX admins need to pay more attention to this setting. We'll add that. 4) The tones are those two digits after the "audio_" in the file system. By default it is USA if nothing else was found. Which one is missing? 5) The problem is that we need to "guess" if users should use 12 or 24 hour format and how they want the date. We could use the country code which works well for the rest of the world, the problem is Canada. Looking at https://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada it seems to be fine to use the same notation like in the US. So: <time_24_format perm="RW">{enum domain country_code on 1=off}</time_24_format> <date_us_format perm="RW">{enum domain country_code off 1=on}</date_us_format> 6) That problem is related. I think that <dialnumber_us_format perm="RW">{enum domain country_code off 1=on}</dialnumber_us_format> should properly solve that problem. It assumes that the admin set the country code.

So 5.3.0a should be available for all minis now.

Ok, so you want a user to set up address book entries that should be visible to the whole domain? If that is the question, you are right the admin has to do that. But it might be an interesting thought to have a flag for private entries to make them visible in the whole domain.