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

[David Vossel]

----- "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