Model12

I finally took the time to merge our changes and we just implemented ... So far so good. Thanks!

Here's what I think will help out alot: If someone at PBXnSIP could provide me with the latest polycom_sip.xml file that matches up better than my current version ... Then we can "sync" our couple changes with your version. Afterwhich ... I think we can eliminate the dialplans.xml file by hardcoding this value in the new polycom_sip.xml file ... Truthfully ... I don't see a problem with replacing your parameter with a hardcoded value for our phones dialplan. All that should be left behind in the html dir is the polycom_sip.xml file used to provision phones. This should make future updates much much easier because we're not messing with any of the underlying PBXnSIP goodies. Make sense?

Wow! Of course I didn't make that file ... so ... I have no idea if there are newer "replacement variables" added/changed/deleted. Is there any way you could be so kind as to point me to the latest polycom_sip.xml version that PBXnSIP is utilizing? Right on! PS: Thanks much!

Ok ... here's what I did ... I noticed that lang_en.xml referenced a file named timeszones.xml ... so ... I made one of those in the html directory as follows: <?xml version="1.0" encoding="utf-8"?> <timezones dict="timezones.xml"> <zone name="EDT"> <description>Eastern Time Zone</description> <gmt_offset>-14400</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>4</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>1</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>10</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>Last</dst_stop_week_of_month> </zone> </timezones> After restarting the server ... only two timezones showed up in the web interface GMT and the one above. But ... the phones would not stop reading GMT time. So ... I hacked the polycom_sip.xml file by taking out the following params: tcpIpApp.sntp.address="{TZ NTP-Adr}" tcpIpApp.sntp.gmtOffset="{TZ GMT-Offset}" tcpIpApp.sntp.daylightSavings.enable="{TZ DST-Enable}" And hardcodding them to the following (please hold you're boo's until later): tcpIpApp.sntp.address="pool.ntp.org" tcpIpApp.sntp.gmtOffset="-18000" tcpIpApp.sntp.daylightSavings.enable="1" This worked ... So ... the only answer I have is that possibly the {TZ NTP-Adr}, {TZ GMT-Offset} and {TZ DST-Enable} are no longer the correct replacement params? Any idea what the heck I'm saying?

I also edited the dialplan.xml file to give the polycom phone a different dial plan as follows: [2-6]xxx|7xxxx|[2-9]11|91xxxxxxxxxx|9[2-9]xxxxxxxxx|*xx[2-6]xxx|xx.# Basically ... just so they don't have to press send. So ... I don't think I can drop the dialplan.xml file until I'm smart enough to know how to put that into the phone so they can be lazy ... {;-) Currently ... here's what's in the html directory: polycom_sip.xml - I've modified a few settings to persist volume and what not ... dialplans.xml - As stated above this was given to us to facilitate 4 digit plans but I also changed the default vendor pattern lang_de.xml - prolly not needed since we're silly American's (we can't help it) I had the lang_en.xml file but had to rename that so that the web interface would draw. The by product of that was the phones now read GMT time even though in the System Settings it says Eastern Time Zone. Right now the phones should say 4:00pm'ish but they show 8:00pm'ish.

I said something wrong in the above post and then realized I could edit the post ...

The files we have in that directory also included: lang_en.xml lang_de.xml But we didn't modify those ourselves ... <edit> With the lang_en.xml file in the html dir the web interface won't work correctly with version 2.1 Without it the web interface looks fine but the time is off on the phones. <end edit> But ... with that file removed then phones display an incorrect time. I think that file was given because of the following entry: <file name="dialplans.xml"> <item id="domdef">Domain Default</item> <item id="enter">User must press enter</item> <item id="usa4">North America (4-digit extensions [2-7]xxx)</item> <item id="usa3">North America (3-digit extensions [2-7]xx)</item> <item id="usa2">North America (2-digit extensions [2-7]x)</item> <item id="europe4">Europe (4-digit extensions [2-7]xxx)</item> <item id="europe3">Europe (3-digit extensions [2-7]xx)</item> <item id="europe2">Europe (2-digit extensions [2-7]x)</item> </file> Some nice fella at PBXnSIP gave us an option in our dialplan.xml file for a 4 digit ext which is great cause that is what everyone was familiar with. Any ideas what we should do ... is there a "newer" lang_en.xml file for the 2.1 version that we could use to incorporate the 4 digit dialplan we need or do you simply think that clearing th browser cache and reinserting this file would work? PS: Thanks sssooo much for the help!

