Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May)
Eric Rescorla <ekr@rtfm.com> Sat, 01 June 2013 14:47 UTC
Return-Path: <ekr@rtfm.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 6860C21F9DF9 for <mmusic@ietfa.amsl.com>; Sat, 1 Jun 2013 07:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.792
X-Spam-Level:
X-Spam-Status: No, score=-96.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I2KGaKY2lfE for <mmusic@ietfa.amsl.com>; Sat, 1 Jun 2013 07:47:05 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41C21F9DFD for <mmusic@ietf.org>; Sat, 1 Jun 2013 07:46:57 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id l11so1362559qcy.37 for <mmusic@ietf.org>; Sat, 01 Jun 2013 07:46:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=jE8uU4EezcWeqQFKXeDDo8Ns4vUD3SWsXcCJerR8GLQ=; b=lYVgOYQeZ223Yd466oLuV0TDie+LVe50UsNnfX8R4ZhdG7358nbrgKTbg1WA8Qtkui dd+mgt8pbOlWqrNMkxDPkB28XccnIJdFBN3/eo8kEoNz6eVAbsUct6bRYzUvJYSkWQ+F 6dF6/AXQ2LMu08KrrTWjpCVClw3PGzwmQhrAfETJgU9mc6vxLd6K3z+298ixDeUlPkfA IEW5CrXWDn8ltxo05RFL0SiJjGK1eH9oB+KgdMSKvjDbg0tcJIecQnG2SeZXuf/QD3Pc vY4F2/E82xa7QTYOeOzaKeP8ZwaxbAf51m291bI+BjyC0NudkG+optu5Cenm3S4OHckV RXug==
X-Received: by 10.224.174.138 with SMTP id t10mr11932670qaz.99.1370098016477; Sat, 01 Jun 2013 07:46:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.41.131 with HTTP; Sat, 1 Jun 2013 07:46:16 -0700 (PDT)
X-Originating-IP: [64.88.227.134]
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11352446E@xmb-aln-x02.cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11352446E@xmb-aln-x02.cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 01 Jun 2013 07:46:16 -0700
Message-ID: <CABcZeBOq+h1S7kUftQ0K=9eBo-oA6nEWMa7czWWO9kLrvx97tg@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="20cf30334e03947af704de18cd78"
X-Gm-Message-State: ALoCoQm5NEpfQLYPRqAHPCYleCqeoJQ953MpDtQAQO+DrVQyFSm/fwvEGbSW5kVuimBxQo2UOcdk
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May)
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: Sat, 01 Jun 2013 14:47:09 -0000
6.4. Answerer Procedures 6.4.1. General This section describes how an Answerer, when it receives an SDP Offer including a BUNDLE group, generates the associated SDP Answer. When an Answerer receives an SDP Offer which includes a BUNDLE group, and the Answerer accepts the offered BUNDLE group, the Answerer MUST generate an SDP Answer according to the procedures in Section 6.1 and this section. 6.4.2. RFC 5888 restrictions Based on the rules and procedures in RFC 5888, the following restrictions also apply to BUNDLE groups in SDP Answers: o 1) A BUNDLE group must not be added to an SDP Answer, unless the same BUNDLE group was included in the associated SDP Offer; and o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP Answer, unless it in the associated SDP Offer was included in the same BUNDLE group. 6.4.3. Offerer Bundle Address Selection In the SDP Answer, the Answerer selects the bundle address for the Offerer, based on the address information received in the associated SDP Offer, using the mid value. The mid value associated with the "m=" line in the SDP Offer that represents the bundle address MUST in the SDP Answer be located first in the mid value list added to SDP group:BUNDLE attribute associated with the BUNDLE group. I am having trouble reading this text. Is this supposed to say that the answerer should choose the transport parameters from one of the m-lines and put the mid associated with those parameters first in the group:BUNDLE attribute he sends? From the associated SDP Offer, the Answerer SHOULD choose the bundle address associated with the mid value located first in the mid value list included in the SDP group:BUNDLE attribute associated with the BUNDLE group, unless: Is there a reason to make this a SHOULD rather than MUST? The conditions below don't really seem to be judgement calls. I may have missed some discussion on this, but why not say MUST use the first mid associated with a non-zero m-line? o 1) The mid value represents an "m=" line with a port zero value in the SDP Offer; or o 2) The mid value represents an "m=" line with a port zero value in the SDP Answer. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. 6.4.4. Answerer Bundle Address Selection In the SDP Answer, the Answerer selects its local bundle address. Each "m=" line included in a BUNDLE group MUST contain identical address information. The only exception is the usage of a zero port value for an "m=" line, which is allowed eventhough another port value number is used for other "m=" lines in the BUNDLE group. A forward reference to 6.4.5 would be nice here. Or maybe just merge it in. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. In a subsequent SDP Answer, the Answerer MAY change its local bundle address, as long as each "m=" line included the BUNDLE group contain identical address information. For a given BUNDLE group, the Answerer MUST NOT assign the bundle address to "m=" lines that are not included the BUNDLE group, or to "m=" lines that are included in another BUNDLE group. 6.4.5. Rejecting A BUNDLE Media Description When generating the SDP Answer, if the Answerer wants to reject media associated with an "m=" line in the BUNDLE group, it will add a zero port number value to the "m=" line, according to the procedures defined in RFC 3264. OPEN ISSUE: It is FFS whether it is allowed to include a port zero media descriptions in a BUNDLE group. 6.4.6. Removing a media description from a BUNDLE group When generating the SDP Answer, if the Answerer wants to remove an "m=" line from a BUNDLE group (without rejecting the "m=" line),it MUST NOT include the "m=" line in a BUNDLE group. In addition, the SDP Answer MUST not add its local bundle address to the "m=" line. An Answerer MUST NOT, in the SDP Answer, remove an "m=" line from a BUNDLE group, unless the "m=" line had unique address information in the associated SDP Offer. NOTE: The reason for the restriction above is that, if the "m=" line would be removed from the BUNDLE group, the address information would be identical to the "m=" lines remaining in the BUNDLE group. OPEN: The decision for allowing a media description with port zero values inside a BUNDLE group is pending on update for RFC 5888. I thought we had agreed to no bundle splitting. On Thu, May 30, 2013 at 10:37 AM, Cullen Jennings (fluffy) <fluffy@cisco.com > wrote: > > Looks good to me > > On May 29, 2013, at 5:39 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > Based on the e-mail and interim discussions, I’ve tried together some > ”Answerer Procedures” text for BUNDLE. > > > > For now, I would request that people mainly focus on the technical > stuff, and if some text is unclear. I WILL align the usage of “m=” line and > “media description” :) > > > > Also note that examples will be added later. > > > > Regards, > > > > Christer > > > > ----------------------------------------------------- > > > > > > 6.4. Answerer Procedures > > > > 6.4.1. General > > > > This section describes how an Answerer, when it receives an SDP Offer > > including a BUNDLE group, generates the associated SDP Answer. > > > > When an Answerer receives an SDP Offer which includes a BUNDLE group, > > and the Answerer accepts the offered BUNDLE group, the Answerer MUST > > generate an SDP Answer according to the procedures in Section 6.1 and > > this section. > > > > 6.4.2. RFC 5888 restrictions > > > > Based on the rules and procedures in RFC 5888, the following > > restrictions also apply to BUNDLE groups in SDP Answers: > > > > o 1) A BUNDLE group must not be added to an SDP Answer, unless the > > same BUNDLE group was included in the associated SDP Offer; and > > > > o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP > > Answer, unless it in the associated SDP Offer was included in the > > same BUNDLE group. > > > > 6.4.3. Offerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects the bundle address for the > > Offerer, based on the address information received in the associated > > SDP Offer, using the mid value. The mid value associated with the > > "m=" line in the SDP Offer that represents the bundle address MUST in > > the SDP Answer be located first in the mid value list added to SDP > > group:BUNDLE attribute associated with the BUNDLE group. > > > > From the associated SDP Offer, the Answerer SHOULD choose the bundle > > address associated with the mid value located first in the mid value > > list included in the SDP group:BUNDLE attribute associated with the > > BUNDLE group, unless: > > > > o 1) The mid value represents an "m=" line with a port zero value in > > the SDP Offer; or > > > > o 2) The mid value represents an "m=" line with a port zero value in > > the SDP Answer. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > 6.4.4. Answerer Bundle Address Selection > > > > In the SDP Answer, the Answerer selects its local bundle address. > > Each "m=" line included in a BUNDLE group MUST contain identical > > address information. The only exception is the usage of a zero port > > value for an "m=" line, which is allowed eventhough another port > > value number is used for other "m=" lines in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > In a subsequent SDP Answer, the Answerer MAY change its local bundle > > address, as long as each "m=" line included the BUNDLE group contain > > identical address information. > > > > For a given BUNDLE group, the Answerer MUST NOT assign the bundle > > address to "m=" lines that are not included the BUNDLE group, or to > > "m=" lines that are included in another BUNDLE group. > > > > 6.4.5. Rejecting A BUNDLE Media Description > > > > When generating the SDP Answer, if the Answerer wants to reject media > > associated with an "m=" line in the BUNDLE group, it will add a zero > > port number value to the "m=" line, according to the procedures > > defined in RFC 3264. > > > > OPEN ISSUE: It is FFS whether it is allowed to include a port zero > > media descriptions in a BUNDLE group. > > > > 6.4.6. Removing a media description from a BUNDLE group > > > > When generating the SDP Answer, if the Answerer wants to remove an > > "m=" line from a BUNDLE group (without rejecting the "m=" line),it > > MUST NOT include the "m=" line in a BUNDLE group. In addition, the > > SDP Answer MUST not add its local bundle address to the "m=" line. > > > > An Answerer MUST NOT, in the SDP Answer, remove an "m=" line from a > > BUNDLE group, unless the "m=" line had unique address information in > > the associated SDP Offer. > > > > NOTE: The reason for the restriction above is that, if the "m=" line > > would be removed from the BUNDLE group, the address information would > > be identical to the "m=" lines remaining in the BUNDLE group. > > > > OPEN: The decision for allowing a media description with port zero > > values inside a BUNDLE group is pending on update for RFC 5888. > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th M… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Kevin Dempsey
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Cullen Jennings (fluffy)
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Eric Rescorla
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29… Cullen Jennings