Subject: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2013 23:28:52 +0000

Hi,

Based on the decision in Vancouver to define the usage of port zero in 'bundle-only' m- lines, I've updated the new text I proposed some time ago.

One question that was raised in Vancouver is whether we will have to update RFC 3264, so I've added a new OPEN ISSUE (13) for that.

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

7.  SDP 'bundle-only' Attribute

7.1.  General

   This section defines a new SDP media-level attribute [RFC4566],
   'bundle-only'.  The attribute is used, in an SDP Offer, to indicate
   that an "m=" line, to which the attribute has been assigned, within a
   BUNDLE group is only to be accepted if the Answerer in the SDP Answer
   keeps the "m=" line within the BUNDLE group.

7.2.  SDP Offer/Answer Procedures

7.2.1.  SDP Offer Procedures

   When an Offerer sends an SDP Offer, which contains a BUNDLE group, it
   can assign an SDP 'bundle-only' attribute to an "m=" lines within
   with the BUNDLE group, in order to request that the Answerer only
   accepts the "m=" line if is kept within the BUNDLE group.

   The Offerer can assign a 'bundle-only' attribute to any number of
   "m=" lines within a BUNDLE group.  The Offerer MUST NOT assign a
   'bundle-only' attribute to an "m=" line that is not within a BUNDLE
   group.

   If the Offerer, for the given SDP session, has not received an SDP
   Answer indicating that the Answerer supports the BUNDLE mechanism,
   the Offerer MUST in the SDP Offer assign a zero port value to any
   "m=" line to which it assigns a 'bundle-only' attribute.  This will
   ensure that the Answerer, if it does not support the BUNDLE
   mechanism, will reject such "m=" line.

   As described in Section 6.4.3, once the Offerer has received an SDP
   Answer, indicating that the Answerer supports the BUNDLE mechanism,
   the Offerer can assign a shared address to an "m=" line within a
   BUNDLE group.  This also applies to "m=" lines to which the Offerer
   has assigned a 'bundle-only' attribute.

   If the Offerer, in a subsequent SDP Offer, wants to ensure that an
   "m=" line is rejected unless it is kept within the BUNDLE group, it
   MUST assign a 'bundle-only' attribute to such "m=" line.  Otherwise
   the Offerer MUST NOT assign a 'bundle-attribute' to such "m=" line.

   If the Offerer, in a subsequent SDP Offer, wants to move an "m=" line
   out of a BUNDLE group Section 6.4.5, it MUST NOT assign a 'bundle-
   only' attribute to such "m=" line.

   If the Offerer, in a subsequent SDP Offer, wants to disable an "m="
   line in a BUNDLE group Section 6.4.6, it MUST NOT assign a 'bundle-
   only' attribute to such "m=" line.

7.2.2.  SDP Answer Procedures

   When the Answerer determines the BUNDLE address for the Offerer
   Section 6.5.1, it also takes any "m=" line to which the Offerer has
   assigned a 'bundle-only' attribute into consideration.

   If the Offerer has assigned a 'bundle-only' attribute, and a zero
   port value, to an "m=" line, and if the Answerer accepts the "m="
   line, it follows the procedures in section Section 6.5.1.

   If the Offerer has assigned a 'bundle-only' attribute, and a non-zero
   port value, to an "m=" line, it is an indication that the Offerer
   wants to disable the "m=" line Section 6.4.6.  The Answerer MUST in
   the SDP Answer assign a zero port value to such "m=" line
   Section 6.5.4.

   If the Answerer chooses to not keep an "m=" line, to which the
   Offerer has assigned a 'bundle-only' attribute, within a BUNDLE
   group, the Answerer MUST reject the "m=" line Section 6.5.4.

   An Answerer MUST NOT assign a 'bundle-only' attribute to an "m="
   lines in an SDP Answer.

   OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answer
   to a zero port value in an SDP Offer.  As we now allow a non-zero
   value in the SDP Answer, do we need to update 3264 procedures?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Nov 2013 09:08:36 -0800

> One question that was raised in Vancouver is whether we will have to update RFC 3264, so I've added a new OPEN ISSUE (13) for that.
...
>     value in the SDP Answer, do we need to update 3264 procedures?

Why is this a question. Section 8.2 of 3264 clearly states this, and we 
propose to do otherwise. So that means a revision is required.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 17:26:53 +0000

Hi,

> Why is this a question. Section 8.2 of 3264 clearly states this, and we propose to do otherwise. So that means a revision is required.

It is a question because we decided in Vancouver that we need to figure out what/how to do.

However, I guess the question is not IF, but HOW, we will update 3264. Will BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc etc etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Nov 2013 09:35:23 -0800

> However, I guess the question is not IF, but HOW, we will update 3264. Will BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc etc etc.

Right.

I doubt we want to do a 3264bis at this time.
The most straightforward thing is to simply put an explicit statement in 
this draft that it is updating 3264 in this way as a narrow exception, 
and mark the draft as "updates 3264".

And then you can ask the chairs of sipcore to review this. :-)

	Thanks,
	Paul