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

[Christer Holmberg <[e-mail]>]

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