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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 11 January 2013 11:28 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 33BDF21F870E for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:28:01 -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 1XEN6fhEOVR1 for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:28:00 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 9706E21F868F for <mmusic@ietf.org>; Fri, 11 Jan 2013 03:27:59 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-66-50eff73d077e
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2B.BE.32353.D37FFE05; Fri, 11 Jan 2013 12:27:58 +0100 (CET)
Received: from [] ( by esessmw0191.eemea.ericsson.se ( with Microsoft SMTP Server id; Fri, 11 Jan 2013 12:27:57 +0100
Message-ID: <50EFF73D.2060105@ericsson.com>
Date: Fri, 11 Jan 2013 13:27:57 +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+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja7d9/cBBtdes1lMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYeP3mQuOCBacWbpZvYGxhcCXYycHBICJhI31qxigbDFJC7c W8/WxcjFISRwklHi3v+3TBDOakaJn7sXsHYxcnDwCmhLrH5XBtLAIqAq8ev9YTYQm03AQmLL rftgg0QFoiTeX21iBrF5BQQlTs58AhYXEZCR2LtpM1hcWEBfYvaiT8wQiyUlFk3rBKthFtCT mHK1hRHClpfY/nYOWI0Q0Nrlz1pYJjDyz0IydhaSlllIWhYwMq9iZM9NzMxJLzffxAgMp4Nb fhvsYNx0X+wQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBW3Uz9vmPF1 9+TMti+lk7IWL9+by+zlvG95QH9tplXJlxULuVXjHDVOd1+70vU59KhuvI78FhG7jYv9Nq6r XdEf1/q4Kc/3idFiti2ctQxbNFvO/94azx+aU39+bdnXzskfE5MXbN7AzRXCFv1ad54cW2GU ug//uUqrwFNuhVUsD5ducw7oUmIpzkg01GIuKk4EAL4Ise71AQAA
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:28:03 -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.