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

[Vadim Lebedev]

Olle E. Johansson wrote:
> 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
>   

I think it would be good occasion to implement better handling of fmtp
attributes for streams
handled in transparent way.  I mean that if endpoint A  calling endpoint
B has a fmtp attribute in video stream descriptor it should be fowarded
to B by asterisk.
Today it is scrapped.


Thanks
Vadim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090910/cc37851c/attachment-0001.htm