[asterisk-bugs] [Asterisk 0011326]: asterisk modifying the in-dialogue route set which is a violation of RFC3261

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11326 
====================================================================== 
Reported By:                robertjdyck
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11326
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:            1.2.24  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-20-2007 14:07 CST
Last Modified:              11-21-2007 02:30 CST
====================================================================== 
Summary:                    asterisk modifying the in-dialogue route set which
is a violation of RFC3261
Description: 
The severity is marked as major because it may be a security threat.
Although the problem is always reproducible I have not confirmed that it
is an asterisk bug. I am not actually an asterisk user. My service provider
uses asterisk for PSTN gateways. The service provider has not been
forthcoming with version and configuration information nor have them
offered to test with me. Perhaps someone with influence or insider
knowledge could determine the asterisk version used by voxalot/sipbroker.

The suspected bug:
When the SIP UA calls through the PSTN gateway and the call is answered,
the gateway does a re-INVITE to optimize the media path. The UA which is
now acting as an UAS sends 200 OK. The expected ACK from the gateway never
arrives and the 200 OK is retransmitted until the UAS times out and sends
BYE. The critical clue is that if the UAS sending the 200 OK includes a
Record-Route list, the call proceeds normally. If the UAS does not include
the RR list when get the situation described above. This leads me to
suspect that gateway is creating an empty route set when it does not
receive an RR list. The ACK can not find its way to the UAS.

RFC 3261 is clear that the route set must not be modified after the
dialogue is established. It states that an UAS MAY send RR but that it must
influence the established route set. By implication, the lack of RR should
not influence it either.

See RFC 3261 12.2 Requests within a Dialog

Please note that calls from the gateway to the UA even with re-INVITE,
proceed normally. Also when the UA sends BYE ( with an RR list ), the
gateway's response arrives at the UA.
====================================================================== 

---------------------------------------------------------------------- 
 oej - 11-21-07 02:30  
---------------------------------------------------------------------- 
Hmm. I've already seen this in a bug report. Isn't this a duplicate? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-21-07 02:30  oej            Note Added: 0074125                          
======================================================================