14 Nov
2004
14 Nov
'04
4:56 a.m.
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....
--
Jamin W. Collins
"Never underestimate the power of very stupid people in large groups."
-- John Kenneth Galbraith
17 Nov
17 Nov
7:35 p.m.
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?
--
Jamin W. Collins
It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking. -- Andrew Suffield
17 Dec
17 Dec
10:10 p.m.
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(a)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(a)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(a)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(a)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?
--
Jamin W. Collins
"Never underestimate the power of very stupid people in large groups."
-- John Kenneth Galbraith
20 Dec
20 Dec
10:30 a.m.
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(a)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(a)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(a)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(a)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?
6:49 p.m.
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).
--
Jamin W. Collins
This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar
7:01 p.m.
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).
7267
days inactive
7303
days old
5 comments
2 participants
participants (2)
-
Greger V. Teigre -
Jamin W. Collins