Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 - Paul's comments

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 09 April 2014 07:22 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 4A1431A0122 for <mmusic@ietfa.amsl.com>; Wed, 9 Apr 2014 00:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level:
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 Jdq17hzjpAvR for <mmusic@ietfa.amsl.com>; Wed, 9 Apr 2014 00:22:14 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5091A0023 for <mmusic@ietf.org>; Wed, 9 Apr 2014 00:22:13 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f328e0000012ab-6f-5344f524658e
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.F2.04779.425F4435; Wed, 9 Apr 2014 09:22:12 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 09:22:12 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, IETF MMUSIC WG <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 - Paul's comments
Thread-Index: Ac9TwY60zFbh/6gBR0CQjgdTUqhFTw==
Date: Wed, 09 Apr 2014 07:22:11 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B6381@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvja7KV5dgg1+P1CymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj6G2pgkNqFT83X2RrYLwp28XIySEhYCJx YutcNghbTOLCvfVgtpDAYUaJtyeLuxi5gOzFjBLv+x8AJTg42AQsJLr/aYPUiAh4SZz4exqs XlggUeL1pzY2iHiSxPrZK5lAykUE9CQe/MsFCbMIqEh0n2oFK+EV8JV4+raFGcRmBFr7/dQa JhCbWUBc4taT+UwQ5whILNlznhnCFpV4+fgfK4StJPFjwyUWiHodiQW7P7FB2NoSyxa+ZoaY LyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS833MQIDOqDW37r7mA8dU7kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhnr+bOtzkfaZXJuoS7eX1256H5 feusfvstM3/Ky6t16/ia0y+TpXsbWp7k6206W1b+Z46UyuHChn+PY06JFczPF80q/hKTf73n 2Ua7SBahD2bpV9NE1kfMLqhns1E7M0n+b/ed0hIznlDvf9oRBpuFm+YcPMwTHylxIOmxhrPv /F35blxfVyixFGckGmoxFxUnAgAr8gO5OAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YUe2LKEUoBNhVlYPeWSU7t2BvKA
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 - Paul's comments
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: Wed, 09 Apr 2014 07:22:17 -0000

Hi Paul,

Thanks for your comments! See inline.

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

I don't think we even need to say "Once it is known that both the offerer and the answerer support the BUNDLE mechanism". Because, if both endpoints don't support BUNDLE, they will not negotiate a BUNDLE group etc.

So, maybe something like:

	"Once the offerer and the answerer have negotiated a BUNDLE group, and the associated BUNDLE addresses, 
	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/

Ok.

------------

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

Ok.

------------

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

Note that the text talk about an "m=" line being associated with a BUNDLE group. So, if the BUNDLE group hasn't been created yet, the "m=" line isn't considered being bundled.

------------

>Section 5.2.1:
>
>s/BUNDEL/BUNDLE/

Ok.

------------

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

I tried to cover that in section 2:

	"Initial SDP offer: The first SDP offer, in which the offerer
   	indicates that it wants to create a given BUNDLE group."

Maybe we could say:

"The first SDP offer, within an SDP session, in which..."

...to make it more clear that it does not necessarily have to be the first offer within the SDP session.

------------

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

Ok.

------------

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

Ok.

Regards,

Christer