Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected

["Stach, Thomas" <[e-mail]>]

Ok understood.
I can imagine the amount of time that you already spent.
I will postpone further editorial comments.

Regards
Thomas

From: Christer Holmberg [mailto:[e-mail]]
Sent: Donnerstag, 9. Oktober 2014 16:02
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Hi,

In previous reviews, I have been asked to add the examples you are referring to.

I have spent very much time on editorial fixes, and re-structures of the whole document, to make it more readable etc. If something is difficult to understand, we should of course fix that, but I'd really like people to also focus on the technical content.

Regards,

Christer



From: Stach, Thomas [mailto:[e-mail]]
Sent: 9. lokakuuta 2014 16:05
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Well,
of course you are right that parts the proposed text is somewhat redundant and I would not insist on having the longer text.
It's just that things that appear obvious to some are not always clear to others.
I would leave the decision up to you.

Independent from that, there are throughout the document quite a few other occurrences of redundant text that could be scrutinized for necessity as well.
E.g. in 8.2
   The generic rules and procedures defined in [RFC3264<https://tools.ietf.org/html/rfc3264>] and [RFC5888<https://tools.ietf.org/html/rfc5888>]
   also apply to the BUNDLE extension.  For example, if an offer is
   rejected by the answerer, the previously negotiated SDP parameters
   and characteristics (including those associated with a BUNDLE group)
   apply.  Hence, if an offerer generates an offer in which the offerer
   wants to create a BUNDLE group, and the answerer rejects the offer,
   the BUNDLE group is not created.
The first sentence is probably ok, but the remainder just repeats 3264/5888.

I could point you to other such examples if you want me to.

Regards
Thomas

From: Christer Holmberg [mailto:[e-mail]]
Sent: Mittwoch, 8. Oktober 2014 21:06
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Hi,

Do we really need text for both sending and receiving?

If we say that an entity sends something towards port X, I think it is obvious that the other endpoint will listen on port X.

Regards,

Christer

From: Stach, Thomas [mailto:[e-mail]]
Sent: 08 October 2014 16:21
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

inline

From: Christer Holmberg [mailto:[e-mail]]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Hi Thomas,

I suggest something like this:

In section 10.3.2.3:

OLD TEXT:

"If the answerer rejects usage of RTP/RTCP multiplexing within the
                BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'
                attribute to any bundled "m=" line in the answer."

NEW TEXT:

"If the answerer rejects usage of RTP/RTCP multiplexing within the
                BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'
                attribute to any bundled "m=" line in the answer. The answerer will,
                based on the port number of the selected offerer BUNDLE address,
                use the next higher (odd) destination port number [RFC3550] for
sending RTCP packets associated with a bundled "m=" line towards
the offerer,"
[TS] I'd like to add something for receiving RCTP. With a slight re-wording the new text would be
If the answerer rejects usage of RTP/RTCP multiplexing within the
BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'
attribute to any bundled "m=" line in the answer.
 Based on the port number of the selected offerer BUNDLE address,
 the answerer will send RTCP packets associated with any bundled "m=" line
 to the next higher (odd) destination port [RFC3550].
 Based on the port number of the selected answerer BUNDLE address,
 the answerer will receive RTCP packets associated with any bundled "m=" line
 at the next higher (odd) destination port [RFC3550].
This means that the associated RTCP streams for bundled "m=" lines
 are bundled at the next higher (odd) destination port


In section 10.3.2.4:

OLD TEXT:

                "If the answerer does not accept the usage of RTP/RTCP multiplexing
                [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP
                and RTCP."

NEW TEXT:

                "If the answerer does not accept the usage of RTP/RTCP multiplexing
                [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP
                and RTCP. The answerer will, based on the port number of the answerer
BUNDLE address, use the next higher (odd) destination port number [RFC3550]
for sending RTCP packets associated with a bundled "m=" line towards the
answerer."

[TS] Similar here
If the answerer does not accept the usage of RTP/RTCP multiplexing
[Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP
and RTCP.
Based on the port number of the selected offerer BUNDLE address,
 the offerer will receive RTCP packets associated with any bundled "m=" line
 at the next higher (odd) destination port [RFC3550].
 Based on the port number of the selected answerer BUNDLE address,
 the offerer will send RTCP packets associated with any bundled "m=" line
 to the next higher (odd) destination port [RFC3550].


Regards,

Christer




From: Stach, Thomas [mailto:[e-mail]]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected


Christer,

From: Christer Holmberg [mailto:[e-mail]]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Hi Thomas,

>BUNDLE can be used separate from RFC5761 RTCP-Multiplexing.
>I can't find text in bundle-11 where the answerer would send its RTCP packets if it accepted BUNDLE, but rejected RTCP-muxing.
>I see two options:
>1. The answerer sends all RTCP packets to the shared RTP-port+1 of the negotiated shared address.
>2. The answerer sends the RTCP packets to separate ports based on the unique addresses in the m-lines of the offer?

Alternative 1) is correct. I guess we could add some text to clarify that.
[TS] Yes, please. The current text is not sufficiently clear.

>The offerer on the other hand will only receive a shared address. I assume it then has to send all its RTCP packets
>to the shared RTP-port+1 of the answerer.

Yes.

>Is my understanding correct or am I completely off-track?

Assuming my understanding is correct, your understanding is correct :)

>Supposed I'm correct, then independent from the response, I'm asking if there really is a use case for that.
>In case 1, one would have to demux the RTP streams and RTCP streams from two separate ports instead of a single port. How much implementation effort >is saved in that case?

I am not sure what you mean. Are you asking how much implementation effort is saved if you don't have to de-mux RTP and RTCP?
[TS] Yes.  I was questioning myself what benefit there is in not mandating RTCP-mux.
In the meantime I looked up again the discussion on "Q14" that led to having rtcp-mux optional. I agree with the outcome.
Thanks!

>In case 2 the RTCP handling at offerer and answerer is completely different. In addition, you still need "a lot" of RTCP ports and take advantage of only half >of the BUNDLE benefits.

Correct. But, case 2 is not applicable (unless the endpoints choose not to use BUNDLE to begin with, that is...).

Regards,

Christer