[asterisk-dev] RFC: chan_sip SDP parsing changes in behavior
Kevin P. Fleming
kpfleming at digium.com
Wed May 30 07:27:56 CDT 2012
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?
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
More information about the asterisk-dev