Vodia PBX

Two things come to my mind. First, you can assign a list of DID numbers to each account (e.g. "tel:2121234567 tel:2121234568"). This may help you to assign several DID to one account. Second, there is a setting called "Change names in To/From-headers" in the domain settings. By default it is on, maybe you want to change it to off.

2.1.6 already has a setting called "cdr_email_size" (invisible global setting in pbx.xml) - see http://wiki.pbxnsip.com/index.php/Global_Configuration_File. Check out http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2441.exe if you like.

Nope. The supported header does not include the magic word "from-change". See http://www.ietf.org/rfc/rfc4916.txt.

CDR is probably a topic that we address in a new way in a 2.2 version. There are a lot of problems with transfers and call segments. We probably have to dive it much deeper than we do today, and then re-assemble the pieces into something human readable so that Joe A is able to read the CDR report.

That seems to be the problem. Are you using an outbound proxy on the trunk? This outbound trunk must also resolve to the "inbound" trunk - the PBX needs to IP address of the trunk to determine that the calls is supposed to come from that trunk.

One thing is clear - you need to use a port range for RTP, not just one port. Typically devices use thousands of ports for RTP just to make sure they are random "enough". I personally agree with your frustration with ICS. I also tried some time ago and did not get anything working...

Check out you default gateway. If you set a default gateway in the LAN then it will be used. What does your /etc/network/interfaces file look like?

Well the problem is probably here that the Re-INVITE is killing it. RFC 4916 makes sense, but it is not supported by the phone. See http://wiki.pbxnsip.com/index.php/Indicati...ge_of_Caller-ID.

Ehh that DTMF level feature was added in 2.1.5...

We have an internal discussion on this. After a attended transfer it is not clear what duration should be shown. It could be that we change the currently policy and show only the duration after the attended transfer. It seems that this is what the good old systems were doing.

I recently had a disussion with a very large carrier and a guy that really understands SIP and the whole VoIP story. DTMF is one of their biggest problems, and the only common denominator is inband. "Transcoding" DTMF is very very difficult, if not impossible. That is the sad truth and we should not hit too hard on the service providers, they really have a difficult position.

At the moment the only thing I can think about is using curl or SOAP. Maybe we need a setting "use default of the domain" and have it changeable in the domain.

On log level 9 (media) there is a way to see what the inband DTMF detector is doing. You can use this to see if there s a problem with the power levels for DTMF. You should see something like "DTMF: Power: 122 34 322 343 535 345".

Well, this provider must support T.38 - otherwise the whole discussion is quite theoretical. This is the first thing to check.

No we are still struggling with other bulls*** like callback.

Yea, the IVR prompts are not there yet - but the Wiki is correct: http://wiki.pbxnsip.com/index.php/Mailbox#...opying_Messages

Yea, sorry typo. I know that for example AudioCodes, Vegastream, Mediatrix and also newer versions of Grandstream work with T.38. I think also Cisco Gateways support it. If you are looking for a sofphone that supports FAX (!) look at Zoiper. Did I forget a vendor?

Check out http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses for thus ugly topic. Can't wait until we have IPv6 rolled out, then there is no more need for this kind of address recycling!

The best way to track this problem down is to use Wireshark and record a conversation. Typically, those kind of problems are because of NAT or firewalls. Also silence suppression can be a problem. A wireshark trace will show it. More information can be found in http://wiki.pbxnsip.com/index.php/One-way_Audio.

Set the outbound proxy of the trunk to your service providers address. The outbound proxy on the phone should point to the PBX address. And BTW you better upgrade those phones to 7.1.30, otherwise you will experience problems with SRTP. You better include the logs from the PBX, not from the phone - then it is easier to see the PBX perspective!

For this, you should take a look at the buttons (http://wiki.pbxnsip.com/index.php/Assigning_Buttons). Should be an easy thing to do.

For those who can give the latest and the greatest a shot: http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2437.exe

That is caused by the fact that many devices cannot deal properly with multiple codecs in the SDP answer. 2.1.6 should improve this (if not fix this).

I would set an outbound proxy on the trunk. Also, if you change the IP configuration, you should restart the service (just to be sure). If it does not help, turn SIP logging on and see what the PBX tries to send out.

Are you sure? If should read out the two new messages (in "historical" order), then the 10 saved messages ("in historical order"). If you have a lot of messages, then the historical might be an issue because you have to go through all of the messages before you get to the latest, but IHMO that is okay because as a policy.