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

[Kevin P. Fleming]

On 05/31/2012 07:35 AM, Saúl Ibarra Corretgé wrote:
> Is this the direction forward in Asterisk? I'd like to see a day when Asterisk copies the media streams it doesn't understand to the outbound call leg. Is this somewhere in the TODO list?

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.

> I agree with Olle here, best would be to reject the media stream by just setting the port to 0 but letting it be. If only unsupported streams are proposed then a 488 response would appropriate. Of course, I'm unaware of all the internals involved.

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.

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

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