phsean

to the demo key comment. I was interested in seeing the new version layout anyway, so I loaded up my machine with 3.0.1, registered a phone, started up wireshark, and waited for the cutoff... which never came. I'm running the same version bootrom.ld and sip.ld (now 2.2.2) on the Polycom, same config files, and the trunk settings are the same on both the Quintum and PBXnSIP. Maybe something changed in the way that PBXnSIP handles the trunk somewhere between pbxnsip version 2.1.10 and 3.0.1 (most likely an understatement). I'm interested to load our production server with the new version and see what happens. Thank you!

You are right. We put 2.2.2 on the polycom and had the same result. But when we called extension to extension and put the phones on mute, we ticked above three minutes of silence without an issue. Next step seems to be to load a test box with pbxnsip so that we can do a wireshark trace on an isolated call and see what is being sent between pbxnsip and the quintum pstn equipment.

Wireshark: http://dtl.pharmacarepc.com/~skline/pbxnsip2.pcap

(not sure of the nomenclature. I think that this constitutes Plug n Play) What we do to provision a phone: Add MAC to a new extension in PBXnSIP. On Polycom: Server Type is TFTP and the Server Address is <pbxnsip dns> Then we have the generic config files in the html directory of pbxnsip that pbxnsip translates into configs for each phone (copies stored in generated directory). I will work on getting a wireshark trace together as well.

I do see an RTP Timeout in the logfile viewer when the call is cutoff: [5] 2008/10/03 09:36:23: RTP Timeout on 9336d5f6@pbx#29825 here's another: [5] 2008/10/03 09:44:03: RTP Timeout on 05a67596@pbx#6807 I just configured e-mail on the logging page, but it doesn't want to send me the RTP notification timeout via e-mail via either my Exchange or Exim mail server. Maybe I have something configured incorrectly (but the same settings in the domain CDR section work for sending a CDR report), or maybe it's something with pbxnsip 2.1.10.2474. But that RTP Timeout you refer to is there in the logfile viewer.

Our current Polycom SIP version is 2.1.0.2708, the bootrom version is 3.2.2.0019. This is bringing back memories... I tried to upgrade the SIP application about 6-8 months ago without a lot of luck because we do have a few customizations in there, too. I ended up giving in. Kristan, if you wouldn't mind sending me your config files, I could use WinMerge to compare them to the stock ones and see what you did to get it to work and start from there, that would be very helpful. An e-mail address that'll reach me is registrant -at- 3ipc -dot- com. Thank you both - now it's down the rabbit hole...

It seems to us that outgoing calls that are silent for two minutes at a time are being cutoff. forum wisdom seems to think that this can be resolved by turning off silence suppression, but as far as I can tell it's already set that way (for the handset, which is the issue). The polycom_sip.xml in my html directory reads: <NS voice.ns.hs.enable="0" voice.ns.hs.signalAttn="-6" voice.ns.hs.silenceAttn="-9" voice.ns.hd.enable="0" voice.ns.hd.signalAttn="0" voice.ns.hd.silenceAttn="0" voice.ns.hf.enable="1" voice.ns.hf.signalAttn="-6" voice.ns.hf.silenceAttn="-9" voice.ns.hf.IP_4000.enable="1" voice.ns.hf.IP_4000.signalAttn="-6" voice.ns.hf.IP_4000.silenceAttn="-9"/> We're a health care organization and I'm in IT -- not a good combination for trying to avoid being on hold. Would appreciate a solution, thanks! We're using Polycom IP 430's on version 2.1.10.2474.

Thanks, Paul, that's good info to have. SP1 has definitely put us in a pickle; wish it were uninstallable. Thanks for the reply, as you find out more, let me know, our Exchange Gold trial server that we have been using to get by expires in 35 days. If we don't know more soon, my only hope is that the Gold server takes the license key for our already-in-place server without complaining. Otherwise we'll have to try something else out (a second temporary x64 server with another trial?)

PbxnSIP, do you have any additional info regarding the Exchange integration issue above? Paul, I left you a voice message earlier this week to find out whether or not you had exchange sp1 working on your test boxes but haven't heard back. Can you call, e-mail, or post here with a reply? Thanks.