I guess what I'm asking is this: To merge content ... I'd expect to be able to find a file such as: dialplans.xml in the new 2.1 version. Compare the differences between my PBX\html\dialplans.xml and begin to fixup differences ... after making a backup ... {;-) Is it just that simple? I cannot find these xml files on the 2.0 version ... Are they simply embedded in code but now seperated as independant files in 2.1?

The only thing we utilize in the html directory is the dialplans.xml file and we've changed one or two setting in the polycom_sip.xml file. I would love to merge content but all I can do at the moment is replace the 2.0 exe with the 2.1 exe. Is there a 2.1 "installer" that will give me all the new content so that I can find the xml files and merge some of the diff? Thanks!

When we drop in the new version exe (no real installation) ... the webpages no longer draw correctly. We can't admin the box anymore cause there is little to click on. What is the correct way to upgrade from v2.0? (sorry for such a simple question) PS: We have an "aftermarket" html directory added to our 2.0 install for a 4 digit North American dialplan. Maybe that is mucking something up with the webserver?

We have the same problem and it is hurting us. The call park blackhole has caused our users to start using HOLD instead. But ... after 2 minutes and 2 seconds the call is dropped. I thought they were crazy ... but ... we tried it ourselves and blame ... no more caller. We're using Polycom 430s and only one release down from the latest PBXnSIP ... We'd be on the latest greatest but for some reason when we drop in the newest exe the webpages in PBXnSIP don't draw correctly. Any idea how to stop a caller from being disco'd while on hold for 2 minutes?

Maybe this is a premature post but I'm ssoo happy I wanted to share. Paul from PBXnSIP was nice enough to help me along by comparing logs and setup. After making everything equal ... it worked! So then we began to back off little by little to the config we were originally running. Right now ... I'm placing the "blame" on the Domain setting in PBXnSIP. I changed ours from the default "localhost" setting because for some reason our Polycom phones would not provision correctly. Setting that to a FQDN that the phones could resolve to the PBXnSIP server seemed to make that problem go away. But ... changing that back to localhost made Exchange transfers to an ext# work ... hooray! So we left the Domain setting in PBXnSIP as a FQDN and added a localhost alias and it still works ... hooray^2!

This looks like a similar problem from a fella using SIPX: http://forums.microsoft.com/TechNet/ShowPo...7&SiteID=17 I'm not quite sure if this is "my same problem". If so ... then this is good info for someone smarter than myself!

