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

[Kevin P. Fleming]

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?

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