Re: [AVT] Codec parameter mismatch in SDP offer and answer

[Randell Jesup <rjesup at wgate.com>]

"Somogyi, Gabor (NSN - HU/Budapest)" <gabor.somogyi at nsn.com> writes:
>What happens if codec parameters in the SDP answer differ from the ones
>in relevant offer? Maybe each codec specific SDP format description
>shell address that issue, as it may not be possible to give a generic
>answer.

It's codec/RFC-dependent, however you can generally say that unless
otherwise mentioned, each side defines what it's willing/expecting to
receive, and the other side needs to provide that (modulo anything
defined by the relevant RFC, such as the way RFC 3952 (iLBC) deals with
the 'mode' parameter in offer-answer.  Note that due to early-media
issues, the offerer generally needs to be ready and willing to receive
what it indicated, even if the answer might cause the expectations to
change.   For example, if you offer iLBC with mode=20, you must be ready
to receive either 20 or 30ms iLBC packets (until you get the answer).
You don't *have* to play 30ms packets, though it would be highly
advised, but you have to be ready to handle them and shouldn't do
anything stupid.

>RFC 3952 (iLBC) clearly defines that "mode" parameter is bi-directional,
>meaning that in both direction the same "mode" must be used. And if the
>parameter differs in the offer and the answer, then value "30" must be
>used. That sounds fine.
>
>In rfc3047-bis-09 proposal I saw no such definition. Is it possible for
>the answerer to reduce the offered bitrate? Must the same bitrate be
>used in both directions?

The spec should discuss offer-answer implications; if not specified then 
asymmetric bitrates, etc is probably implied as supported.

>I saw such interworking issues between live products of different
>vendors. G.729 (RFC 3555) defines optional parameter "annexb". If the
>offerer indicated the willingness of using Annex B, then could the
>answerer indicate that it is not willing to use discontinuous
>transmission (as it cannot generate comfort noise)? When the offerer
>sent its offer, it may had set up its DSPs, so might not be happy about
>even "downgrading" codec settings. Same applies to many other codecs, as
>well.

G.729 probably is ok with asymmetric use of annexb=no (I haven't
reviewed it).  It defines what each side is willing to receive.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)