Here's a brand new log file with all current changes: The 301xxxxxxx is my home phone calling work ... I blanked it out for obvious reasons. Here's the line on down in the log that makes me think I'm so close: /* snippet [5] 2007/07/08 14:47:18: Redirecting call to 2502 */ That's where I wanna go ... I'm trying to transfer back to 2502. And if I try a transfer to another person their ext# shows up instead of mine. So ... PBXnSIP knows where I'm trying to get to ... but ... for some reason I always get ex_permission.wav ... PS: Sorry for the long posts but this is the call from start to finish as Exchange UM performs the REFER. [7] 2007/07/08 14:47:18: SIP Rx tcp:192.168.11.4:5065: REFER sip:301xxxxxxx@192.168.11.5:5060;transport=tcp SIP/2.0 FROM: <sip:2424@apollo.test.com;user=phone>;epid=46-F6-C5-D5-61;tag=5941401e1e TO: <sip:301xxxxxxx@apollo.test.com>;tag=24016 CSEQ: 1 REFER CALL-ID: e09cfa91@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK42702096 CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4> CONTENT-LENGTH: 0 REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone> USER-AGENT: RTCC/2.0.6017.0 Referred-By: sip:2424@apollo.test.com;user=phone [8] 2007/07/08 14:47:18: Resolve destination 98700: tcp 192.168.11.4 5065 [8] 2007/07/08 14:47:18: Send Packet 202 [7] 2007/07/08 14:47:18: SIP Tx tcp:192.168.11.4:5065: SIP/2.0 202 Accepted Via: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK42702096 From: <sip:2424@apollo.test.com;user=phone>;epid=46-F6-C5-D5-61;tag=5941401e1e To: <sip:301xxxxxxx@apollo.test.com>;tag=24016 Call-ID: e09cfa91@pbx CSeq: 1 REFER Contact: <sip:301xxxxxxx@192.168.11.5:5060;transport=tcp> User-Agent: pbxnsip-PBX/2.0.3.1715 Content-Length: 0 [5] 2007/07/08 14:47:18: Redirecting call to 2502 [8] 2007/07/08 14:47:18: Resolve destination 98701: a Tcp 192.168.11.4 5065 [8] 2007/07/08 14:47:18: Resolve destination 98701: Tcp 192.168.11.4 5065 [8] 2007/07/08 14:47:18: Send Packet BYE [7] 2007/07/08 14:47:18: SIP Tx tcp:192.168.11.4:5065: BYE sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4 SIP/2.0 Via: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-828172d8ed8622060a8fb41c6091c805;rport From: "301xxxxxxx" <sip:301xxxxxxx@apollo.test.com>;tag=24016 To: <sip:2424@apollo.test.com;user=phone>;tag=5941401e1e Call-ID: e09cfa91@pbx CSeq: 12843 BYE Max-Forwards: 70 Contact: <sip:301xxxxxxx@192.168.11.5:5060;transport=tcp> RTP-RxStat: Dur=14,Pkt=467,Oct=80324,Underun=407 RTP-TxStat: Dur=14,Pkt=498,Oct=85656 Content-Length: 0 [8] 2007/07/08 14:47:18: Play audio_en/ex_permission.wav [7] 2007/07/08 14:47:18: SIP Rx tcp:192.168.11.4:5065: SIP/2.0 200 OK FROM: "301xxxxxxx"<sip:301xxxxxxx@apollo.test.com>;tag=24016 TO: <sip:2424@apollo.test.com;user=phone>;tag=5941401e1e;epid=46-F6-C5-D5-61 CSEQ: 12843 BYE CALL-ID: e09cfa91@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-828172d8ed8622060a8fb41c6091c805;rport CONTENT-LENGTH: 0 SERVER: RTCC/2.0.6017.0 [5] 2007/07/08 14:47:18: BYE Response: Terminate e09cfa91@pbx [7] 2007/07/08 14:47:18: Other Ports: 1 [7] 2007/07/08 14:47:18: Call Port: call-F167A001-8F0F-2A10-0B06-14B@192.168.11.6#0f519ce80a

Dang it ... I thought I had it figured out! But ... I cannot use Call Ext in the Dial Plans as it does not "behave" like the ext it is being sent to. See: http://forum.pbxnsip.com/index.php?showtopic=202 So I'm back to beating this topic around again. I've got to get this figured out ... so much so that I'm supposed to be on vacation this week but I'm taking any time needed to try and finish this problem. I don't mean to offend anyone but I need answers so badly that I'm willing to pony up some cash if that is what it takes ... Prev said: "The REFER looks fine to me - it is just that the dial plan seems not to be able to send the call to something useful." Here's what the first packet looks like again (slightly modified to reflect current settings): [7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065: REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0 FROM: <sip:2400@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f TO: <sip:2502@apollo.test.com>;tag=22017 CSEQ: 1 REFER CALL-ID: 5e333c44@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932 CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4> CONTENT-LENGTH: 0 REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone> USER-AGENT: RTCC/2.0.6017.0 Referred-By: sip:2400@apollo.test.com;user=phone Let's break this down if possible. The packet is from the exchange server apollo (192.168.11.4). Not sure what a REFER is supposed to do but Apollo is contacting the PBXnSIP server at 192.168.11.5 and asking for 2502 which is the extension I'm trying to transfer to. REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0 On the exchange server the ext# it is coming from is 2400. FROM: <sip:2400@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f Not sure why this packet shows the TO: as apollo again. I'd kinda expect this to be for the PBXnSIP server? TO: <sip:2502@apollo.test.com>;tag=22017 So more SIP mombojumbo. CSEQ: 1 REFER CALL-ID: 5e333c44@pbx MAX-FORWARDS: 70 Coming via TCP from 192.168.11.4 (the exchange server). VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932 More SIP info. CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4> CONTENT-LENGTH: 0 Looks like a good chance this is correct as I'm trying to transfer to 2502 on 192.168.11.5 the PBXnSIP server. REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone> More SIP stuff. USER-AGENT: RTCC/2.0.6017.0 Coming from 2400 on the Exchange server. Referred-By: sip:2400@apollo.test.com;user=phone ***** Does anything stick out in this packet that would lead one to believe that the rest of the conversation should not workout? All I want to do is send a call to PBXnSIP from Exchange just like the PRI gateway sends a call to the PBX server. Seems like the way Exchange wants to do it is via a REFER ... Any ideas?

