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/