Hmm... looking at the logs, sorry, but I don't understand what 6xx code it is that you are referring to. That shouldn't have changed unless the phones were provisioned differently, though, correct? They are not. In case my wording was confusing, let me reword what's happening: On 2.1.6 and Exch sp1: - If I call 5001 from 5000 directly, it goes to voicemail after 5 secs as config'd. Good. - If I call 5001 from 5000 directly and press reject on 5001 before the auto timeout to voicemail, it plays 'extension is busy, press 2 to leave a message'. Also Good. - If I call 78564 (Exch AA), press 1 to transfer to 5001, it transfers to 5001 (with the above ERE in the dial plan), but rings forever instead of going to voicemail after 5 secs. Bad - If (while ringing forever), I press reject on 5001 to force the call to voicemail, the 'this number could not be found' plays. Also Bad. On 2.1.2 and Exch (no sp1): - Good stuff above works as expected. - If I call 78564 (Exch AA), press 1 to transfer to 2504, it transfers to 2504 (without ERE), rings the correct number of times, then times out to voicemail. Good!

Thanks, pbxnsip. Adding the following line to the dialplan allowed Exchange to call the extension: Call Extension - (your ERE) - \1 However, the call from the AA to the extension rings forever instead of being transferred to voicemail. Hitting reject on the Polycom phone should force the caller to voicemail (as it does on an extension to extension call, and as it does on our other test server coming from the AA), but instead gives the caller the audio_en/ex_wrong_id.wav 'this number could not be found'. Is there more to this internally than can be fixed via the dialplan? The log files show the DECLINE from 5000 to 78564, the ACK from 5000 to 78564, then the number not found message -- no dialplan matching attempts.

