[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


On Wednesday, May 30, 2012 at 2:27 PM, Kevin P. Fleming wrote:

> In review 1811 (https://reviewboard.asterisk.org/r/1811/) I've got a set  
> of changes designed to accomplish multiple things:
>  
> * Improve chan_sip's warning/error messages related to SDP parsing to  
> use proper RFC-defined terminology, and ensure that the messages are  
> clearly stating exactly what happened.
>  
> * Ensure that warning/error messages related to parsing SDP 'm' lines  
> include the 'm' line content that was in error.
>  
> * Ensure that Asterisk *rejects* SDP offers/answers that contain media  
> stream specifications that Asterisk doesn't support.
>  
> This latter change is what is of some concern here: if this patch is  
> merged, Asterisk will start rejecting SDP offers/answers that it used to  
> accept or ignore. Specifically, if:
>  
> * An 'm' line for an audio/video/text stream includes an unknown RTP  
> profile.
>  
> * An 'm' line specifies a top-level media type other than 'audio',  
> 'video', 'text' or 'image'.
>  
> * An 'm' line specifies more than one port for an audio/video/text  
> stream (the current patch allows this to pass, but I think it should be  
> changed before it is committed).
>  
> Personally I'd prefer that Asterisk behave this way, even in the  
> existing release branches, as accepting such SDP offers/answers will  
> only lead to broken calls anyway, and it would be better to break the  
> call at the beginning as soon as the media offer problems can be identified.
>  
> Does anyone out there object to these changes in behavior going into  
> 1.8, 10, and trunk?
>  
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?

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.


Regards,