Anyone else seeing problems with Polycom 300 phones ignoring CANCEL messages from a SER proxy? I've got a number of SER proxies (running 0.8.12) that are receiving CANCEL messages and passing them on to the Polycom phone, but all indications are that the phone is just ignoring them (as it continues to ring).
Below is an example capture:
U 2004/11/08 15:10:32.802663 172.16.22.25:5060 -> 130.110.72.16:5060 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 130.110.72.16..From: "Interaction Cen ter" sip:8475787000@GLCU.ORG;type=ICConnectionCall;tag=8500..To: sip:187 42@172.16.22.25:5060;tag=585588F8-A212D515..CSeq: 1 INVITE..Call-ID: 198f7 c0ca5c28e7f59759c1f1c024617@130.110.72.16..Contact:sip:18742@172.31.22.12 ..Record-Route: sip:18742@172.16.22.25;ftag=8500;lr=on..User-Agent: Polyc omSoundPointIP-SPIP_500-UA/1.1.0..Content-Length: 0....
U 2004/11/08 15:10:47.634541 130.110.72.16:1136 -> 172.16.22.25:5060 CANCEL sip:18742@172.16.22.25:5060 SIP/2.0..To: sip:18742@172.16.22.25:506 0..From: "Interaction Center" sip:8475787000@GLCU.ORG;type=ICConnectionCa ll;tag=8500..Via: SIP/2.0/UDP 130.110.72.16..CSeq: 1 CANCEL..Call-ID: 198f 7c0ca5c28e7f59759c1f1c024617@130.110.72.16..User-Agent: ININ-EICSRVR01-9987 9649..Content-Length: 0....
U 2004/11/08 15:10:47.634635 172.16.22.25:5060 -> 172.31.22.12:5060 CANCEL sip:18742@172.31.22.12 SIP/2.0..Max-Forwards: 10..Record-Route: <sip :18742@172.16.22.25;ftag=8500;lr=on>..To: sip:18742@172.16.22.25:5060..Fr om: "Interaction Center" sip:8475787000@GLCU.ORG;type=ICConnectionCall;ta g=8500..Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK7377.54324bd5.0..Via: S IP/2.0/UDP 130.110.72.16..CSeq: 1 CANCEL..Call-ID: 198f7c0ca5c28e7f59759c1f 1c024617@130.110.72.16..User-Agent: ININ-EICSRVR01-99879649..Content-Length : 0....
U 2004/11/08 15:10:47.986990 172.16.22.25:5060 -> 172.31.22.12:5060 CANCEL sip:18742@172.31.22.12 SIP/2.0..Max-Forwards: 10..Record-Route: <sip :18742@172.16.22.25;ftag=8500;lr=on>..To: sip:18742@172.16.22.25:5060..Fr om: "Interaction Center" sip:8475787000@GLCU.ORG;type=ICConnectionCall;ta g=8500..Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK7377.54324bd5.0..Via: S IP/2.0/UDP 130.110.72.16..CSeq: 1 CANCEL..Call-ID: 198f7c0ca5c28e7f59759c1f 1c024617@130.110.72.16..User-Agent: ININ-EICSRVR01-99879649..Content-Length : 0....
U 2004/11/08 15:10:48.124132 130.110.72.16:1136 -> 172.16.22.25:5060 CANCEL sip:18742@172.16.22.25:5060 SIP/2.0..To: sip:18742@172.16.22.25:506 0..From: "Interaction Center" sip:8475787000@GLCU.ORG;type=ICConnectionCa ll;tag=8500..Via: SIP/2.0/UDP 130.110.72.16..CSeq: 1 CANCEL..Call-ID: 198f 7c0ca5c28e7f59759c1f1c024617@130.110.72.16..User-Agent: ININ-EICSRVR01-9987 9649..Content-Length: 0....
On Sat, Nov 13, 2004 at 06:56:04PM -0700, Jamin W. Collins wrote:
Anyone else seeing problems with Polycom 300 phones ignoring CANCEL messages from a SER proxy? I've got a number of SER proxies (running 0.8.12) that are receiving CANCEL messages and passing them on to the Polycom phone, but all indications are that the phone is just ignoring them (as it continues to ring).
No one else is seeing this? Anyone else using Polycom phones with a SER proxy?
On Sat, Nov 13, 2004 at 06:56:04PM -0700, Jamin W. Collins wrote:
Anyone else seeing problems with Polycom 300 phones ignoring CANCEL messages from a SER proxy? I've got a number of SER proxies (running 0.8.12) that are receiving CANCEL messages and passing them on to the Polycom phone, but all indications are that the phone is just ignoring them (as it continues to ring).
I reported this problem a while ago as you can see from the quoting above. Since then, I believe the problem has been located. It seems that for some reason SER is inserting a "branch" tag to the INVITE sent to the phone and then changing that "branch" tag on the disconnect:
The original INVITE request from the server: To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 130.110.72.16 Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 CSeq: 1 INVITE Contact: sip:xxxxxxxxxx@130.110.72.16;type=ICConnectionCall User-Agent: ININ-EICSRVR01-99924257 Allow: INVITE, BYE, ACK, CANCEL, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO Accept: application/sdp Accept-Encoding: identity Content-Length: 0
INVITE request from SER to phone (note the branch tag): Max-Forwards: 10 Record-Route: sip:18742@172.16.22.25;ftag=17919;lr=on To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK4722.88643d91.0 Via: SIP/2.0/UDP 130.110.72.16 Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 CSeq: 1 INVITE Contact: sip:xxxxxxxxxx@130.110.72.16;type=ICConnectionCall User-Agent: ININ-EICSRVR01-99924257 Allow: INVITE, BYE, ACK, CANCEL, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO Accept: application/sdp Accept-Encoding: identity Content-Length: 0
CANCEL message from the server: To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 130.110.72.16 CSeq: 1 CANCEL Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 User-Agent: ININ-EICSRVR01-99924257 Content-Length: 0
CANCEL message from SER to phone (note the new value of the branch tag): Max-Forwards: 10 Record-Route: sip:18742@172.16.22.25;ftag=17919;lr=on To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK4722.98643d91.0 Via: SIP/2.0/UDP 130.110.72.16 CSeq: 1 CANCEL Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 User-Agent: ININ-EICSRVR01-99924257 Content-Length: 0
In the initial INVITE request from the SER proxy to the phone the branch tag had a value of "z9hG4bK4722.88643d91.0" while in the CANCEL message bares a value of "z9hG4bK4722.98643d91.0" the digit immediately following the first '.' is different.
Anyone know if there is a patch to correct this, an option to disable the usage of the branch tag, or if this has been corrected post 0.8.12?
With SER 0.8.14 and Polycom we have not seen the behavior you describe. Cannot say why... g-)
Jamin W. Collins wrote:
On Sat, Nov 13, 2004 at 06:56:04PM -0700, Jamin W. Collins wrote:
Anyone else seeing problems with Polycom 300 phones ignoring CANCEL messages from a SER proxy? I've got a number of SER proxies (running 0.8.12) that are receiving CANCEL messages and passing them on to the Polycom phone, but all indications are that the phone is just ignoring them (as it continues to ring).
I reported this problem a while ago as you can see from the quoting above. Since then, I believe the problem has been located. It seems that for some reason SER is inserting a "branch" tag to the INVITE sent to the phone and then changing that "branch" tag on the disconnect:
The original INVITE request from the server: To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 130.110.72.16 Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 CSeq: 1 INVITE Contact: sip:xxxxxxxxxx@130.110.72.16;type=ICConnectionCall User-Agent: ININ-EICSRVR01-99924257 Allow: INVITE, BYE, ACK, CANCEL, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO Accept: application/sdp Accept-Encoding: identity Content-Length: 0
INVITE request from SER to phone (note the branch tag): Max-Forwards: 10 Record-Route: sip:18742@172.16.22.25;ftag=17919;lr=on To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK4722.88643d91.0 Via: SIP/2.0/UDP 130.110.72.16 Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 CSeq: 1 INVITE Contact: sip:xxxxxxxxxx@130.110.72.16;type=ICConnectionCall User-Agent: ININ-EICSRVR01-99924257 Allow: INVITE, BYE, ACK, CANCEL, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO Accept: application/sdp Accept-Encoding: identity Content-Length: 0
CANCEL message from the server: To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 130.110.72.16 CSeq: 1 CANCEL Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 User-Agent: ININ-EICSRVR01-99924257 Content-Length: 0
CANCEL message from SER to phone (note the new value of the branch tag): Max-Forwards: 10 Record-Route: sip:18742@172.16.22.25;ftag=17919;lr=on To: sip:18742@172.16.22.25 SIP to address: sip:18742@172.16.22.25 From: "Interaction Center" sip:xxxxxxxxxx@DMN1.ORG;type=ICConnectionCall;tag=17919 SIP Display info: "Interaction Center" SIP from address: sip:xxxxxxxxxx@DMN1.ORG SIP tag: 17919 Via: SIP/2.0/UDP 172.16.22.25;branch=z9hG4bK4722.98643d91.0 Via: SIP/2.0/UDP 130.110.72.16 CSeq: 1 CANCEL Call-ID: 6f1a95c1a4d7ba6d8ae12aeeda933906@130.110.72.16 User-Agent: ININ-EICSRVR01-99924257 Content-Length: 0
In the initial INVITE request from the SER proxy to the phone the branch tag had a value of "z9hG4bK4722.88643d91.0" while in the CANCEL message bares a value of "z9hG4bK4722.98643d91.0" the digit immediately following the first '.' is different.
Anyone know if there is a patch to correct this, an option to disable the usage of the branch tag, or if this has been corrected post 0.8.12?
On Mon, Dec 20, 2004 at 08:30:42AM +0100, Greger V. Teigre wrote:
With SER 0.8.14 and Polycom we have not seen the behavior you describe. Cannot say why... g-)
Any chance that your configuration uses the syn_branch option, perhaps set to "no"? Testing seems to indicate that this option corrects the problem (most likely by not using the branch tag at all).
Interesting, but unfortunately no. The default syn_branch setting is used in our config. g-)
Jamin W. Collins wrote:
On Mon, Dec 20, 2004 at 08:30:42AM +0100, Greger V. Teigre wrote:
With SER 0.8.14 and Polycom we have not seen the behavior you describe. Cannot say why... g-)
Any chance that your configuration uses the syn_branch option, perhaps set to "no"? Testing seems to indicate that this option corrects the problem (most likely by not using the branch tag at all).
-
Greger V. Teigre -
Jamin W. Collins