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

["Ejzak, Richard P (Richard)" <[e-mail]>]

Hi Christer,
Thanks for your comments.  See below.

Richard

> From: Christer Holmberg [mailto:[e-mail]]
> 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.

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.

> 
> ----------
> 
> 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?

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).

> 
> ----------
> 
> Regards,
> 
> Christer