BUG REPORT: chan_sip.c is not compliant with SIP RFC3261


#1

chan_sip.c - BUG REPORT:

Asterisk ignores the information in “Record-Route” headers and thus breaks compliance with SIP RFC 3261.
This lack of compliance often results in wrong Request-URI after the BYE and REFER methods.
Consequently the applications HangUp() and Transfer() do not work properly in many scenarios.

Most acutely Asterisk is not in compliance with RFC-3261, Section: 12.2.1.1 and the following statement:
If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI…"

Notice that this processing of the route set is MANDATORY in SIP implementations, and the “route sets” are defined by the “Record-Route” headers.

Please see quotations from RFC-3261 and Asterisk SIP Debug Output below:

Regards,
Daniel Leeds


RFC 3261, Section: 8.1.1.1 - Request-URI
“In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy.

When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI.”

RFC 3261, Section: 12.1.1 - UAS behavior

“The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. If no Record-Route header field is present in the request, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the request.”

RFC 3261, Section: 12.1.2 - UAC Behavior
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.

RFC 3261, Section: 12.2.1.1 - Generating the Request

“The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.

If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value.

For example, if the remote target is sip:user@remoteua and the route set contains:         <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
The request will be formed with the following Request-URI and Route header field:    METHOD sip:proxy1

Route: sip:proxy2,sip:proxy3;lr,sip:proxy4,sip:user@remoteua

If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the end of the Route header field preserves the information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose- router).”

RFC 3261, Definitions (page 24):
“Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured”.


####################################################

Below is Asterisk v1.2.1 SIP debug output

of answering an incoming call and hanging up.

Note that the Request-URI in the BYE method

is wrong, as it does not account for the

topmost Record-Route: header in the original

incoming INVITE request.

The Request-URI after BYE should be:

sip:pstin_7748712@sphone.vopr.vonage.net:5061

####################################################

<-- SIP read rom sphone.vopr.vonage.net:5061:
INVITE sip:pstin_7748712@asterisk.aa.eu:5060;suppress-features=- SIP/2.0
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bK15FF
Record-Route: sip:pstin_7748712@sphone.vopr.vonage.net:5061
Record-Route: sip:pstin_7748712@inbound4.vonage.net:5060
From: “pstn_1234567”sip:transit.vonage.net;tag=428326453
To: sip:pstin_7748712@inbound4.vonage.net
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 INVITE
Contact: sip:transit.vonage.net:5060;rtpupdated=-
Max-Forwards: 13
Content-Type: application/sdp
Content-Length: 355

v=0
o=CiscoSystemsSIP-GW-UserAgent 3846 5784 IN IP4 transit.vonage.net
s=SIP Call
c=IN IP4 transit.vonage.net
t=0 0
m=audio 19064 RTP/AVP 0 18 2 100 101
c=IN IP4 transit.vonage.net
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Reliably Transmitting (no NAT) to sphone.vopr.vonage.net:5061:
SIP/2.0 200 OK
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061;received=sphone.vopr.vonage.net
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bK15FF
Record-Route: sip:pstin_7748712@sphone.vopr.vonage.net:5061
Record-Route: sip:pstin_7748712@inbound4.vonage.net:5060
From: “pstn_1234567”sip:transit.vonage.net;tag=428326453
To: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 INVITE
User-Agent: Asterisk v1.2.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: sip:pstin_7748712@asterisk.aa.eu
Content-Type: application/sdp
Content-Length: 486

v=0
o=root 3084 3084 IN IP4 asterisk.aa.eu
s=session
c=IN IP4 asterisk.aa.eu
t=0 0
m=audio 18628 RTP/AVP 4 18 3 0 8 2 5 10 7 110 97 101
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:7 LPC/8000
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

<-- SIP read from sphone.vopr.vonage.net:5061:
ACK sip:pstin_7748712@asterisk.aa.eu:5060 SIP/2.0
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bKD9C
From: “pstn_1234567”sip:transit.vonage.net;tag=428326453
To: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 ACK
Max-Forwards: 13
Content-Length: 0

Reliably Transmitting (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

#####################################################

Here note that Asterisk did not get a reply to

its BYE request because the Request-URI was wrong

#####################################################

Retransmitting #1 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #2 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #3 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #4 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #5 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #6 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: sip:pstin_7748712@inbound4.vonage.net:5060,sip:transit.vonage.net:5060
From: sip:pstin_7748712@inbound4.vonage.net;tag=as108211ae
To: “pstn_1234567”sip:transit.vonage.net;tag=428326453
Contact: sip:pstin_7748712@asterisk.aa.eu
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username=“pstin_7748712”, realm=“sphone.vopr.vonage.net”, algorithm=MD5, uri=“sip:sphone.vopr.vonage.net”, nonce=“455097506”, response=“4e2131ede158b2f71ce3bea4a7cb04c7”, opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0