Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

"Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com> Wed, 12 June 2013 16:33 UTC

Return-Path: <thomas.belling@nsn.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 97EC221F998A for <mmusic@ietfa.amsl.com>; Wed, 12 Jun 2013 09:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level:
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
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 ex21V8NmyQhX for <mmusic@ietfa.amsl.com>; Wed, 12 Jun 2013 09:33:02 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E97FB21F9989 for <mmusic@ietf.org>; Wed, 12 Jun 2013 09:32:58 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5CGWv9s002996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 18:32:57 +0200
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5CGWuOC030602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 18:32:56 +0200
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Jun 2013 18:32:56 +0200
Received: from DEMUMBX001.nsn-intra.net ([169.254.1.137]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 12 Jun 2013 18:32:56 +0200
From: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
To: ext Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th)
Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9AAFMMPQ
Date: Wed, 12 Jun 2013 16:32:54 +0000
Message-ID: <BDBE1A97E84675488F72A48C23811F350F2FAB@DEMUMBX001.nsn-intra.net>
References: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C388BD8@ESESSMB209.ericsson.se>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.103]
Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F350F2FABDEMUMBX001nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 30095
X-purgate-ID: 151667::1371054777-000017BA-A0B57C67/0-0/0-0
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)
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: Wed, 12 Jun 2013 16:33:11 -0000

Dear Christer,

only some comments on the terminology:

"When an Offerer rejects an "m=" line in a BUNDLE group ..."
I am used to terminology where an answerer "rejects" something that is being offered, but is unclear what this means for an offerer.
I assume what you are after is "disabling" an m-line. Perhaps this terminology would be clearer?

You also speak about "Removing A Media Description From A BUNDLE Group".
I see a certain risk that people misunderstand this to also mean "disabling" an m-line.
I assume what you are after is rather "Moving A Media Description out of a BUNDLE Group". Perhaps this terminology would be clearer?

Regards, Thomas


From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)




6.2.4.  Removing A Media Description From A BUNDLE Group

   When an Offerer removes an "m=" line from a BUNDLE group, the Offerer
   MUST assign a unique address to the "m=" line that is removed.  In
   addition, the Offerer MUST NOT place the mid value that was
   previously defined for the "m=" line in the SDP group:BUNDLE
   attribute mid value list associated with the BUNDLE group.

   To the other "m=" lines (that previously have been added to the
   BUNDLE group), the Offerer assigns addresses according to the
   procedures in Section 6.2.1.

   Example: The example shows a BRO, where an "m=" line is removed from
   a BUNDLE group.  The Offerer removes the mid ("zen") associated with
   the "m=" line from the SDP group:BUNDLE attribute mid value list, and
   assigns a unique address to the removed "m=" line.

   Example: The example shows an SDP Offer, where an "video" "m=" line
   (previously identified by the "zen" mid value), is removed from a
   BUNDLE group.  The Offerer assigns a unique address to the "m=" line,
   and the bundle address to each of the remaining "m=" lines in the
   BUNDLE group.


   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=video 40000 RTP/AVP 60
       b=AS:1000
       a=rtpmap:60 H261/90000



6.2.5.  Rejecting A Media Description In A BUNDLE Group

   When an Offerer rejects an "m=" line in a BUNDLE group, the Offerer
   MUST assign a unique address, with a zero port value [RFC3264], to
   the "m=" line that is rejected.  In addition, the Offerer MUST NOT
   place the mid value that was previously defined for the "m=" line in
   the SDP group:BUNDLE attribute mid value list associated with the
   BUNDLE group.

   To the other "m=" lines (that previously have been added to the
   BUNDLE group), the Offerer assigns addresses according to the
   procedures in Section 6.2.1.

   Example: The example shows an SDP Offer, where an "video" "m=" line
   (previously identified by the "zen" mid value), is rejected, and
   removed from a BUNDLE group.  The Offerer assigns a unique address,
   with a zero port value, to the "m=" line, and the bundle address to
   each of the remaining "m=" lines in the BUNDLE group.


   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=video 0 RTP/AVP 60
       a=rtpmap:60 H261/90000