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

From: "Somogyi, Gabor (NSN - HU/Budapest)" <[email-masked]>
Date: Wed, 17 Jun 2009 21:27:31 +0300

Sorry if that topic was discussed earlier. I was not able to find the
proper answer, though.

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.

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?

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.

BR,
Gabor Somogyi

---

From: Randell Jesup <[email-masked]>
Date: Thu, 18 Jun 2009 10:47:48 -0400

>shell address that issue, as it may not be possible to give a generic

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.

>the answerer to reduce the offered bitrate? Must the same bitrate be

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

>even "downgrading" codec settings. Same applies to many other codecs, as

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
[email-masked]
"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)