-----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... ------------------- Scott, thanks for all the details here. I will investigate the setting that are putting the public address on their calls this weekend. Ranga - it seem suspect that the bridge isn't forwarding the resent re-invite. Would this public address be an issue for the bridge? _______________________________________________ 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/