Vodia PBX

That should be fixed in the 2116 build. Try http://www.pbxnsip.com/download/pbxctrl-2.1.0.2116.exe.

Well, the redirection to Exchange essentially runs through the dial plan. That means you should not dial the mailbox prefix, but the prefix that you are using in the dial plan to redirect calls to Exchange.

Not yet. We need to talk to Polycom, they would have to add this feature to the firmware release.

I would recommend to use RFC3325 (P-Preferred-Identity) in any case. All the other "ways" are workarounds.

Well, the best solution in this case is probably to use the manual update in http://wiki.pbxnsip.com/index.php/Installi...#Manual_Upgrade. That should work independently from the InstallShield updates.

Okay there is a 2116 version (http://www.pbxnsip.com/download/pbxctrl-2.1.0.2116.exe), and we did a small change in the 0.0.0.0 detection, but we had no chance of trying it out. Please give it a try.

Unfortunately, we have only a 57i here... Interestingly, this one uses 0.0.0.0 and a=sendonly in the same SDP.

I don't think it is the Replaces. I looked at the SDP, but they all contain the out of band codec. It is wierd.

Oh, okay. Simple patterns might not be suitable here. I you use the ERE pattern 8([0-9]{7})@.* and the replacement 1914\1@\r;user=phone then it should work. ERE are not beautiful, but powerful ;-)

Well, the Replaces header tells the "other side" what call to drop as a replacement for the new call (initiated by the REFER). Because everything is happening inside the PBX, that logic is programmed without really initiating another call. Doe the replaced Call-ID exist on the PBX? If not, the PBX should log the message "Replaces: Call-ID xxx not found" on log level 5.

Yes. Other vendors are welcome to join the team of easy and fast button updates!

Did you see the stuff on the Wiki? http://wiki.pbxnsip.com/index.php/Microsoft_Exchange Did it touch that topic. 2.1 has a new setting called "Assume that call comes from user" that is not covered by the Wiki page. It tells the PBX what account to charge if Exchange wants to initiate an outbound call from the trunk.

Why don't you use 8* as pattern?

Hmm. Maybe it is easier to program around it and support that old style as well.

PCMU, PCMA == G.711 ... If you continue to have problems, it makes sense to run Wireshark in the network to identify the problem.

Yea for internal calls that should be okay. It is all about expectations!

Well, this is a long story. I think we can say that we tried almost everything, and the above PPT is the gist of it. One bottom line is: Don't just get a cheap DSL and think that you are all set.

Oh yea, they are using the 0.0.0.0. I am not sure if we should still support this more than 5 years old "workaround" - isn't there a SW upgrade for the phone available?

Indeed. Workaround is to add another pattern +* with replacement also +*. Will be fixed in the next 2.1 build.

Do you have the SIP INVITE that tells the PBX to hold the call? Maybe the phone is using the old style with 0.0.0.0 (which was obsoleted in June 2002, see RFC 3264)?

Well, what you can do already is use SOAP to set the state. If that's an option, we can work out the details. But it makes sense to control that flag also from the web interface. The next version (2.2) will have it.

Version 7.1.23 also does that, and this version is available as beta from the snom web server. If you are using 2.1.0.2115 then PnP should be working smoothly. For example, you find the snom firmware here (it is not so easy to find on the snom Wiki): http://fox.snom.com/download/snom300-7.1.24-SIP-f.bin http://fox.snom.com/download/snom320-7.1.24-SIP-f.bin http://fox.snom.com/download/snom360-7.1.24-SIP-f.bin http://fox.snom.com/download/snom370-7.1.24-SIP-f.bin If you need to upgrade from version 6, see the descriptions on http://wiki.pbxnsip.com/index.php/Snom.

There are plenty of gateways available, for example: AudioCodes Grandstream Ericsson Patton Parlay Mediatrix Teles Vegastream

Works here, using PBX 2.1.0.2115 and Aastra 57i/2.0.1.2000 Brcm-Callctrl/v1.7.2.2 MxSF/v3.6.2.5. Maybe you need to upgrade the PBX to the 2115 build.

Could it be that the SIP packet goes to the default IP gateway of the PBX? Seems there could be a problem.