IETF Logo Mail Archive

Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt

worley@ariadne.com (Dale R. Worley) Thu, 23 May 2013 02:05 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5711E8139 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 19:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPySzf3WAej9 for <mmusic@ietfa.amsl.com>; Wed, 22 May 2013 19:05:01 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9421F826B for <mmusic@ietf.org>; Wed, 22 May 2013 19:04:57 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4N24829006759; Wed, 22 May 2013 22:04:11 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4N248uU5250004; Wed, 22 May 2013 22:04:08 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4N247r25245471; Wed, 22 May 2013 22:04:07 -0400 (EDT)
Date: Wed, 22 May 2013 22:04:07 -0400
Message-Id: <201305230204.r4N247r25245471@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Parthasarathi R <partha@parthasarathi.co.in>
In-reply-to: <002801ce564b$51e52230$f5af6690$@co.in> (partha@parthasarathi.co.in)
References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB113508A6A@xmb-aln-x02.cisco.com> <002801ce564b$51e52230$f5af6690$@co.in>
Cc: fluffy@cisco.com, mmusic@ietf.org
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 02:05:07 -0000

> > From: Cullen Jennings (fluffy)
> > 
> > What happens when an endpoint that understands the [annexb] attribute
> > sends [an] offer to an endpoint that does not understand or implement
> > the [annexb] attribute ?

> From: "Parthasarathi R" <partha@parthasarathi.co.in>
> 
> As per Sec 2.1.9 RFC 4856, "annexb=no" has to be sent by Answerer in case
> the answerer does not support G729 AnnexB. The exact RFC snippet is as
> follows:  
> 
>         "annexb: indicates that Annex B, voice activity detection, is
>         used or preferred.  Permissible values are "yes" and "no"
>         (without the quotes); "yes" is implied if this parameter is
>         omitted."
> 
> Please let me know whether you wish to explicitly mention in the draft that
> Answerer *MUST* send "annexb=no".

No, if the offerer sends "annexb=yes" and the answerer *does not
understand it*, that is, does not support this I-D, the answer will
not contain an annexb parameter.  You should make sure the draft
describes how the *offerer* detects this situation and ensures that
the operation of the codec is done as well as possible.

Dale

v2.26.15 | Report a Bug | By Email | System Status