Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 25 Feb 2013 23:35:49 +0000

Hi All,
I updated my BUNDLE alternatives draft to include the discussion from last week's call with some added tweaks to try to address comments/discussion so far.  Please consider this version.

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 25, 2013 5:29 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt

A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-01.txt
has been successfully submitted by Richard Ejzak and posted to the IETF repository.

Filename:	 draft-ejzak-mmusic-bundle-alternatives
Revision:	 01
Title:		 Alternatives to BUNDLE
Creation date:	 2013-02-26
Group:		 Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-bundle-alternatives-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ejzak-mmusic-bundle-alternatives
Htmlized:        http://tools.ietf.org/html/draft-ejzak-mmusic-bundle-alternatives-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-bundle-alternatives-01

Abstract:
   This paper discusses some potential modifications to the BUNDLE
   proposal for multiplexing of multiple media types within a single
   5-tuple to address limitations of the current proposal and
   alternatives already considered by MMUSIC.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Feb 2013 18:39:02 +0000

Hi Richard,

A few comments on the -01 version.

----------

Section 1:

Q1: You say that, if the first line of the offer is rejected, and one has to wait for the second offer, it may cause a setup time delay. There may be cases where the application doesn't want to session to succeed in the first place in that case, so we can have text which recommends adding an "essential" (if available) m- line first. Typically I guess it would be an audio m- line.

----------

Section 2:

Q2: You indicate, that if an empty re-INVITE is sent to the WebRTC client, it will create a BUNDLE offer. We can simply say that, unless there is an BUNDLE indicator (yes, we may have to define a feature tag, option tag, etc), the WebRTC should not create a BUNDLE offer - it should create a legacy offer, with different ports.

----------

Section 3.1:

Q3: The text says that, if the answerer does not use BUNDLE, the offerer will have to send a second offer. But, you don't mention that this would also add delay to the session establishment, as the answerer can't do anything with the m- lines with unspecified address.

----------

Section 3.1:

Q4: The text says:

"The middle box will not allocate resources for these m lines
 when forwarding the SDP offer, and the SDP answerer will usually
 respond with the unspecified address for these m lines.  Even if the
 SDP answer includes valid connection information for these m lines,
 the middle box will still not allocate separate transport flows for
 them."

As I've said before, you still DO expect the intermediary to take those m- lines into consideration when calculating bandwidth, checking media types, payload type information, crypto information etc etc etc.

----------

Section 3.1:

Q5: The text says:

"If the SDP answerer chooses to reject the first m line(s) in the
 bundle group in the SDP offer (by setting port in the m line to
 zero), it places the intended port, connection, candidate and DTLS
 crypto information for the bundle in the first valid m line of the
 SDP answer and includes the unspecified address for all other m lines
 in the bundle group.  Because of this, it is understood by both
 endpoints that the 5-tuple connection, port and DTLS crypto
 information is to be based on the first valid m line in the SDP offer
 and the first valid m line in the SDP answer."

So, assume that in the offer the first m- line contains a valid address, but in the answer the second m- line contains a valid address (because the answerer rejected the first m- line).

Now, in this case, based on the text in previous section, an intermediary will not reserve resources for any of the m- lines:

- It will not reserve resources based on the first m- line, as it is rejected
- It will not reserve resources based on the second m- line, as the offer contained an unspecified address

Or, do you expect media to be sent in one direction using one m- line, and in another direction using another m- line?

----------

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 26 Feb 2013 20:41:34 +0000

Hi Christer,
Thanks for your comments.  See below.

Richard

> From: Christer Holmberg [mailto:[email-masked]]
> Q1: You say that, if the first line of the offer is rejected, and one
> has to wait for the second offer, it may cause a setup time delay.
> There may be cases where the application doesn't want to session to
> succeed in the first place in that case, so we can have text which
> recommends adding an "essential" (if available) m- line first.
> Typically I guess it would be an audio m- line.

SDP doesn't really have the concept of an "essential" m line, so this recommendation reduces but does not eliminate the possibility that this will happen.

> 
> ----------
> 
> Section 2:
> 
> Q2: You indicate, that if an empty re-INVITE is sent to the WebRTC
> client, it will create a BUNDLE offer. We can simply say that, unless
> there is an BUNDLE indicator (yes, we may have to define a feature tag,
> option tag, etc), the WebRTC should not create a BUNDLE offer - it
> should create a legacy offer, with different ports.

If we added a feature tag for this it would only cover some use cases while others would still not be covered.  A better solution is one that is less likely to cause failure in any use case and more likely to work with at most a second offer/answer.  That is at least my current assessment of the risk.

Just to be clear regarding your terminology, you mean by BUNDLE offer one in which all ports are the same (corresponding to the 2nd and subsequent offers in the latest BUNDLE draft) and a legacy offer is still an SDP offering BUNDLE but with different ports (corresponding to the first offer in your draft)?  Or do you mean a fully legacy offer without BUNDLE?

> 
> ----------
> 
> Section 3.1:
> 
> Q3: The text says that, if the answerer does not use BUNDLE, the
> offerer will have to send a second offer. But, you don't mention that
> this would also add delay to the session establishment, as the answerer
> can't do anything with the m- lines with unspecified address.

You are correct.  I thought this was clear from context but should have mentioned it.  Fortunately with this option a second offer is only needed for the non-bundle (lower priority) case.  Note that as the default in my preferred hybrid proposal (section 3.3) I propose to use the same first offer format as the current first BUNDLE offer to avoid this potential extra offer/answer.

> 
> ----------
> 
> Section 3.1:
> 
> Q4: The text says:
> 
> "The middle box will not allocate resources for these m lines  when
> forwarding the SDP offer, and the SDP answerer will usually  respond
> with the unspecified address for these m lines.  Even if the  SDP
> answer includes valid connection information for these m lines,  the
> middle box will still not allocate separate transport flows for  them."
> 
> As I've said before, you still DO expect the intermediary to take those
> m- lines into consideration when calculating bandwidth, checking media
> types, payload type information, crypto information etc etc etc.

Agreed.  I should have emphasized this point in the draft based on your earlier comment.  My bad.  Since this aspect is inherited from the current BUNDLE draft, along with many other things, I forgot to mention it.

> bundle group in the SDP offer (by setting port in the m line to  zero),
> it places the intended port, connection, candidate and DTLS  crypto
> information for the bundle in the first valid m line of the  SDP answer
> and includes the unspecified address for all other m lines  in the
> bundle group.  Because of this, it is understood by both  endpoints
> that the 5-tuple connection, port and DTLS crypto  information is to be
> based on the first valid m line in the SDP offer  and the first valid m
> line in the SDP answer."
> 
> So, assume that in the offer the first m- line contains a valid
> address, but in the answer the second m- line contains a valid address
> (because the answerer rejected the first m- line).
> 
> Now, in this case, based on the text in previous section, an
> intermediary will not reserve resources for any of the m- lines:
> 
> Or, do you expect media to be sent in one direction using one m- line,
> and in another direction using another m- line?

This (as you pointed out in Q1, rare) case requires a second offer/answer for simple intermediaries that do not understand BUNDLE but are needed, e.g., to open pinholes.  While the idea of using different m line offer/answer pairs in the 2 directions is intriguing, I think this is a non-starter since we will have non-symmetric RTP and it would be difficult to switch back to a single m line representation.

This is not my preferred option for the first offer in a session.  My preferred option is based on section 3.2, where the offer is formatted exactly as in the current BUNDLE draft but the answer differs.  A second offer is still needed if the answerer rejects the first m line in the offer, but this should not usually happen (see Q1).