Under Dial Plans you can pick the Trunk: Call Extension If I put in something like: Pattern=3500 Replacement=2500 When I dial 3500 it rings my phone at 2500. The problem is it doesn't behave the same as when you dial 2500 directly. Dialing 3500 the call will ring forever ... The "rules" of the 2500 ext (like voicemail timeout) do not apply. Is this the way it is supposed to act? I'd expect the call to behave just like if you dialed 2500 directly?

I beat this and beat this until I got it to work. I dunno why (and would still love it if someone explained) but I could never get the simple pattern matching to work. So ... here's what I did: Set the Pattern: ([2][0-9][0-9][0-9])@.* Set the Replacement: \1 Done and now all works and life is great!

PS: Thanks for all the help!

You are 100% correct. This was/is a dial plan issue. Being a programmer of some sorts I would think that understanding dial plans both simple and regular expressions should be a breeze. But ... guess what ... I am having trouble. Take the following two scenerios for example: All I want to do in this example is transfer to ext# 2502 and this works without a problem: http://64.193.87.67/~kallman/pbxnsip/working.JPG All I want to do in this example is transfer to the same 2502 but this time using wildcard/pattern matching: http://64.193.87.67/~kallman/pbxnsip/notworking.JPG *ugh* Why does the second example not work? And sometimes in the logfile when I have a bad replacement value I get this: [5] 2007/06/29 11:09:11: Dialplan: i goes to extension [5] 2007/06/29 11:09:11: Dialplan: i is not a known user in domain pbx.test.com What the heck is i? PS: I put the 8$u back to 7$u as you mentioned above just to make sure!

We do have accept redirects turned on ... I followed the Exchange setup in the Wiki. http://wiki.pbxnsip.com/index.php/Microsoft_Exchange The only diff is that I'm using 8$u instead of 7$u ... All I really want is for folks that are "in" the Exchange server to be able to transfer to an ext on the PBXnSIP server ... not necessarily make an outbound call. I don't really understand how it supposed to happen so I don't even know if the SIP REFER I see leading the log file entries above is what should be taking place. And ... because I do have Accept Redirects enabled on that trunk makes me wonder if PBXnSIP really thinks that is the trunk it should be using. The only other trunk I have is for the PRI and it has no entry in the Domain field which may cause PBXnSIP to pick that trunk instead during an Exchange transfer ... I dunno how to debug it well enough to tell what's really happening. Is there anyway to tell which trunk PBXnSIP thinks the call is coming from? According to the rules here: http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk I would think the line: FROM: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f would cause PBXnSIP to realize it is from the Exchange server and to utilize that trunk. Both trunks I have are marked as SIP Gateways ... I'm not even sure I understand what a SIP Registration trunk is but it doesn't sound like what I'd need. Thanks for the help!

