[#XTRN-206] Polycom phone does not handle 'headers' in Refer-To URIs correctly

External

Polycom phone does not handle 'headers' in Refer-To URIs correctly

Created: 2008-07-15 12:46 Updated: 2008-10-08 13:31

Component/s:

Polycom - SoundPoint IP

Affects Version/s:

None

Fix Version/s:

None

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

File Attachments:

blind_xfer.pcap (22 kb)
2.

merged.xml (101 kb)

Environment:

« Hide

Polycom firmware "PolycomSoundPointIP-SPIP_650-UA/Grizzly.3892"
sipX 3.11

Issue Links:

Related

This issue related to:
	~~XECS-1457~~ Blind Transfer issue with Polycom pho...

Description

« Hide

During a blind transfer sequence, a UA can receive a REFER like this:

REFER sip:207@10.1.1.171;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.1.68;branch=z9hG4bK-sipXecs-00d011e0d4ff76ee2ec5d37a4c5d45a94a34
Via: SIP/2.0/TCP 10.1.1.41;branch=z9hG4bK854347abCD03BB40
From: <sip:202@victoria.pingtel.com;user=phone>;tag=4AF6BD44-DFAC36BF
To: "207" <sip:207@victoria.pingtel.com>;tag=9CF3C0FB-11000BF2
Cseq: 3 REFER
Call-Id: 11a781ce-1420f139-a86408b8@10.1.1.171
Contact: <sip:202@10.1.1.41;transport=tcp>
User-Agent: PolycomSoundPointIP-SPIP_301-UA/2.2.2.0084
Refer-To: <sip:208@victoria.pingtel.com?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E>

The Polycom phone then produces an INVITE like this:

INVITE sip:208@victoria.pingtel.com;transport=tcp?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E SIP/2.0
Via: SIP/2.0/TCP 10.1.1.171;branch=z9hG4bK2be0ec80C9A4CFA3
From: "207" <sip:207@victoria.pingtel.com>;tag=32BBB957-60F115DE
To: <sip:208@victoria.pingtel.com?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E>
CSeq: 1 INVITE
Call-ID: 44de31fa-fb5997b5-54a8b044@10.1.1.171
Contact: <sip:207@10.1.1.171;transport=tcp>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_650-UA/Grizzly.3892
Accept-Language: en
Supported: 100rel,replaces
Allow-Events: talk,hold,conference
Referred-By: <sip:202@victoria.pingtel.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 290

But the request-URI of that INVITE is incorrect. See RFC 3261 section 19.1.5. The 'header' part of the request-URI should be split off as a separate header (and have %-quoting removed):

INVITE sip:208@victoria.pingtel.com;transport=tcp SIP/2.0
X-Sipx-Authidentity: <sip:202@victoria.pingtel.com;signature=487CDEE7%3A%3A4a40638118bbcea615a0aaeb089a7ccd>
[etc.]

Description

During a blind transfer sequence, a UA can receive a REFER like this: REFER sip:207@10.1.1.171;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.1.1.68;branch=z9hG4bK-sipXecs-00d011e0d4ff76ee2ec5d37a4c5d45a94a34 Via: SIP/2.0/TCP 10.1.1.41;branch=z9hG4bK854347abCD03BB40 From: <sip:202@victoria.pingtel.com;user=phone>;tag=4AF6BD44-DFAC36BF To: "207" <sip:207@victoria.pingtel.com>;tag=9CF3C0FB-11000BF2 Cseq: 3 REFER Call-Id: 11a781ce-1420f139-a86408b8@10.1.1.171 Contact: <sip:202@10.1.1.41;transport=tcp> User-Agent: PolycomSoundPointIP-SPIP_301-UA/2.2.2.0084 Refer-To: <sip:208@victoria.pingtel.com?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E> The Polycom phone then produces an INVITE like this: INVITE sip:208@victoria.pingtel.com;transport=tcp?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E SIP/2.0 Via: SIP/2.0/TCP 10.1.1.171;branch=z9hG4bK2be0ec80C9A4CFA3 From: "207" <sip:207@victoria.pingtel.com>;tag=32BBB957-60F115DE To: <sip:208@victoria.pingtel.com?X-Sipx-Authidentity=%3Csip%3A202%40victoria.pingtel.com%3Bsignature%3D487CDEE7%253A%253A4a40638118bbcea615a0aaeb089a7ccd%3E> CSeq: 1 INVITE Call-ID: 44de31fa-fb5997b5-54a8b044@10.1.1.171 Contact: <sip:207@10.1.1.171;transport=tcp> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomSoundPointIP-SPIP_650-UA/Grizzly.3892 Accept-Language: en Supported: 100rel,replaces Allow-Events: talk,hold,conference Referred-By: <sip:202@victoria.pingtel.com> Max-Forwards: 70 Content-Type: application/sdp Content-Length: 290 But the request-URI of that INVITE is incorrect. See RFC 3261 section 19.1.5. The 'header' part of the request-URI should be split off as a separate header (and have %-quoting removed): INVITE sip:208@victoria.pingtel.com;transport=tcp SIP/2.0 X-Sipx-Authidentity: <sip:202@victoria.pingtel.com;signature=487CDEE7%3A%3A4a40638118bbcea615a0aaeb089a7ccd> [etc.]

Show »

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Dale R. Worley - 2008-07-15 12:52

Attachment merged.xml shows an example of this behavior, with the REFER at frame 39 and the resulting INVITE at frame 40.

Attachment blind_xfer.pcap shows the same calls in PCAP format. The REFER is frame 21 and the INVITE is frame 23.

[ Permlink | « Hide ]

Aaron Brumpton - 2008-07-15 16:57

Are there any other sipx specific headers that need to be supported, other than

X-Sipx-Authidentity

[ Permlink | « Hide ]

Aaron Brumpton - 2008-07-22 15:10

polycom twin to this issue is VOIP-44384

[ Permlink | « Hide ]

Paul Mossman - 2008-09-25 12:16

I've verified that the resulting INVITE has the X-Sipx-Authidentity header, and that the %-quoting has been removed. (Grizzly.5173) Thanks!

For reference: X-Sipx-Authidentity: <sip:1455@bcmsl2195.ca.nortel.com;signature=48B7FCB9%3A%3Af367eb85482ad8be27f0de29e5a7ea2a>