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

[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.

Mark Michelson