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

[Kevin P. Fleming]

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org