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

Olle E. Johansson oej at edvina.net
Wed Sep 9 13:16:07 CDT 2009


9 sep 2009 kl. 19.24 skrev Mark Michelson:

> Kevin P. Fleming 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.
>>
>
> The examples in RFC 3264 show the m= lines being exactly the same as  
> they were
> received, except that the port has been set to 0. No a= lines are  
> required.
>
Always check RFC4317 too as it explains things a bit more clearly.

/O



More information about the asterisk-dev mailing list