Yes, I'll look at it this weekend. Thanks. -----Original Message----- From: Tony Graziano [mailto:tgrazi...@myitdepartment.net] Sent: Thursday, March 25, 2010 2:17 PM To: thod...@verizon.net Subject: Re: [sipx-users] Call failures via UDP
Does vop have a setting for topiology that let's you tell it to use its local (not global,stun address) address? ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: sipx-users-boun...@list.sipfoundry.org <sipx-users-boun...@list.sipfoundry.org> To: 'Scott Lawrence' <xmlsc...@gmail.com> Cc: sipx-users@list.sipfoundry.org <sipx-users@list.sipfoundry.org> Sent: Thu Mar 25 16:40:47 2010 Subject: Re: [sipx-users] Call failures via UDP -----Original Message----- From: Scott Lawrence [mailto:xmlsc...@gmail.com] Sent: Thursday, March 25, 2010 12:17 PM To: Todd Hodgen Cc: sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] Call failures via UDP On Thu, 2010-03-18 at 11:01 -0700, Todd Hodgen wrote: > I have a scenario where one specific company calling into a customer s > console has calls that drop when answered. The thing that we find > unique for these calls is that they are UDP, where TCP calls don t > fail. > > > > Here is the setup sipXecs 4.0.4. Console is a Voice Operator Panel, > with a Polycom 450 tethered to it. The tethering works this way > call comes to VOP Console, which forks the call to another extension > on the 450. Customer answers on the 450, and speaks to the calling > party. I ve worked extensively with the console manufacturer, and we > believe the issue is not there. A debug of their software came up > with the following: > > > > 17/03 12:10:10.231 DEBUG1 UA [75:2xxx273807] <-- INVITE SDP > 6835264022320204725 1 10.110.2.10:30002 PCMU/G729/DTMF sendrecv > 17/03 12:10:10.231 DEBUG1 UA [75:2xxx273807] --> 180 Ringing > 17/03 12:10:18.106 DEBUG1 UA [75:2xxx273807] --> OK SDP 384 384 > 2xx.xxx.131.152:26154 PCMU/DTMF > 17/03 12:10:18.293 DEBUG1 UA [75:2xxx273807] --> INVITE SDP 384 385 > 10.110.2.101:2234 PCMU/DTMF > > A call is offered (INVITE), VOP answers (OK), then connects it to the > slave phone (INVITE). > > At this time the answer from sipXecs is "408 Request Timeout" only 3 > seconds after the INVITE. > > Here is another call from the same customer, but the call is delivered > with TCP rather than UDP > > 17/03 12:10:41.121 DEBUG1 UA [79:2xxx267607] <-- INVITE SDP > 7890176375740151118 1 10.110.2.10:30010 PCMU/G729/DTMF sendrecv > 17/03 12:10:41.121 DEBUG1 UA [79:2xxx267607] --> 180 Ringing > 17/03 12:10:57.120 DEBUG1 UA [79:2xxx267607] --> OK SDP 384 384 > 2xx.xxx.131.152:26162 PCMU/DTMF > 17/03 12:10:57.292 DEBUG1 UA [79:2xxx267607] --> INVITE SDP 384 385 > 10.110.2.101:2226 PCMU/DTMF > 17/03 12:10:57.417 DEBUG1 UA [79:2xxx267607] <-- OK SDP > 7890176375740151118 1 10.110.2.10:30010 PCMU/G729/DTMF sendrecv > > I carefully checked the original INVITEs between the two calls there > are only two differences between the two calls: > > 1. The caller ID and phone numbers are different: > Bad call: "company" 2xxx273807 > Good call: "company" 2xxx267607 > > 2. The Via original source is different: > Bad call: Via: SIP/2.0/UDP 10.110.2.10:5090;originator=~~id~bridge > Good call: Via: SIP/2.0/TCP > 10.110.2.10:5090;originator=~~id~bridge > > There is a 3rd call in the log where everything is fine and the source > is also "SIP/2.0/TCP 10.110.2.10:5090;originator=~~id~bridge". > > > > > > Simple solution turn off UDP. However, I believe I should find the > underlying issue here and resolve it. I can do extensive call traces > on site. Wanted to see if anyone had suggestions. > > > > BTW, if I set up a did with an alias to another extension, this caller > can call into it just fine. It is only when this particular customer > calls into the console that the disconnect happens. Seems bizarre. I made a filtered version of your trace by removing all the subscription and registration dialogs (takes out a lot of noise). I'm not much closer to an answer, but have a couple of questions: * Why is the VOP using a public address when everything else is using private addresses? * Is the VOP just keeping a call nailed up (the brown one?) to the tethered phone? I don't see any call here... The call appears to go wrong when the VOP sends a re-INVITE back toward the caller (frame 69) as UDP, which is then sent (70) by the proxy to the bridge, which appears to be lost and is resent as TCP by the proxy (72). The bridge doesn't seem to forward it, and the transaction times out... You got me on question one, there is no reason for it to use a public address. It is on a machine with a private address. It does keep a call nailed up between the Console and the Polycom 450, or at least it can, and I believe they do for the most part. That becomes an audio path between the two devices. It's pretty cool the way it works actually. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
