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

[Olle E. Johansson]

9 sep 2009 kl. 17.33 skrev David Vossel:

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

As I wrote in the bug tracker, with experience of this code, it's not  
easy to make our SDP parser, if it is worthy of such a name, to  
understand multiple streams of the same type and respond properly - or  
make a choice. Please look in the code and you'll understand. There  
are multiple comments in that part of the code about making a proper  
solution. And I understand it was hard work to get it to properly  
answer an offer of multiple streams, only one of each.

We don't choose, we randomly parse the SDP and take the latest stuff  
we find I guess. If you want to improve our parser, we look forward to  
your patches. We do need help :-)

Regards,
/Olle