Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May)

Kevin Dempsey <kevindempsey70@gmail.com> Thu, 30 May 2013 08:18 UTC

Return-Path: <kevindempsey70@gmail.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 10F6021F97E2 for <mmusic@ietfa.amsl.com>; Thu, 30 May 2013 01:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001]
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 P8+t3UAyE+3y for <mmusic@ietfa.amsl.com>; Thu, 30 May 2013 01:18:46 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03421F980E for <mmusic@ietf.org>; Thu, 30 May 2013 01:18:28 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hn14so4242669wib.7 for <mmusic@ietf.org>; Thu, 30 May 2013 01:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SLXcIaQAw9ujiskptr3XrIHDZqLU0pz2dWUjJLbslcI=; b=FBFpXbhou9GtxqVPyJ2JCRtudBftErLeMSB79erp5VbHZE0V3HG5h8vV8nA6rpgroA 6fz+GCLzvJBLRq125e5N6F8uazmsFHAtCQfX2vPcYMZ3joqRwQbqL/urGIKVbPgmqe0y 1jrfQje/CFrRoB1ewDXgWJyc+p1uKlJGo6hjcwuNZWwP+gl6rCDrZdiiT8yvL1V2SdgQ +Qmutkx69Q7P8OOADeA8QWnwEsa26rMY07H6+qI1or666DpvEDV4AQBt3huS5eLr2pST jzLcwX2mgKUmtimVBZBm8/ml+0BJNop1j2xE9ouPZ188a8DqR2EXrnR5H13yX7PiRTzu fTyQ==
MIME-Version: 1.0
X-Received: by 10.180.185.225 with SMTP id ff1mr3390778wic.36.1369901907676; Thu, 30 May 2013 01:18:27 -0700 (PDT)
Received: by 10.180.146.196 with HTTP; Thu, 30 May 2013 01:18:27 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37CFE4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C37B973@ESESSMB209.ericsson.se> <51A60F50.9020902@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C37CFE4@ESESSMB209.ericsson.se>
Date: Thu, 30 May 2013 09:18:27 +0100
Message-ID: <CAMvTgccVOPVjxN7BoV7tYfcwrsUcUXx8LdcVrss2ZfmV-m7Xgg@mail.gmail.com>
From: Kevin Dempsey <kevindempsey70@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a11c34ed29591e404ddeb247f"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Thu, 30 May 2013 08:18:49 -0000

Can we add that the answerer must also ensure that it can de-mulitplex the
media it will receive? That is, it must either agree to a de-mulitplex
scheme that was offered (either in the SDP, such as SSRC signalling,  or
external signalling) or ensure that there is no PT overlap in the bundle by
not including certain PTs or by unbundling one or more m-lines.


On 30 May 2013 07:27, Christer Holmberg <christer.holmberg@ericsson.com>wrote:

> Hi,
>
> > This seems good to me, pending polishing the language.
> >
> > I trust when you say "address information" you mean:
> > - the port in the m-line
> > - the address in the c-line
> > - associated ICE information
> >
> > Obviously it would be cumbersome to mention all of that each time you
> need to refer to address information. So I'm expecting you will coin a term
> (e.g., "address information") and provide a definition of it.
>
> Yes. There is going to be a separate section which describes that more in
> detail.
>
> Thanks!
>
> Regards,
>
> Christer
>
>
>
>
> On 5/29/13 7:39 AM, Christer Holmberg 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 mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>