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

[Olle E. Johansson]

30 maj 2012 kl. 14:27 skrev 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?
I don't understand the reason for this.

Instead of rejecting the call - why not reject the media stream if there are other media streams we do support?

If the call ONLY has media streams that we do not support, we should respond with a 488.

/O