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

Christer Holmberg <> Sun, 02 June 2013 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD2621F90EE for <>; Sun, 2 Jun 2013 11:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.426
X-Spam-Status: No, score=-5.426 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id miP532Qxm121 for <>; Sun, 2 Jun 2013 11:33:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D381221F90CD for <>; Sun, 2 Jun 2013 11:33:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-48-51ab8fec2b9b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id CF.37.18006.CEF8BA15; Sun, 2 Jun 2013 20:33:16 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 20:33:16 +0200
From: Christer Holmberg <>
To: Eric Rescorla <>, "Cullen Jennings (fluffy)" <>
Thread-Topic: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May)
Thread-Index: Ac5cYL6Xjkqad1ozQWuoyGt6QctbSAA6uR4AAF6XlAAAPeC20A==
Date: Sun, 02 Jun 2013 18:33:15 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3812FBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre6b/tWBBks/m1iseH2O3aJjMpvF 1OWPWRyYPab83sjqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyXr7rZi941M1YsXvWTJYG xomVXYwcHBICJhKnHkl2MXICmWISF+6tZwOxhQQOM0rM7U/tYuQCshczSmy53s0GUs8mYCHR /U8bpEZEIFBi6oTJLCBhZgF1iauLg0BMYQFHiYb3UBVOEk9/rWGHsdvuHAKbziKgIrFi0UEw m1fAV6LxyWMmiE3XGSUW3jwA1sAJNH7BgcMsIDYj0GnfT61hArGZBcQlPhy8zgxxsoDEkj3n oWxRiZeP/7FC2EoSjUuesELU50v8ePaTCWKZoMTJmU9YJjCKzkIyahaSsllIyiDiOhILdn9i g7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HKjTYzACDu45bfqDsY750QOMUpzsCiJ8+rx Lg4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJi64LjEs63WRw+n37sUf3xps4Dvz9QsKfc3 GrV2tUWL2OQjCyZu3hCh3P36fsziD+sk1uxk/MZ7cXEqg/Lm87y/a+vcFs7/tPDF31OvOH+b Mex99N1h0iyFlbdrf/zSuPK1xH+u8DvzvONnCubGn532dZPi6TnRDUdXtd1foHZPM0pw/kzh GRN3KbEUZyQaajEXFScCAA7Vf3p+AgAA
Cc: "" <>
Subject: Re: [MMUSIC] BUNDLE TEXT: Answerer Procedures (29th May)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Jun 2013 18:33:29 -0000


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?

Actually,  the text (and the conditions) probably needs some re-wording, because I mostly had the initial offer in mind.

But, assume an updated offer, where the first m- line is changed from zero to a non-zero value ("taken back into use") - which is different from the current bundle address. The answerer may want to keep the current offerer bundle address.

However, this also depends on whether an m- line that is taken back into use is allowed to have another address than the current bundle address to begin with. I'll discuss that in the SDP Offer section.


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.

I can add a forward reference for now. I think we should wait with the cosmetics until we have the new version of the draft available.


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.

I am not sure what you mean by "splitting", but this is not about moving an m- line from one BUNDLE group to another BUNDLE group, but to move it outside an BUNDLE group all together. People wanted to allow that in the case where the Offer contains different ports, but if you disagree we need to discuss it further.