Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Feb 2013 19:50:21 +0000

Hi,

I've submitted a new version (-03) of BUNDLE.

Based on discussions with Cullen, and exchange of the concerns we had with the different port alternatives (different-ports vs identical-port), this version now describes a mechanism where both alternatives more or less are combined. When the first BUNDLE offer is sent, and it is now known whether the answerer supports BUNDLE (or, even identical ports), different ports are used (read: the one-rtp alterntaive). Once BUNDLE answer has been received, a new offer, with identical port numbers, is sent.

We think that having to send a second offer is not going to increase complexity and delay, because in many use-cases subsequent offer(s) will be sent anyway. For example, RTCWEB entities will do it because of ICE.

Cullen has also been added as co-author.

Now, we do realize that there are still issues that have to be described, and hopefully we will be able to focus on those from now on, but our wish is that this proposal will unite the different "port camps" :)

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 20 Feb 2013 00:16:03 +0530

Hi Christer,

The updated draft looks good as 
1) The different port is passed in the offer which reduces interop issue
with most of the SIP devices. 
2) The mechanism allows to select same port and different port in the
answerer side

My comments & clarification queries are as follows:

1) The details Multiple answer for single bundled offer is not clear in the
draft. The multiple answer may be due to SIP forking or WebRTC FedEx usecase
sort of scenario. 
2) Whether it is allowed in answerer side to generate new offer before
receiving the identical port new offer from offerer? It is allowed from RFC
3264 perspective.
3) Open issue #2 in Sec 6.2: Please explain the side-effect in case bundle
is done in the middle of the session.
4) Nits in Sec 8.2 para 2 Line 2: "generates an SDP" instead of "generates
and SDP"

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Tuesday, February 19, 2013 1:20 AM
> To: [email-masked]
> Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-
> negotiation-03
> 
> 
> Hi,
> 
> Based on discussions with Cullen, and exchange of the concerns we had
> with the different port alternatives (different-ports vs identical-
> port), this version now describes a mechanism where both alternatives
> more or less are combined. When the first BUNDLE offer is sent, and it
> is now known whether the answerer supports BUNDLE (or, even identical
> ports), different ports are used (read: the one-rtp alterntaive). Once
> BUNDLE answer has been received, a new offer, with identical port
> numbers, is sent.
> 
> We think that having to send a second offer is not going to increase
> complexity and delay, because in many use-cases subsequent offer(s)
> will be sent anyway. For example, RTCWEB entities will do it because of
> ICE.
> 
> Now, we do realize that there are still issues that have to be
> described, and hopefully we will be able to focus on those from now on,
> but our wish is that this proposal will unite the different "port
> camps" :)
> 
> Regards,
> 
> Christer
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Feb 2013 19:12:00 +0000

Hi Partha,

>draft. The multiple answer may be due to SIP forking or WebRTC FedEx usecase

With "Multiple answer", do you mean answers received on different early dialogs? If so, each answer will be handled separately, and a new offer has to be sent on each early dialog (assuming the answer indicated support of BUNDLE).

>receiving the identical port new offer from offerer? It is allowed from RFC

I see no reason to forbid it. However, in order to prevent a race condition, maybe we should recommend that the answerer side does not generate an offer by itself, until it has received the single-port offer?

>is done in the middle of the session.

I am not sure I understand what you mean by "side-effect"?

>4) Nits in Sec 8.2 para 2 Line 2: "generates an SDP" instead of "generates and SDP"

Will be fixed :)

Thanks!

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 20 Feb 2013 23:10:19 +0530

Hi Christer,

The main usecase for "Multiple answer" is different answer in early
dialog/dialog (SIP forking). It is possible to see each answer as a separate
dialog (offer-answer) in case the applicability of the bundle draft is RFC
3261(SIP).  As per this draft applicability is currently RFC 3264
(offer-answer), So, is there a need to define/clarify about the higher
aggregation like (early) dialog for handling "multiple answer" within bundle
negotiation?

Please read inline for more comments.

Thanks
Partha

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2013 12:42 AM
> To: Parthasarathi R; [email-masked]
> Subject: RE: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-
> negotiation-03
> 
> 
> Hi Partha,
> 
> With "Multiple answer", do you mean answers received on different early
> dialogs? If so, each answer will be handled separately, and a new offer
> has to be sent on each early dialog (assuming the answer indicated
> support of BUNDLE).
> 
> I see no reason to forbid it. However, in order to prevent a race
> condition, maybe we should recommend that the answerer side does not
> generate an offer by itself, until it has received the single-port
> offer?
<Partha> I agree with you. Could you please add the recommendation in the
next revision </Partha>

