Subject: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2016 06:04:12 +0000

Hi,

I’ve submitted a new draft: draft-holmberg-avtcore-5761-update-00.

The draft clarifies that the a=rtcp-mux attribute is only allowed in an answer if also present in the associated offer, and that the usage of RTP/RTCP-mux is negotiated for both directions.

The need for this came from 3GPP, where people had different understandings regarding the meaning of the current text.

For the GitHub fans: https://github.com/cdh4u/draft-5761-update (NOTE: Personal repo)

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jun 2016 18:49:01 +0300

Hi Christer,

I reviewed the new text

I have a comment and a nit

Comment:  I am not sure what this sentence means "and the answerer MUST NOT
multiplex RTP and RTCP packets on a single port"

The answerer cannot send multiplex RTP and RTCP packets if the attribute is
not there, it can either send RTCP to RTP port+1 or to the port specified by
the a=rtcp attribute.

Nit: "the rules in Section 4" add of RFC5761

Roni 

 

From: avt [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, June 15, 2016 9:04 AM
To: [email-masked]
Subject: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

Hi,

I've submitted a new draft: draft-holmberg-avtcore-5761-update-00.

The draft clarifies that the a=rtcp-mux attribute is only allowed in an
answer if also present in the associated offer, and that the usage of
RTP/RTCP-mux is negotiated for both directions.

The need for this came from 3GPP, where people had different understandings
regarding the meaning of the current text.

For the GitHub fans: https://github.com/cdh4u/draft-5761-update (NOTE:
Personal repo)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 17:26:51 +0000

Hi,

> Comment:  I am not sure what this sentence means "and the answerer MUST NOT multiplex RTP and > RTCP packets on a single port"
> The answerer cannot send multiplex RTP and RTCP packets if the attribute is not there, it can either
> send RTCP to RTP port+1 or to the port specified by the a=rtcp attribute.

It means that the answerer must not multiple RTP and RTCP packets on a single point. Not sure I understand the issue :)

> Nit: "the rules in Section 4" add of RFC5761

Keep in mind that the text is actually new RFC 5671 text. Do we want the text to refer to its own RFC, or could add "of this specification" instead?

Regards,

Christer

Roni

From: avt [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, June 15, 2016 9:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

Hi,

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Jun 2016 00:22:22 +0300

inline

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2016 8:27 PM
To: Roni Even; [email-masked]
Subject: RE: [AVTCORE] Draft new: draft-holmberg-avtcore-5761-update-00

Hi,

> Comment:  I am not sure what this sentence means "and the answerer MUST
NOT multiplex RTP and > RTCP packets on a single port"

> send RTCP to RTP port+1 or to the port specified by the a=rtcp attribute.

It means that the answerer must not multiple RTP and RTCP packets on a
single point. Not sure I understand the issue :)

[Roni Even]If you mean that  the answerer MUST not send multiplex RTP/RTCP
it is implied by the lack of the attribute and by the definition of where
RTCP should go to, so the sentence is not needed. Do you mean that the
answerer MUST not receive multiplex RTP/RTCP streams?

That is tied to my question about can the answerer use a=RTCP to receive
multiplex RTP and RTCP without explicitly using rtcp-mux attribute?

> Nit: "the rules in Section 4" add of RFC5761

Keep in mind that the text is actually new RFC 5671 text. Do we want the
text to refer to its own RFC, or could add "of this specification" inste

Regards,

Christer

Roni 

 

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jun 2016 18:32:01 -0400

On 6/22/16 5:22 PM, Roni Even wrote:

> */That is tied to my question about can the answerer use a=RTCP to
> receive multiplex RTP and RTCP without explicitly using rtcp-mux
> attribute?/*

I agree that is fuzzy. IMO, attempts to do that ought to be considered 
an error. But I don't know what sort of recovery action should be taken 
for this error.

Note that for an *answerer* to attempt this leads to nonsense. It means 
the offerer will be sending both RTP and RTCP to a single port while the 
answerer (who set this up) must still send them to separate ports. And 
since it wasn't anticipating that these be multiplexed it will 
presumably be buffering as if they are going to separate ports. I would 
think that would make a mess.

It would be less problematic if first signaled by the offerer, because 
then the answerer knows what is going on if it also uses a single for 
both in the answer. But in this case they ought to be explicitly 
signaling that they are multiplexing.

It would be good to revise the definition of a=rtcp to clarify this, so 
somebody not aware of a=rtcp-mux doesn't do this by accident.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jun 2016 09:44:17 +0000

Hi,

>somebody not aware of a=rtcp-mux doesn't do this by accident.

I guess we¹d just need to add an sentence (to section 2.1 of RFC 3605)
saying that one MUST NOT include the RTP port value in the attribute,
right?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jun 2016 10:01:24 -0400

> saying that one MUST NOT include the RTP port value in the attribute,

I *think* that's right, at least in general. I haven't considered 
whether it might make sense in certain contexts in conjunction with 
other options/parameters.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jun 2016 18:57:05 +0000

Hi,

>>> I agree that is fuzzy. IMO, attempts to do that ought to be 
>>> considered an error. But I don't know what sort of recovery action 
>>> should be taken for this error.
>>>
>>> Note that for an *answerer* to attempt this leads to nonsense. It 
>>> means the offerer will be sending both RTP and RTCP to a single port 
>>>> while the answerer (who set this up) must still send them to separate 
>>> ports. And since it wasn't anticipating that these be multiplexed it 
>>> will presumably be buffering as if they are going to separate ports. 
>>> I would think that would make a mess.
>>>
>>> It would be less problematic if first signaled by the offerer, 
>>> because then the answerer knows what is going on if it also uses a 
>>> single for both in the answer. But in this case they ought to be 
>>> explicitly signaling that they are multiplexing.
>>>
>>> It would be good to revise the definition of a=rtcp to clarify this, 
>>> so somebody not aware of a=rtcp-mux doesn't do this by accident.
>>
>>
> I *think* that's right, at least in general. I haven't considered whether it might make sense in certain contexts in conjunction with other options/parameters.

I am not aware of such usage. And, considering the fact that people don't want to define new a=rtcp usages to begin with, I don't think there is a big risk for something to come up.

Regards,

Christer