[MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 11 January 2013 11:50 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EB70721F87DC for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KlP+jHz-UoP5 for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:50:47 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 8084C21F87B6 for <mmusic@ietf.org>; Fri, 11 Jan 2013 03:50:46 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-db-50effc942f9b
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.28.10459.49CFFE05; Fri, 11 Jan 2013 12:50:45 +0100 (CET)
Received: from [] ( by esessmw0256.eemea.ericsson.se ( with Microsoft SMTP Server id; Fri, 11 Jan 2013 12:50:44 +0100
Message-ID: <50EFFC93.70406@ericsson.com>
Date: Fri, 11 Jan 2013 13:50:43 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvje7UP+8DDE584LKYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mg4fvclccEC04szSzewNjC8Euhg5OCQETCR+TPbvYuQEMsUk Ltxbz9bFyMUhJHCSUeL91GZ2CGc1o8SZx3+ZQRp4BTQlTvSwgjSwCKhKbL74iQXEZhOwkNhy 6z6YLSoQJfH+ahMziM0rIChxcuYTsLiIgIzE3k2bweLCAvoSsxd9YoZYLCmxaFonWA2zgJ7E lKstjBC2vMT2t3PAaoQEtCWWP2thmcDIPwvJ2FlIWmYhaVnAyLyKkT03MTMnvdxwEyMwmA5u +a27g/HUOZFDjNIcLErivGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPZXmHhGv3KY ekhu5b7ckjlfLtQK1j9xZavdt/DTrh+bgldmpfEnH/knOuHvDlfmp02J035+tUs88vLTVp2e uLeH8p8WXbl30jTBbFvM2+UH7pnenX99vje3YXh7Yl6i2YfGbQ1/9gtWxKT9d2O4KaVR2ry+ fsX6S5oq3EZ7kkzfd2wU2/haMFiJpTgj0VCLuag4EQCAqymU9AEAAA==
Subject: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16
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: Fri, 11 Jan 2013 11:50:48 -0000


I just got a publication request for the following draft:


Please, find below my AD review.




Page 10: remove the indentation of the following paragraph. Indented
paragraphs are typically used to provide clarifications while this one
contains normative language:

      Note that <addrtype> and/or <connection-address> MUST NOT be
      omitted when unknown since this would violate basic syntax of SDP
      [RFC4566].  In such cases, they MUST be set to a "-".

Section provides a "format" for the cs-correlation attribute.
However, its ABNF formal syntax is in Section 5.7. So, why does Section also contain a syntax for the attribute... and what type of
syntax is that?

Page 14: the text says:

      To mitigate this problem implementations
      should consider only some of the rightmost digits from the E.164

Can we provide a more concrete advice (or at least some discussion) on
the number of digits to consider?

Page 15: we define how to encode a binary value in hexadecimal format
and represent it as a two-digit ASCII value. Can we point to an existing
specification that defines how to do that instead of specifying it inline?

Page 17: the text says:

      Implementations are advised to select a number of DTMF digits that
      provide enough assurance that the call is related, but on the
      other hand do not prolong the bearer setup time unnecessarily.

Can we provide a more concrete recommendation?

Page 17: Section specifies what to do when the correlation
fails. However, that is described in general in Section 5.3.3. Why don't
we move all the statements about how to decide whether the sessions are
correlated to Section 5.3.3? Now, the following statement contradicts
what Section 5.3.3 says, for example:

   the passive side
   SHOULD treat the circuit-switched bearer as not correlated to the
   ongoing session.

The indented text right after the statement above talks about
suppressing alerting. Such a supression is applicable to any session,
not only those that are correlated using DTMF tones. So, we could also
move that discussion to Section 5.3.3.

Section 5.5: rephrase the following sentence (possibly splitting it into
more than one sentence) so that it is clearer:

      Note that this may result in the recipient of the initial Offer in
      rejecting the Offer if the recipient of the Offer is not aware of
      its own E.164 number, and thus concluding that it will not be
      possible to establish a circuit-switched bearer since neither
      party is aware of their E.164 number.