I have a PBXnSIP UM problem that seems to be caused by Exchange SP1... but it might be a 2.1.6 thing. The problem seems to be in the REFER coming back from the Exchange Server. Scenario: Extension (2412 & 5000, respectively) calls Exchange Auto Attendant (8564), presses 1, transfers back to PBXnSIP extension (2504 and 5001, respectively). Right now we have two systems that we are using to figure out what exactly is going on: 1. PBXnSIP 2.1.6.2446 with a trunk to Exchange SP1 server (testing) 2. PBXnSIP 2.1.2.2292 with a trunk to Exchange without SP1 (production) On the SP1 Server, the REFER-TO line is: REFER-TO: <sip:5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com@192.168.11.4;user=phone> On the Exchange Server (no SP1), the REFER-TO line is: REFER-TO: <sip:2504@192.168.11.4:3848;transport=tcp;user=phone> Where the 'PBXnSIP-exchangesp1.ourdomain.com' is the Exchange dialplan associated with the PBXnSIP 2.1.6 gateway and '192.168.11.4' is our mailbox server. If you look at the UM properties of a user in Exchange, both users 5001 and 2504 have the phone-context listed. Is anyone else aware of this issue or what might be done to fix it? --- Call logs below --- --- PBXnSIP 2.1.2 to Exchange w/o SP1 REFER sip:2412@192.168.11.4:3848;transport=tcp SIP/2.0 FROM: <sip:8564@192.168.11.7;user=phone>;epid=25-50-99-AE-EF;tag=741759d2a0 TO: <sip:2412@192.168.11.7>;tag=22099 CSEQ: 1 REFER CALL-ID: 0a45efff@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.7:5065;branch=z9hG4bK879ddf92 CONTACT: <sip:exchange.ourdomain.com:5065;transport=Tcp;maddr=192.168.11.7> CONTENT-LENGTH: 0 REFER-TO: <sip:2504@192.168.11.4:3848;transport=tcp;user=phone> USER-AGENT: RTCC/2.0.6017.0 Referred-By: sip:8564@192.168.11.7;user=phone [9] 2008/02/20 14:56:36: Resolve destination 144704: tcp 192.168.11.7 5065 [7] 2008/02/20 14:56:36: SIP Tx tcp:192.168.11.7:5065: SIP/2.0 202 Accepted Via: SIP/2.0/TCP 192.168.11.7:5065;branch=z9hG4bK879ddf92 From: <sip:8564@192.168.11.7;user=phone>;epid=25-50-99-AE-EF;tag=741759d2a0 To: <sip:2412@192.168.11.7>;tag=22099 Call-ID: 0a45efff@pbx CSeq: 1 REFER Contact: <sip:2412@192.168.11.4:3848;transport=tcp> User-Agent: pbxnsip-PBX/2.1.2.2292 Content-Length: 0 [5] 2008/02/20 14:56:36: Redirecting call to 2504 [7] 2008/02/20 14:56:36: Calling extension 2504 --- --- PBXnSIP 2.1.6 to Exchange SP1 REFER sip:5000@192.168.11.13:4510;transport=tcp SIP/2.0 FROM: <sip:8564@192.168.11.4;user=phone>;epid=4BA968830A;tag=da77a4c889 TO: <sip:5000@192.168.11.4>;tag=50275 CSEQ: 1 REFER CALL-ID: 4a853a28@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK16cbdb5f CONTACT: <sip:exchangesp1.ourdomain.com:5065;transport=Tcp;maddr=192.168.11.4;ms-opaque=fd2ca9a11a23831e>;automata CONTENT-LENGTH: 0 REFER-TO: <sip:5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com@192.168.11.4;user=phone> REFERRED-BY: <sip:8564@192.168.11.4;user=phone> USER-AGENT: RTCC/3.0.0.0 [9] 2008/02/20 15:02:51: Resolve 36489: tcp 192.168.11.4 5065 [7] 2008/02/20 15:02:51: SIP Tx tcp:192.168.11.4:5065: SIP/2.0 202 Accepted Via: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK16cbdb5f From: <sip:8564@192.168.11.4;user=phone>;epid=4BA968830A;tag=da77a4c889 To: <sip:5000@192.168.11.4>;tag=50275 Call-ID: 4a853a28@pbx CSeq: 1 REFER Contact: <sip:5000@192.168.11.13:4510;transport=tcp> User-Agent: pbxnsip-PBX/2.1.6.2446 Content-Length: 0 [5] 2008/02/20 15:02:51: Redirecting call to 5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com [9] 2008/02/20 15:02:51: Dialplan: Evaluating !^5([0-9]*)@.*!5*!i against 5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com@192.168.11.4 [9] 2008/02/20 15:02:51: Resolve 36490: aaaa tcp 192.168.11.4 5065 [9] 2008/02/20 15:02:51: Resolve 36490: a tcp 192.168.11.4 5065 [9] 2008/02/20 15:02:51: Resolve 36490: tcp 192.168.11.4 5065 [7] 2008/02/20 15:02:51: SIP Tx tcp:192.168.11.4:5065: BYE sip:exchangesp1.ourdomain.com:5065;transport=Tcp;maddr=192.168.11.4 SIP/2.0 Via: SIP/2.0/TCP 192.168.11.13:4510;branch=z9hG4bK-d05437562f4762e6c579cb1bbd0c5a45;rport From: "Extension 5000" <sip:5000@192.168.11.4>;tag=50275 To: <sip:8564@192.168.11.4;user=phone>;tag=da77a4c889 Call-ID: 4a853a28@pbx CSeq: 10137 BYE Max-Forwards: 70 Contact: <sip:5000@192.168.11.13:4510;transport=tcp> RTP-RxStat: Dur=8,Pkt=187,Oct=32164,Underun=0 RTP-TxStat: Dur=7,Pkt=342,Oct=57108 P-Asserted-Identity: "Extension 5000" <sip:5000@pbxnsip216.ourdomain.com> Content-Length: 0 [9] 2008/02/20 15:02:51: Dialplan: Evaluating !^7([0-9]*)@.*!sip:\1@\r;user=phone!i against 5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com@192.168.11.4 [8] 2008/02/20 15:02:51: Play audio_en/ex_permission.wav ---

Haven't done it (we use star codes to park), but if the phone park softbutton is what you're using to park a call and it's config'd to always park a call at a hardcoded orbit #, then I could see you getting an error message if it tried to park two calls on the same orbit.

