[asterisk-dev] RFC: chan_sip SDP parsing changes in behavior
Saúl Ibarra Corretgé
saghul at gmail.com
Thu May 31 07:35:43 CDT 2012
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
> * 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.
More information about the asterisk-dev