Subject: [AVT] Re: [SIP] Re: Codecs G729 and their various flavors

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Jul 2001 17:10:30 -0400

See the RTP FAQ at http://www.cs.columbia.edu/~hgs/rtp

This is not a SIP issue, so I'm moving the discussion to AVT.

Manoj Bhatia wrote:
> 
> Hi
> 
> The fact is that g.729 /g.729a  pair shall not interoperate with
> g.729b/g.729ab.

If somebody can define what G.729AB is, it would be helpful. Doesn't
seem to be defined by the ITU.

I have no idea what it means for G.729 to interoperate with G.729B,
given that the latter is silence suppression and the former a regular
codec.

There is one potential issue, namely as to whether the ability to
support G.729B (silence suppression) is worth indicating. This would
presumably be a fmtp, not a payload type.

> The static payload '18' defined so far is being used for g.729/g.729a
> by
> SIP folks  .
> Some are now interested in using g.729b/g.729ab pair for obvious
> advantages in
> VAD,DTX etc.

Again, static payload types are history. See the FAQ.

> 
> So, my question is that why don't we have a static payload defined for
> g.729b/g729ab
> pair just like we had '18' for the other pair.
> 
> Or is it legal to use '18' for this pair too ?
> 
> To avoid interop issues, can we lay down rules to state that when to
> use '18' and when
> not to use '18' especially if a SIP-UA agent has the ability to
> support 'all' the four flavors of
> g729 and is interested in advertising that in its SDP ?
> 
> thanks
> -manoj
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Simao Campos-Neto <[email-masked]>
Date: Mon, 09 Jul 2001 15:19:19 -0400

Henning,

Henning Schulzrinne wrote:
> ...

It's simply G.729 Annex A (i.e. the reduced-complexity version of G.729)
with the G.729 Annex B silence removal functionality.

> presumably be a fmtp, not a payload type.

Here, I am not sure -- Manoj might have meant G.729 Main body (the "full
complexity" version of G.729) with Annex B functionality, then it makes
sense. 

The interoperability issue will be between a G.729|G.729A decoder operating
with an encoder (either G.729 or G.729A) that perfoms silence removal
(G.729 Annex B). Ideally, in the call setup it should be signalled that the
decoder does not support G.729B and the encoder should refrain from using
it. If this does not happen, my guess is that the G.729B packets should be
discarded on the receive end and the decoder should deal with the speech
frames (which would actually contain silence segments) that do not arrive
as lost packets (since the silence frames were removed by the encoder),
eventually muting the output and resuming normal coding in the start of the
next talkspurt. 

> ...

BR,
Simão
-- 
===========================================================================
Simão Ferraz de Campos Neto, Scientist *All comments are strictly my own*
LMGT/COMSAT Laboratories               Tel:    +1-301-428-4516
22300 Comsat Drive                     Fax:    +1-301-428-9287
Clarksburg MD 20871 - USA              E-mail: [email-masked]
===========================================================================
  ******** Practice random kindness and senseless acts of beauty ********
===========================================================================

---

From: Manoj Bhatia <[email-masked]>
Date: Mon, 09 Jul 2001 18:39:37 -0400

See comments inline.

> complexity" version of G.729) with Annex B functionality, then it makes

Yes,  for me G.729b codec is full complexity G.729 with Annex B
and                       G.729ab is reduced complexity G.729 with Annex B.

--
Manoj Bhatia                           |        |         |
[email-masked]                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s

---

From: "Chris Fulmer" <[email-masked]>
Date: Mon, 09 Jul 2001 20:44:54 -0400

So, in all this discussion, I think it should be pointed out that G.729
and G.729A are compatible with each other -- that is that the output
from one can be used as the input to the other.  This discussion is
really only about annex B and not annex A.

--
Chris Fulmer
Nortel Networks

Manoj Bhatia wrote:

>> ==
>> ========================================================================
>>
>> ============================
>> ==============================================
>> ========
>> ==================================================================
>
> --
> Manoj Bhatia                           |        |         |

---

From: Simao Campos-Neto <[email-masked]>
Date: Tue, 10 Jul 2001 09:16:44 -0400

Precisely -- that's what I tried to address in the part of my original
posting, reproduced below.

BR,
Simão.
--
Chris Fulmer wrote:
> and G.729A are compatible with each other -- that is that the output from
> one can be used as the input to the other.  This discussion is really
> only about annex B and not annex A.
> 
> --
> Chris Fulmer
> Nortel Networks
> 
...
> >
> >>
> >> The interoperability issue will be between a G.729|G.729A decoder
> >> operating with an encoder (either G.729 or G.729A) that perfoms
> >> silence removal (G.729 Annex B). 
> >> Ideally, in the call setup it should be signalled
> >> that the decoder does not support G.729B and the encoder should
> >> refrain from using it. If this does not happen, my guess is that
> >> the G.729B packets should be discarded on the receive end and the
> >> decoder should deal with the speech frames (which would actually
> >> contain silence segments) that do not arrive as lost packets (since
> >> the silence frames were removed by the encoder), eventually muting
> >> the output and resuming normal coding in the start of the next
> >> talkspurt.
> >>
> >> > ...
> >>
> >> BR,
> >> Simão
> >> --
> >> ==