[Asterisk-Dev] chan_sip.c - BUG REPORT: Request-URI not in compliance with RFC3261

Wed Jan 18 07:51:23 MST 2006

Indeed, I have verified that Asterisk does not respect the route information 
in the Record-Route headers, and because of it the Request-URI after the BYE 
or REFER keyword is often wrong. 

Also, I checked 4 other SIP Softphones and the OnDO software PBX and they 
all behave differently from Asterisk when they issue a BYE request within an 
existing SIP dialog. 

It's either:
 - Asterisk is wrong and 4 other SIP implementaions are correct
 - or the other way around... 

Anyway, it seems like a major SIP protocol violation to me, and explains why 
call transfers do not work half of the time. 

George Robinson 

> On Sat Jan 14 17:12:24 MST 2006 Daniel Leeds wrote:

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 at 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 at 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 at sphone.vopr.vonage.net:5061>  #
#################################################### 

<-- SIP read rom sphone.vopr.vonage.net:5061:
INVITE sip:pstin_7748712 at 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 at sphone.vopr.vonage.net:5061>
Record-Route: <sip:pstin_7748712 at inbound4.vonage.net:5060>
From: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
To: <sip:pstin_7748712 at inbound4.vonage.net>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at sphone.vopr.vonage.net:5061>
Record-Route: <sip:pstin_7748712 at inbound4.vonage.net:5060>
From: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
To: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 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 at 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 at inbound4.vonage.net>;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 at 
inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712 at inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712 at asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B at 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 

 ----------------------------------------------------
Grypa? Damy radê! SprawdŸ jak jej zapowbiegaæ, a jeœli ju¿ za póŸno
...jak leczyæ - grypa.wp.pl
http://klik.wp.pl/?adr=www.grypa.wp.pl&sid=636 

 ---------------------------------------------------------------------------- 
 ---- 

Previous message: [Asterisk-Dev] time stamp in queue_log
Next message: [Asterisk-Dev] zaptel echo preload
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

 ---------------------------------------------------------------------------- 
 ----
More information about the Asterisk-Dev mailing list 