[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:23 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0125906) frawd (reporter) - 2010-08-12 12:23
 https://issues.asterisk.org/view.php?id=17849#c125906 
---------------------------------------------------------------------- 
The same happened to me, I spent a few hours reading before being sure
about the meaning of those lines and posting the issue.

By the way, I forgot to say that this negociation issue makes the Huawei
to fail having the right port or to never send any UDPTL stream (even if it
actually ACKs).

It's the first issue I could really trace, but I had other with
audio/video streams that I'm pretty sure had something to do with this. For
example anything that would place video before audio could potentially
suffer the same problem. If I can have more debug info I'll post it, but it
should be enough with the T38 example.

Let's wait and see what Asterisk devs say! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-12 12:23 frawd          Note Added: 0125906                          
======================================================================