[asterisk-dev] SIP: handling multiple m=video or m= audio lines

[Mark Michelson]

David Vossel wrote:
> ----- "Kevin P. Fleming" <kpfleming at digium.com> wrote:
> 
>> Mark Michelson wrote:
>>
>>> An even better idea would be to actually answer all streams, making
>> sure to use 
>>> a 0 port for any streams of a certain type beyond the first. The
>> trouble with 
>>> this is that chan_sip is not written to handle multiple streams of
>> the same type 
>>> at all. This means the changes would be far more invasive. With
>> chan_sip being 
>>> the house of cards that it is, plus the fact that this isn't exactly
>> the most 
>>> pressing issue I've seen, I'm inclined to go with the reporter's
>> solution unless 
>>> there are strong objections.
>> The most serious objection is that this is non-conformant with RFC
>> 3264
>> (as is our current implementation). If an SDP offer contains 'n' m=
>> lines, the answer MUST also contain 'n' m= lines. The answerer may
>> choose to decline any or all of those media stream offers by setting
>> them to port number 0 (and marking them as 'a=inactive' may not hurt
>> as
>> an additional measure), but it must respond to all of them.
>>
>> Failing to do so leads to exactly the sort of problem being discussed
>> here; the offerer cannot conclusively determine which streams the
>> answerer is accepting.
>>
>> We do not need to make chan_sip able to actually multiple *active*
>> streams of the same type, but if our goal is to be RFC compliant, we
>> should absolutely record the 'm=' line information for each offered
>> stream and ensure that our answer includes each one, properly marked
>> as
>> 'declined'. Whether this requires also including all the 'a=' lines
>> for
>> each stream I don't really know, but I suspect they would not be
>> required.
> 
> I agree, the real fix here is to at least respond to all media streams regardless if we are accepting them or not.  Like OEJ has mentioned, given our current architecture even simply responding with rejected media streams is not a simple task.  Given that our current SDP parser is not RFC compliant, and the simple fix of only responding to the first media stream of each type supported is proven to give Asterisk a little better interoperability, does this not sound like a valid change to be made until an architecture change can be made in the future?
> 
> ~Vossel
> 

Well, the problem is one that I brought up with you earlier. By responding only 
to the first media stream of a given type, the offerer is still not guaranteed 
to parse the reply "correctly." The user agent in the reporter's example works 
appropriately in the situation, but we can't rely on user agents to all 
interpret such a cryptic answer the same way.

Here's an idea for how to approach this. First, don't even touch 1.4, since the 
problem there is much different (it will respond with a 488 if an audio stream 
and two video streams are offered). For 1.6.X, I think you could follow oej's 
suggestion regarding having a configuration option which users can set if they 
know that their UA will properly handle only having the first media stream of a 
type answered. For trunk, I would suggest to do the right thing: do deeper work 
to make sure all media streams for a given type at least have an answer, even if 
all but one stream is rejected (though not necessarily the first stream 
offered). I also would recommend waiting until 1.6.3 is branched before merging 
this work into trunk so that there is more time for it to be out there before 
being part of a branch.

Also, on a side note, I checked RFC 4317 like oej suggested, and in those 
examples, the a= lines *are* echoed for rejected media streams.

Mark Michelson