[asterisk-bugs] [Asterisk 0017849]: Asterisk does not properly align SDP "m=" lines when answering an SDP offer (provoking a T.38 negociation issue)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17849 
====================================================================== 
Reported By:                frawd
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17849
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-12 10:23 CDT
Last Modified:              2010-08-12 12:12 CDT
====================================================================== 
Summary:                    Asterisk does not properly align SDP "m=" lines when
answering an SDP offer (provoking a T.38 negociation issue)
Description: 
It appears that Asterisk generates SDP replies with "m=" lines always
aligned in the same order:
1. m=audio
2. m=video
3. m=text
4. m=image

When it should reply with the same order that was in the initial offer per
RFC-3264 (page 8):

[QUOTE]For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same number of "m="
lines as the offer. This allows for streams to be matched up based on their
order. This implies that if the offer contained zero "m=" lines, the answer
MUST contain zero "m=" lines.[/QUOTE]

This could potentially provoke many interoperability issues, one of which
is presented below.
====================================================================== 

---------------------------------------------------------------------- 
 (0125905) ebroad (manager) - 2010-08-12 12:12
 https://issues.asterisk.org/view.php?id=17849#c125905 
---------------------------------------------------------------------- 
Corresponding can be ambiguous. With that said, while 3264 may be
"interpretable", I agree with you and in no way meant to put Asterisk in
the clear(I can see how that was construed, my apologies), however, final
interpretation is up to an Asterisk dev.

elazar 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-12 12:12 ebroad         Note Added: 0125905                          
======================================================================