Pbxnsip: Sorry to nag, but is there a "stock" pbxnsip version of the Polycom 2.2.0 config files? Thanks!

Wish I had one. The User and Admin guides for SIP 3.0 that I see are here: http://www.polycom.com/usa/en/support/voic...oint_ip430.html

How about that... I see the user and admin's guide, but not any release notes on their main support pages; I wonder what's new.

Would someone be able to point me to an authoritative pbxnsip version of the polycom 2.2.2 config xml files? I don't see the files anywhere in the full 2.1.5 version, and will need to merge our custom settings into them before we can go live with the new support. Thanks! (Last time they were hidden in a forum beta full-build, but I don't see one for 2.1.5 -- looks like Kristan obtained them somehow -- always a step or two ahead of me )

Wow, this forum's been hopping. I've been away from it for a bit. I'm excited to try out the new version -- as soon as things slow down here, we'll put it on our test server and try out some Polycoms on 2.2.2. Thanks!

My posting may have been premature, I apologize -- as it turns out the wireless bridge wasn't as optimized as it could have been. Made the changes last night; we'll take some time and see how the phones behave.

Seems like latency issues between the phones and the server. For example, they tell me that they'll pick up a handset on a ringing phone and it will continue to ring for a few seconds before the caller is connected. We have two locations about 200 feet apart connected using a wireless bridge using the same PBXnSIP server. Most of the complaints are indeed coming from the folks across the wireless bridge, but the ping times are consistently great - 1 and 2 ms, even under load. We currently have a call into them to make sure that the bridge is setup optimally.

We're starting to get a higher frequency of varying complaints from users with performance issues, etc. Just wanted to check and see if there was any news on the status of the 2.2 SIP Application Polycom config files? I'd like to be current before we go chasing down performance-enhancing bugs (not to be confused with performance-enhancing drugs). Thanks...

There appears to be something prohibitive with running pbxnsip and Exchange SP1 UM on the same server. Using a separate demo system, I can get right to the Exchange server when creating everything in the GUI. Then I moved it to a port besides 5060 (as it is on the Exchange server) and did a Set-UMIPgateway and it still worked just fine. Just to triple check, I created another brand new Dial Plan, Gateway, UM Server Association, etc. for the PBXnSIP installation on our Exchange server. Still no dice. Our own best solution is probably to move PBXnSIP off the Exchange server permanently -- we had originally put it there so that all the phone stuff would be localized (one point of failure). So much for that line of reasoning, eh? Looking around the web, I found someone else running a Cisco phone system that had to delete/redo their entire UM setup after a Exchange SP1 install, so it looks like there's something to that as well. So if you're going to install Exchange SP1, allot yourself some time to redo your UM setup -- you may need it.

Jonas, Thanks for the link -- I gave it another shot, but still have the same issue. I don't remember specifying pilot identifiers on either the gateway to the alternate server or the original server, but I'm doing some reading there as well. I'm going to fire up a demo PBXnSIP server on separate machine and see what happens from there, maybe there's a bug in SP1 related to the phone system and UM running on the same server. Unless yours are on the same server too...

Hi Paul, Nice to hear from you. Here are PBXnSIP log files of the issue: Exchange Post SP1 Exchange RTM Hi Jonas, Thanks. After seeing your post I tried that as well without success. But I'm glad that it's working for you. -- More info: a warning that is showing in the Windows Server Event Log for each call that fails is: Cannot find a valid UM IPGateway for <pbx server ip>. A UM IPGateway must exist for <pbx server ip> and must be linked to the UM Server via a UM DialPlan/UM HuntGroup. An MS support engineer is taking a look at the problem as well -- I'll post his insight as I get it.

Redid the AA's and changed user mailboxes to the secondary server's dial plan. Not too bad, actually... now everything is hot to trot going through the UM role on the secondary server. Short-term crisis averted. We'll still need to be back using the UM role on the primary server before the role from the secondary server expires. I've sent a message to Microsoft Support as well asking them if they can help point to the problem.