Hope you don't mind a long post! Once a call is transferred from PBXnSIP to Exchange ... it might be nice to transfer it back at some point. I can do that but every time PBXnSIP tells me audio_en/ex_permission.wav ... It is transferring from an ext# 8002 on the ExchangeServer which is not valid on the PBXnSIP box (actually I made an 8002 ext just incase but it didn't help) to 2502 which is a valid ext. After I get the message that I don't have perms ... it asks if I want to use a diff ext#. I can tell it I want to use a diff ext# and enter my PIN# and it'll actually let me dial out (and tells me to push # when I'm done) but won't let me dial just an ext#. I'm not sure what's up ... I have a log capture showing the event unfolding ... Anywhere you see apollo.test.com the IP = 192.168.11.4 and viceversa ... that is the Exchange server Anywhere you see pbx.test.com the IP = 192.168.11.5 and viceversa ... that is the PBXnSIP server Anywhere you see the IP = 192.168.10.106 ... that's the phone *** I read the bit about "How the PBX identifies the trunk" but how can you tell in the log file which trunk it thinks it is using? If you can glean any info from these log entries ... any help would be greatly appreciated! PS: apollo.test.com and pbx.test.com do resolve to the proper private IPs listed on our test server [7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065: REFER sip:2502@192.168.11.5:5060;transport=tcp SIP/2.0 FROM: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f TO: <sip:2502@apollo.test.com>;tag=22017 CSEQ: 1 REFER CALL-ID: 5e333c44@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932 CONTACT: <sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4> CONTENT-LENGTH: 0 REFER-TO: <sip:2502@192.168.11.5:5060;transport=tcp;user=phone> USER-AGENT: RTCC/2.0.6017.0 Referred-By: sip:8002@apollo.test.com;user=phone [8] 2007/06/27 14:17:20: Resolve destination 2203: tcp 192.168.11.4 5065 [8] 2007/06/27 14:17:20: Send Packet 202 [7] 2007/06/27 14:17:20: SIP Tx tcp:192.168.11.4:5065: SIP/2.0 202 Accepted Via: SIP/2.0/TCP 192.168.11.4:5065;branch=z9hG4bK5d77c932 From: <sip:8002@apollo.test.com;user=phone>;epid=C1-FB-4C-98-B4;tag=68e0d24c7f To: <sip:2502@apollo.test.com>;tag=22017 Call-ID: 5e333c44@pbx CSeq: 1 REFER Contact: <sip:2502@192.168.11.5:5060;transport=tcp> User-Agent: pbxnsip-PBX/2.0.3.1715 Content-Length: 0 [5] 2007/06/27 14:17:20: Redirecting call to 2502 [8] 2007/06/27 14:17:20: Resolve destination 2204: a Tcp 192.168.11.4 5065 [8] 2007/06/27 14:17:20: Resolve destination 2204: Tcp 192.168.11.4 5065 [8] 2007/06/27 14:17:20: Send Packet BYE [7] 2007/06/27 14:17:20: SIP Tx tcp:192.168.11.4:5065: BYE sip:apollo.test.com:5065;transport=Tcp;maddr=192.168.11.4 SIP/2.0 Via: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-4a1059d8db06faa2122a27c1235fc72f;rport From: "Test User" <sip:2502@apollo.test.com>;tag=22017 To: <sip:8002@apollo.test.com;user=phone>;tag=68e0d24c7f Call-ID: 5e333c44@pbx CSeq: 15517 BYE Max-Forwards: 70 Contact: <sip:2502@192.168.11.5:5060;transport=tcp> RTP-RxStat: Dur=19,Pkt=628,Oct=108016,Underun=18 RTP-TxStat: Dur=18,Pkt=914,Oct=156116 Content-Length: 0 [8] 2007/06/27 14:17:20: Play audio_en/ex_permission.wav [7] 2007/06/27 14:17:20: SIP Rx tcp:192.168.11.4:5065: SIP/2.0 200 OK FROM: "Test User"<sip:2502@apollo.test.com>;tag=22017 TO: <sip:8002@apollo.test.com;user=phone>;tag=68e0d24c7f;epid=C1-FB-4C-98-B4 CSEQ: 15517 BYE CALL-ID: 5e333c44@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.11.5:5060;branch=z9hG4bK-4a1059d8db06faa2122a27c1235fc72f;rport CONTENT-LENGTH: 0 SERVER: RTCC/2.0.6017.0 [5] 2007/06/27 14:17:20: BYE Response: Terminate 5e333c44@pbx [7] 2007/06/27 14:17:20: Other Ports: 1 [7] 2007/06/27 14:17:20: Call Port: cbd543da-aa44bd0d-e66441b8@192.168.10.106#7e9372ddb6 [8] 2007/06/27 14:17:23: UDP: recvfrom receives ICMP message [7] 2007/06/27 14:17:23: SIP Rx udp:192.168.10.106:5060: BYE sip:88002@192.168.11.5:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.10.106;branch=z9hG4bK9ef929f07D8BC593 From: "Test User" <sip:2502@pbx.test.com>;tag=B33CA89B-99603676 To: <sip:88002@pbx.test.com;user=phone>;tag=7e9372ddb6 CSeq: 3 BYE Call-ID: cbd543da-aa44bd0d-e66441b8@192.168.10.106 Contact: <sip:2502@192.168.10.106> User-Agent: PolycomSoundPointIP-SPIP_430-UA/2.1.0.2708 Max-Forwards: 70 Content-Length: 0 [8] 2007/06/27 14:17:23: Resolve destination 2205: a udp 192.168.10.106 5060 [8] 2007/06/27 14:17:23: Resolve destination 2205: udp 192.168.10.106 5060 [8] 2007/06/27 14:17:23: Send Packet 200 [7] 2007/06/27 14:17:23: SIP Tx udp:192.168.10.106:5060: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.10.106;branch=z9hG4bK9ef929f07D8BC593 From: "Test User" <sip:2502@pbx.test.com>;tag=B33CA89B-99603676 To: <sip:88002@pbx.test.com;user=phone>;tag=7e9372ddb6 Call-ID: cbd543da-aa44bd0d-e66441b8@192.168.10.106 CSeq: 3 BYE Contact: <sip:88002@192.168.11.5:5060;transport=udp> User-Agent: pbxnsip-PBX/2.0.3.1715 RTP-RxStat: Dur=22,Pkt=1068,Oct=182604,Underun=590 RTP-TxStat: Dur=21,Pkt=790,Oct=135880 Content-Length: 0 [8] 2007/06/27 14:17:23: Resolve destination 2206: url sip:2502@192.168.10.106 [8] 2007/06/27 14:17:23: Resolve destination 2206: udp 192.168.10.106 5060 [8] 2007/06/27 14:17:23: Send Packet NOTIFY [7] 2007/06/27 14:17:23: SIP Tx udp:192.168.10.106:5060: NOTIFY sip:2502@192.168.10.106 SIP/2.0 Via: SIP/2.0/UDP 192.168.11.5:5060;branch=z9hG4bK-d99bd20584c988d989912af2f4291624;rport From: <sip:2502@pbx.test.com>;tag=69d97dcb93 To: "Test User" <sip:2502@pbx.test.com>;tag=73C94BE-E7463B91 Call-ID: 20735995-bd184780-3bc6a9a3@192.168.10.106 CSeq: 29923 NOTIFY Max-Forwards: 70 Contact: <sip:192.168.11.5:5060;transport=udp> Event: dialog Subscription-State: active;expires=109 Content-Type: application/dialog-info+xml Content-Length: 152 <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="56" state="full" entity="sip:2502@pbx.test.com"></dialog-info> [7] 2007/06/27 14:17:23: SIP Rx udp:192.168.10.106:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.11.5:5060;branch=z9hG4bK-d99bd20584c988d989912af2f4291624;rport From: <sip:2502@pbx.test.com>;tag=69d97dcb93 To: "Test User" <sip:2502@pbx.test.com>;tag=73C94BE-E7463B91 CSeq: 29923 NOTIFY Call-ID: 20735995-bd184780-3bc6a9a3@192.168.10.106 Contact: <sip:2502@192.168.10.106> Event: dialog User-Agent: PolycomSoundPointIP-SPIP_430-UA/2.1.0.2708 Content-Length: 0

Hooray! I got it figured out. We like to live on the edge so we installed our PBXnSIP server of Vista x64. Crazy aye? Well ... I didn't trust just pasting the INVITE in via telnet so I made me a quicky program to do the same thing. After repeated attempts to break it ... I couldn't. Every bit-o-info in the packet was an exact duplicate of what PBXnSIP sent but my program wouldn't break. That is until I ran it from the Vista machine. Tried the program from WinXP, Win2003R2, Vista 32bit and Vista 64bit. Each Vista machine "hung". Packet traces showed a strange ACK being sent by Vista machines immediately after the INVITE. Google told me about all the niffty enhancements to the TCP stack that Vista brought to the table. What's this ... Auto-Tuning the receive window size ... hmm ... From a command prompt: netsh interface tcp set global autotuninglevel=disabled After that single command ... we're now back on track.

We are trying to get PBXnSIP to play nice with Exchange 2007. Everything works great but there two long delays during the SIP setup that results in about a 10 second total delay before the Exchange auto attendant starts talking. *ugh* Thru ugly low level packet traces it really seems that the Exchange server is just sitting there waiting. I called MS and they tried for days to help but we could find no problems. Then I got out the handy dandy telnet app and connected to port 5060 and pasted an INVITE to the Exchange server. To my surprise it just hung out ... for about 5 seconds (which it does twice during a connection leading to the 10 second delay). If I telnet and paste and then manually press ENTER it immediately works. If I telnet and paste an extra CR+LF it just sits there for 5 seconds. Is it a possible timing issue? I've actually seen this trying to simulate an SMTP connection via Exchange. Telnet/paste and it can't take it. Doing the same thing to a Linux machine running exim and it eats it right up. Does that make any sense?