> I am not sure I understand what you mean by "side-effect"?
<Partha> I'm not seeing any issue in modify the bundle negotiation after the
session is established. IMO, the bundle should be allowed in the middle of
the session. I'm asking any known side-effect in case bundle is done in the
middle of the session </Partha>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2013 12:47:28 -0500

> <Partha> I agree with you. Could you please add the recommendation in the

IMO this is a bad idea.

The UAS may not be able to wait, or it may complicate the programming to 
wait.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Feb 2013 20:03:08 +0000

Hi Partha,

>aggregation like (early) dialog for handling "multiple answer" within bundle

I have difficulties to understand what you are asking. There is no such thing as "multiple answer" in RFC 3264. There is an offer, followed by an answer. 

>>>receiving the identical port new offer from offerer? It is allowed
>>>from RFC 3264 perspective.
>>>

We can discuss such details later (and I noted that Paul has another opinon :), but first I would like to know whether the WG on a high level can agree on moving forward with this :)

>>>3) Open issue #2 in Sec 6.2: Please explain the side-effect in case
>>>bundle is done in the middle of the session.
>>

I can't think of any side-effects.

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 21 Feb 2013 05:42:26 +0000

Hi Christer,

I read the draft and I think it is a good step forward. I like the overall approach and think it can work. I do have questions about some of the specifics, and also some suggested changes and additions.

1) In section 1, the 4th paragraph ends as follows:

   The port number
   value associated with the first "m=" line associated with the
   "BUNDLE" group represents the port value number offered to be used in
   the single 5-tuple.

I think this is no longer necessary per the rules in section 6.1, and it should be removed.

2) Section 2 says the following about RTCP:

   Bundled media: Two or more RTP streams using a single 5-tuple.  The
   RTCP streams associated with the RTP streams also use a single
   5-tuple, which might be the same, but can also be different, as the
   one used by the RTP streams.

This is contradicted by section 6.1, which says the SDP offer MUST
   o  5.  Insert an SDP 'rtpc-mux' attribute.

So one of these needs to be changed, and replace 'rtpc-mux' with 'rtcp-mux' :)

3)   OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate
   that "m=" lines must be grouped in the same way in the SDP Answer as
   they are grouped in the SDP Offer?

I'd say yes, because otherwise you are not sure if something is wrong (e.g. an intermediary has changed the ports, or something does not really understand bundle). I think if the ports in the SDP answer are not grouped the same as in the offer, it should be interpreted as a failure to bundle, and another offer should be sent to use different ports.

4) I do not understand the intent of the following text in section 6.2:

   However, if the "m=" lines associated with the "BUNDLE"
   group contain different port number values (i.e. the SDP Offer is
   generated until it is known whether the SDP Answerer supports the
   "BUNDLE" grouping extension) the SDP Offerer MUST NOT set the port
   number value of the first "m=" line associated with the "BUNDLE"
   group to zero.

Perhaps there is a typo, but in any case, I do not think the first "m=" lines needs to be treated specially any more. This is similar to comment (1).

5)   OPEN ISSUE #2: If the session has been established without BUNDLE, do
   we allow BUNDLE to be enabled later during the session?

Yes, but need to use different ports until it is known that both offerer and answerer support bundle.

6)   OPEN ISSUE #3: If the session has been established with BUNDLE, do we
   allow BUNDLE to be disabled later during the session, meaning that

Yes, for failure recovery. 

7) Section 6.3 ends as follows:

   Until the SDP Answerer receives the new SDP Offer, which contains an
   identical port number value for each "m=" line associated with a
   "BUNDLE" group, it MUST use the port, and related information (ICE
   candidates, SDES keys etc) associated with the first "m=" line in the
   "BUNDLE" group.

I think the SDP Answerer needs to wait for the next offer and not assume the first "m=" line contains the port to be used for the bundle.

8) Section 10

The SDP Answer shows the same port being used in the "m=" lines. I was thinking this first answer would use different ports, and only if there is another offer/answer exchange would both the offer and the answer switch to using the same port.

Cheers,
Charles

> Sent: Monday, February 18, 2013 11:50 AM
> To: [email-masked]
> with the different port alternatives (different-ports vs identical-port), this
> version now describes a mechanism where both alternatives more or less
> are combined. When the first BUNDLE offer is sent, and it is now known
> whether the answerer supports BUNDLE (or, even identical ports), different
> ports are used (read: the one-rtp alterntaive). Once BUNDLE answer has
> been received, a new offer, with identical port numbers, is sent.
> 
> complexity and delay, because in many use-cases subsequent offer(s) will
> be sent anyway. For example, RTCWEB entities will do it because of ICE.
> 
> Now, we do realize that there are still issues that have to be described, and
> hopefully we will be able to focus on those from now on, but our wish is
> that this proposal will unite the different "port camps" :)
> 
> Regards,
> 
> Christer