[MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 08 April 2014 17:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172601A0671 for <mmusic@ietfa.amsl.com>; Tue, 8 Apr 2014 10:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UMzMQMu6lyO for <mmusic@ietfa.amsl.com>; Tue, 8 Apr 2014 10:42:57 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id EBD251A0221 for <mmusic@ietf.org>; Tue, 8 Apr 2014 10:42:56 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id nP4z1n0011swQuc5FViwhb; Tue, 08 Apr 2014 17:42:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id nViw1n00e3ZTu2S3bViwna; Tue, 08 Apr 2014 17:42:56 +0000
Message-ID: <53443520.90706@alum.mit.edu>
Date: Tue, 08 Apr 2014 13:42:56 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: IETF MMUSIC WG <mmusic@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396978976; bh=4b/WNgALvZvXpcXCVHzliL1ELOvCx1d3CnNMvMOoVr4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dPcR13wG1ZsDK6AeLzEkDVq32KrQdPZne2qSEmWoURkCovtoimRAV/rOmqsl2oDNg cnfVRFFByWic9IQkAT5PUQW/U0BM5B+NuzxM9Cjp/YsiTxECNm3dEhC1B0QOauCmBQ ZmC1lTBsU/38RQCqRBXXNQGfuJqUB14RpM7UMexvI8CkEkFb1qAMVOF3q9s/NOJaI7 UEq4lDyJfoi0z1NLMTCrYQDUcsfGYwNHvHckuvsMmhqy3Sunl+oooHn6KoEdNzzQwQ L0jfiQRNDOA4OqjYD7hO1uSmXwKZgh80yVioE0fA76ERU2aiI/I4eTNZcXnKm6oPtV rVZ/z3Y7Fm5Dw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-yoM4lum5pMqJYMLZKpEpzSr4x4
Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 08 Apr 2014 17:42:58 -0000

Here are comments on the latest version:

Section 1:

I had trouble parsing the following:

    Once it is known that both the offerer and the answerer supports the
    BUNDLE mechanism, a BUNDLE group and the associated BUNDLE addresses
    have been negotiated, each endpoint can assign its BUNDLE address to
    each "m=" line within, and use the address to send and receive all
    media associated with, the BUNDLE group.

I suggest:

    Once it is known that both the offerer and the answerer support the
    BUNDLE mechanism, and a BUNDLE group and the associated BUNDLE
    addresses have been negotiated, each endpoint can assign its BUNDLE
    address to each "m=" line within, and use the address to send and
    receive all media associated with, the BUNDLE group.

Later in the section, in the following:

    The procedures in this specification apply to a given BUNDLE group.

I suggest a change: s/apply/apply independently/

Section 2:

In the following:

    Offerer BUNDLE address: Within a given BUNDLE group, an IP address
    and IP port combination used by an offerer to send and receive all
    media associated with each "m=" line within the BUNDLE group.

    Answerer BUNDLE address: Within a given BUNDLE group, an IP address
    and IP port combination used by an answerer to send and receive all
    media associated with each "m=" line within the BUNDLE group.

I question the "to send and" in the above. In general with O/A the 
address is only for receive - there is no promise that media will also 
be sent from that address.

Then, in the following:

    Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer,
    associated with a BUNDLE group.

Is an m-line a bundled m-line if it is included in the a=group:bundle of 
the offer, but not in the answer???

IOW, for an offer do I determine if an m-line is bundled based on the 
a=group:bundle in the *offer*, or in the *answer*?

Section 5.2.1:

s/BUNDEL/BUNDLE/

Section 5.2.3:

This fits into the general format for documenting O/A. So this section 
specifically describes the processing of the first offer. (E.g., in the 
sip session.)

But this section is also used as *the* place to describe the initial 
offer that creates a BUNDLE group. That suggests that you can only 
create a bundle group within the first O/A of a sip session. Certainly 
that is not the intent. (A BUNDLE group can be first created in an offer 
that modifies an SDP session.)

I don't currently have a suggestion for how to fix this. It is hard!

Section 5.2.4.2:

In the last line of the following:

    When an answerer generates an SDP answer, it MUST select a BUNDLE
    address for the offerer, referred to as the offerer BUNDLE address.
    The answerer MUST select an address which the offerer in the
    associated SDP answer requested to be within the BUNDLE group.

s/answer/offer/

Section 5.2.6.2:

The following has some grammar problems:

    NOTE: If the offerer wants that the answerer selects the address
    associated with the added "m=" as the offerer BUNDLE address, the
    offerer suggested BUNDLE mid MUST represent the added "m=" line
    [Section 5.2.3.2].

I suggest:

    NOTE: If the offerer wants the answerer to select the address
    associated with the added "m=" as the offerer BUNDLE address, the
    offerer suggested BUNDLE mid MUST represent the added "m=" line
    [Section 5.2.3.2].

	Thanks,
	Paul