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

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Feb 2013 07:10:03 +0000

Hi Charles,

Thanks for your comments! Reply inline.

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

The text talks about the Offer where different port numbers are used, ie when it is still not known whether the Answerer supports bundle. But, maybe that needs to be more clear.

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

> 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' :)

Correct. I got the same comment off-line from Harald, but forgot to fix it.

Do people have any preference? Shall du usage of rtcp-mux be a SHOULD, a MUST, or a RECOMMEND? :)

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

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

I'm still thinking about it, but at least at this point I would agree with you :)

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

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

Keep in mind that, in this case, only the port of the first "m=" line represents the bundle port (as different port values are given for the other m= lines).

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

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

Sure, that rule would still apply.

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

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

I was more thinking of the case where endpoints already have successfully negotiated the usage of bundle, and then at some point during the session chose (for whatever reason) to disable the multiplexing.

Basically it would mean sending a new offer, without BUNDLE, and with different port number values - ie a "legacy"  offer :)

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

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

Is there a specific reason why you think that we can't mandate the Offerer to insert the bundle port in the first "m=" line?

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

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

My personal opinion is that the answerer already knows that the offerer wants to use bundle, and is expected to send a new offer. Also, by using the same ports already in the first answer, we would prevent a case where the answerer does NOT support bundle, but blindly copies the grouping attributes from the offer to the answer.

But, opinions are welcome :)

Regards,

Christer

---

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

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2013 11:10 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-
> negotiation-03 - Charles' comments
> 
> Hi Charles,
> 
> >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.
> >
> The text talks about the Offer where different port numbers are used, ie
> when it is still not known whether the Answerer supports bundle. But,
> maybe that needs to be more clear.

I understand that. However, in that case, it seems to me that the port number of the first "m=" line no longer has any special significance because each "m=" line has its own port number, and if another offer is sent to make all the ports the same, that port number may be different than any of the port numbers in the initial offer.

According to draft-ietf-rtcweb-rtp-usage, it is mandatory to support both muxed and non-muxed, so SHOULD seems most appropriate to me. What is important is that rtcp-mux is used or not use consistently across all BUNDLED "m=" lines.

> > 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
> > 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).
> 
> Keep in mind that, in this case, only the port of the first "m=" line
> represents the bundle port (as different port values are given for the other
> m= lines).

If the "m=" lines have different ports, my thinking is that no special meaning is tied to any of them. In a subsequent offer/answer exchange where the ports of all the bundled "m=" lines are set to the same value, that value need not be the same as what was in the previous offer that used separate ports for each "m=" line.

For example, if the initial offer is:

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10002 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000

The subsequent offer may be:

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 20000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
 
> I was more thinking of the case where endpoints already have successfully
> negotiated the usage of bundle, and then at some point during the session
> chose (for whatever reason) to disable the multiplexing.
> 
> Basically it would mean sending a new offer, without BUNDLE, and with
> different port number values - ie a "legacy"  offer :)

Yes.
 
> > 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.
> 
> Is there a specific reason why you think that we can't mandate the Offerer
> to insert the bundle port in the first "m=" line?

Because it gets confusing if the first bundled "m=" line in the SDP offer is rejected in the first SDP answer. I just think it is cleaner to wait for the next offer. I suppose it is less efficient, so I agree there are tradeoffs.
 
> >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
> My personal opinion is that the answerer already knows that the offerer
> wants to use bundle, and is expected to send a new offer. Also, by using the
> same ports already in the first answer, we would prevent a case where the
> answerer does NOT support bundle, but blindly copies the grouping
> attributes from the offer to the answer.

If you wait until the second offer/answer exchange to set the ports to be the same, you still get this property. Also by waiting until the second offer/answer exchange to make the ports the same you increase the odds of the initial offer/answer completing correctly end to end.
 
> But, opinions are welcome :)

Yes, as I am not all the convinced as to which way is better yet either.

Cheers,
Charles