History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XTRN-131
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Dale R. Worley
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
External

Polycom phone does not properly process "Require" header

Created: 2008-04-26 20:01   Updated: 2008-10-08 13:30
Component/s: Polycom - SoundPoint IP
Affects Version/s: None
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. XML File merged-merde.xml (262 kb)

Issue Links:
Duplicate
 
This issue also reported as:
XTRN-210 Interop:LG phones do not reject the r... Critical Resolved
XTRN-211 Interop:Polycom phones do not reject ... Critical Closed
Related
This issue related to:
XTRN-130 LG-Nortel LIP 68xx phone does not pro... Major Open
 


 Description  « Hide
RFC 3261 defines the Require header of a request to contain a list of SIP extensions that are required to properly process the request. RFC 3261 requires a SIP UA to examine the Require header of each incoming request, and if contains an extension name that the phone does not implement (including if it does not recognize the extension name), the UA is required to reject the request with a 420 Extension Not Implemented response.

This may seem academic, but proper processing of Require is important in various situations: It allows the other party to detect and compensate for non-implementation of extensions, it allows for more graceful failure when a call requires an extension to process successfully, and it is an integral part of sipX's authorization scheme(*).

It appears that the Polycom phone does not process the Require field at all. The interopability test described at http://interop.pingtel.com/#Require shows that the phone does not reject requests with "Require: merde".

----

(*) INVITEs with "Replaces: xxxx" and "Require: replaces" do not require authorization.


 All   Comments   Work Log   Change History      Sort Order:
Dale R. Worley - 2008-04-26 20:06
The behavior seen in the Polycom is as follows (messages taken from attachment merged-merge.xml, with some irrelevant headers and SIP bodies deleted):

frame 44:

INVITE sip:202@10.1.1.41 SIP/2.0
From: "206"<sip:206@victoria.pingtel.com>;tag=94bf30f0-a0101b9-13c4-1fd4-1cd45e91-1fd4
To: <sip:*63202@victoria.pingtel.com>
Call-Id: 94bf0488-a0101b9-13c4-1fd4-6d5c3028-1fd4@victoria.pingtel.com
Cseq: 1 INVITE
Supported: replaces
User-Agent: LG-Nortel LIP 6830 v1.2.38sp SN/00405A187C1A
Contact: <sip:206@10.1.1.185:5060>
Require: merde

frame 50:

SIP/2.0 200 OK
From: "206" <sip:206@victoria.pingtel.com>;tag=94bf30f0-a0101b9-13c4-1fd4-1cd45e91-1fd4
To: <sip:*63202@victoria.pingtel.com>;tag=C70E298B-531CEE64
CSeq: 1 INVITE
Call-ID: 94bf0488-a0101b9-13c4-1fd4-6d5c3028-1fd4@victoria.pingtel.com
Contact: <sip:202@10.1.1.41>
User-Agent: PolycomSoundPointIP-SPIP_301-UA/2.2.2.0084

A correct response (420) is shown by an old Pingtel Xpressa phone:

frame 150:

INVITE sip:203@10.1.20.215;LINEID=02a6e739b83cee7cafa833b315d14789 SIP/2.0
From: "206"<sip:206@victoria.pingtel.com>;tag=94bf47e8-a0101b9-13c4-1ffc-69f68c8d-1ffc
To: <sip:*63203@victoria.pingtel.com>
Call-Id: 94bf0630-a0101b9-13c4-1ffc-f071fb4-1ffc@victoria.pingtel.com
Cseq: 1 INVITE
Supported: replaces
User-Agent: LG-Nortel LIP 6830 v1.2.38sp SN/00405A187C1A
Contact: <sip:206@10.1.1.185:5060>
Content-Type: application/sdp
Content-Length: 295
Require: merde

frame 151:

SIP/2.0 420 Bad Extension
From: "206"<sip:206@victoria.pingtel.com>;tag=94bf47e8-a0101b9-13c4-1ffc-69f68c8d-1ffc
To: <sip:*63203@victoria.pingtel.com>
Call-Id: 94bf0630-a0101b9-13c4-1ffc-f071fb4-1ffc@victoria.pingtel.com
Cseq: 1 INVITE
Unsupported: merde

Paul Mossman - 2008-09-25 15:17
Test Version: 3.1.0.0073 I've verified that the phone returns a 420 response. Thanks!