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

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Mon, 14 January 2013 09:11 UTC

Return-Path: <miguel.a.garcia@ericsson.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 686F921F88A8 for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2013 01:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5C1pY1UzEJk for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2013 01:11:48 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF821F87C8 for <mmusic@ietf.org>; Mon, 14 Jan 2013 01:11:36 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-07-50f3cbc761ac
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.89.32353.7CBC3F05; Mon, 14 Jan 2013 10:11:36 +0100 (CET)
Received: from [159.107.26.63] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 10:11:35 +0100
Message-ID: <50F3CBC6.90901@ericsson.com>
Date: Mon, 14 Jan 2013 10:11:34 +0100
From: "Miguel A. Garcia" <Miguel.A.Garcia@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: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
References: <50EFFC93.70406@ericsson.com>
In-Reply-To: <50EFFC93.70406@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RvfE6c8BBms+clhMXf6YxeLcp7ss DkweS5b8ZPK4e+sSUwBTFJdNSmpOZllqkb5dAlfGvg1fWAomKlV0T/jC1MC4XqqLkZNDQsBE 4uqZL0wQtpjEhXvr2UBsIYGTjBIPJ2t3MXIB2asZJea3rmcFSfAKaEpcenQPzGYRUJXomLiD GcRmEzCXaN24kR3EFhWIknh/tYkZol5Q4uTMJywgtoiAmcT7f6vAljELBEis/TkdzBYWsJFY v34FUD0H0DJNidlrCkDCnAJaEudPTGaHKLeVuDDnOguELS+x/e0cZog7NSUm31zKPIFRcBaS bbOQtMxC0rKAkXkVI3tuYmZOern5JkZgQB7c8ttgB+Om+2KHGKU5WJTEecNdLwQICaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYLRWOiZoO01DI3OJQ7e7/sLqWSwmbv981RomFt8yutOssHhn ZD/T0sMxO55vvPp3fb56Rt5imQ+BXya2v8vckPjro+OM0GXdr6yvn5dqOjUlcP91Ex/FwzXa 9RNqfjAfEOacqhS8b7v/lcoK63SNnRKld361L7Q5fPFRatSKq88nLprFITvrUrgSS3FGoqEW c1FxIgAp+Sm9FgIAAA==
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [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: Mon, 14 Jan 2013 09:11:50 -0000

Hi Gonzalo:

Here are some inline comments. I am about to post version -17 addressing 
your comments:


On 11/01/2013 12:50, Gonzalo Camarillo wrote:
> Hi,
>
> I just got a publication request for the following draft:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16
>
> Please, find below my AD review.
>
> Cheers,
>
> Gonzalo
>
>
> draft-ietf-mmusic-sdp-cs-16:
>
> 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 "-".

Ok.

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

The sort-of-syntax in Section 5.2.3.1 is simply an introduction to the 
three types of correlation mechanisms that can be used. So, the syntax is 
the way to introduce to Sections 5.2.3.2, 5.2.3.3, and 5.2.3.4.

But I understand your point. I suggest removing the syntax from there and 
including a pointer to Section 5.7, where the formal syntax is described.

>
> 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?

This is a hard problem even to provide guidance, because the PSTN E.164 
numbers have a variable length. So, if you want to do it right, you 
should become aware of the number plan in the network you are camping. 
But this is outside the scope of the specification.

We can add a note to refer to ITU-T E.164 specification in order for 
implementations to consider what the right number of digits is.

>
> 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?
>

Yeap, and I found that there is an RFC specifying it (there is always an 
RFC specifying what you want :-). It is RFC 4648 and we are referring to 
the base16 (or "hex") encoding. We will change the text accordingly.


> 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?

Ok, I guess we are talking of 5 to 10 digits.

>
> Page 17: Section 5.2.3.4 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.

ok.

>
> 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.

ok too.

>
> 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.

Done



Thanks,


>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain