The udp packet is probably too big. What size is the failed one? Methinks the vop adds more to it and they (vop) need to make available a settable threshold to it. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431
Email: [email protected] 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: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Thu Mar 18 14:01:59 2010 Subject: [sipx-users] Call failures via UDP 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. _______________________________________________ sipx-users mailing list [email protected] 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/
