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

[Olle E. Johansson]

9 sep 2009 kl. 23.02 skrev 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.
>
And, to repeat myself, in order to make sure that we answer everything  
properly, including totally to us unknown media streams, we need to  
save it in text format.

/O