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

[Mark Michelson]

David Vossel wrote:
> Hello!
> 
> This is in regard to issue #15407 on the bug tracker and arunpunj's proposed fix.
> 
> I understand if multiple m=video streams are offered in a SDP that only one can be chosen due to the current architecture, but I don't understand our current method of choosing the single video stream.  Right now, if multiple streams of the same type are present, only the last one is chosen.  This results in each parsed stream of the same type overriding the one before it, which in itself has the potential to cause problems if parts of the previous stream are not overridden entirely.
> 
> So, the question is, why do we choose the last media offering when multiple are present over the first one.  In the case of issue #15407, if multiple video streams are offered, and only one is responded to, the device assumes it is the first media stream rather than the second (causing a port mismatch).  I'm not saying whether or not that device is exhibiting correct behavior or not, but since we don't at least respond to the other video streams with a zeroed out port number, it seems rather odd that we would pick the last one rather than the first.  If choosing the first stream increases our chances of interoperability and has no negative side effects, this seems like a simple fix that should be made.
> 
> ~Vossel
> 

If I had to guess as to the reason why the SDP parser works the way it does, it 
is probably due to a mentality of "no one will likely offer us more than one 
video stream, so I won't try to work to handle that situation." The same goes 
for multiple streams of any type. On a side note, the same general attitude 
seems to pervade the code in other ways as well. See pedantic mode for further 
evidence of that.

I already talked with David about this issue some, so he's already seen my 
opinion, but I thought it would be good to get it out there in this discussion, 
too. The easiest way to handle this situation is the way proposed by the 
reporter on the issue. Always honor the first stream and ignore subsequent 
offers of the same type. This is not ideal, but it requires the least invasive 
amount of changes.

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.

Mark Michelson