[asterisk-dev] RFC: chan_sip SDP parsing changes in behavior

[Saúl Ibarra Corretgé]

Hi Kevin,  

--  
Saúl Ibarra Corretgé
http://saghul.net | http://about.me/saghul

>  
> That could happen some day; the next step (which Kinsey Moore is working  
> on in his spare time) is improving the SDP code to at least be able to  
> properly respond to offers that include unsupported streams.
>  
That would be awesome!
>  
> Today, we don't have a way to respond properly to unsupported streams.  
> If an offer includes a BFCP stream, for example, our answer will not  
> include that stream *at all*. If that stream was in the 2nd position of  
> a three-stream offer (audio, BFCP, video), then our answer will be  
> really messed up because we'll have a video stream in position 2.

I can indeed confirm that we would fail there. If the stripped stream is at the end, however, I think it can be handled.  
>  
> This is why I've proposed this set of changes; I'd much rather fail that  
> session setup completely than respond with such a broken answer. The  
> changes required to respond with a non-broken answer are significantly  
> more invasive than what I've proposed and would certainly not be  
> candidates for existing release branches. They *may* make it into  
> Asterisk 11, but they aren't on the current 'committed work' list  
> (primarily because it's rare that these problems affect calls, except  
> when unusual endpoints are in use).
>  
I see. Do you have numbers in how big the impact would be? I mean, if people prepared their stacks to be gentle in what they receive but now Asterisk just rejects their offer that would be a bad thing IMHO.


KInd regards,