Summary:	ASTERISK-16558: Asterisk does not properly align SDP "m=" lines when answering an SDP offer (provoking a T.38 negociation issue)
Reporter:	frawd (frawd)	Labels:
Date Opened:	2010-08-12 10:23:16	Date Closed:	2011-11-11 15:01:32.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip_trace_initial_call.txt ( 1) sip_trace_t38_reinvite.txt
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. ****** ADDITIONAL INFORMATION ****** An example of T.38 negociation failure against a Huawei (SIP capture attached): 1. A regular audio session is established with a single "m=audio" line: Asterisk => Huawei: m=audio 10062 RTP/AVP 8 101 Huawei => Asterisk: m=audio 21988 RTP/AVP 8 101 2. The Huawei chooses to replace the audio stream by an "m=image", and add a new "m=audio" stream to the media session: m=image 21988 udptl t38 m=audio 25184 RTP/AVP 8 101 3. Asterisk answers the following: m=audio 0 RTP/AVP 8 101 m=image 4875 udptl t38 But it should keep the same order as the new offer sent by the Huawei, as such: m=image 4875 udptl t38 m=audio 0 RTP/AVP 8 101
Comments:	By: Elazar Broad (ebroad) 2010-08-12 11:36:54 "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" That is correct, see the last 20 lines or so of add_sdp() in chan_sip. "This allows for streams to be matched up based on their order." does imply that the order must match, though the wording of "The answer MUST contain exactly the same number of "m=" lines as the offer." could have been less vague if it had has been worded as "The answer MUST contain exactly the same number and order of "m=" lines as the offer." my .02 elazar   By: frawd (frawd) 2010-08-12 11:56:28 Thanks for giving me arguments to put responsabilities to Huawei, but come on... The older SIP/SDP RFC (RFC-2543) says: "The caller and callee align their media descriptions so that the nth media stream ("m=" line) in the caller's session description corresponds to the nth media stream in the callee's description." The new SDP RFC (RFC-3264) implies it quite strongly: page 8: - "[...] there MUST be a corresponding "m=" line in the answer." - "This allows for streams to be matched up based on their order." See section 6 "Generating the Answer" and 8 "Modifying the Session" from the same RFC, always referring to the "corresponding" m= line. Other RFCs, for example RFC-5888 refer to 3264 saying: "[RFC3264] describes the usage of SDP in text of SIP. The offerer and the answerer align their media description so that the nth media stream ("m=" line) in the offerer's session description corresponds to the nth media stream in the answerer's description." Also get a look in the "SIP implementors" mailing list, a few threads talk about this. I mean, come on! :-D By: Elazar Broad (ebroad) 2010-08-12 12:12:45 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 By: frawd (frawd) 2010-08-12 12:23:52 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! By: frawd (frawd) 2010-08-12 18:10:25 I just lost hope. Similarities exist with issue ASTERISK-14386, raised 1 year and 2 months ago... Anyone brave willing to help in making a patch attempt to support proper 'm=' alignments (help me obiwan mnicholson, you're my only hope)? The patch would imply a better tracking of media stream info throughout the dialog to check for changes in types, ... This would probably make it easier to add support for multiple media stream per type (at least the part to make Asterisk able to reject them properly), thus closing ASTERISK-14386 as well. François. PS: Hello to you man from the future reading this message. Have you guys invented flying cars yet in 2011? By: Elazar Broad (ebroad) 2010-08-13 10:14:23 Unfortunately there isn't much that is copied between the originating request and the outbound request from Asterisk, another good example of this is fmtp values for video. From what I understand of the code, passing information like this between two sip_pvt structs is going to require some serious work. By: Kinsey Moore (kmoore) 2011-10-11 11:52:53.490-0500 I have a patch that should resolve this issue and a few others.  See reviewboard issue here: https://reviewboard.asterisk.org/r/1516/ By: Kinsey Moore (kmoore) 2011-11-11 15:01:32.279-0600 Fix commited.