Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Dec 2015 20:52:49 +0000

Hi,

I've submitted a new version (-01) of draft-holmberg-mmusic-mux-exclusive.

It now also includes the ICE considerations when indicating support of exclusive RTP/RTCP multiplexing.

NOTE: I have some issues with git, so the new version can NOT yet be found on github.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Dec 2015 15:25:33 +0000

Hi,

Version -01 can now also be found on github.

https://github.com/cdh4u/draft-mux-exclusive

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 08 December 2015 22:53
To: [email-masked]
Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Dec 2015 16:19:34 -0500

Hi Christer,

Couple of questions about the new draft:

1. Are you stating the rtcp attribute for mux-exclusive MUST not contain
the optional [nettype space addrtype space connection-address] or that it
may contain this address and it should be set to the value from the c= line?

2. In cases when trickle ICE is used, should rtcp SDP attribute contain "9
IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your
draft? Does this mean that JSEP complaint offer is always rtcp-mux
exclusive?

Regards,
_____________
Roman Shpount

On Tue, Dec 8, 2015 at 3:52 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I’ve submitted a new version (-01) of draft-holmberg-mmusic-mux-exclusive.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Dec 2015 07:23:05 +0000

Hi Roman,

Thanks for your (as always) excellent comments.

> 1. Are you stating the rtcp attribute for mux-exclusive MUST not contain the optional [nettype space addrtype space connection-address] or that it may contain this address and it should be set to the value from the c= line?

Good question.

My idea was that the attribute only contains the port, but I do agree that we should say something about the optional parts. Either we:

1)	 say MUST NOT use it; or 
2)	we say MUST use the value from the c= line; or 
3	we allow both 1) and 2). 

Any preference?

>2. In cases when trickle ICE is used, should rtcp SDP attribute contain "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your draft? Does this mean that JSEP complaint offer is always rtcp-mux exclusive?

Good question.

In that case, if you are yet not providing any candidates to begin with, I assume you don't know.

Of course, if we want to distinguish the cases, one option would be to e.g. use a port value of zero for mux-exclusive?

Perhaps the b=RR/RS bandwidth indicators could also be used somehow, but I hope we can avoid that.

Regards,

Christer

On Tue, Dec 8, 2015 at 3:52 PM, Christer Holmberg <[email-masked]> wrote:
Hi,

 
 
Regards,
 
Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Dec 2015 15:35:18 -0500

On Fri, Dec 11, 2015 at 2:23 AM, Christer Holmberg <
[email-masked]> wrote:

> My idea was that the attribute only contains the port, but I do agree that
> we should say something about the optional parts. Either we:
>

Unless there is a reason, we should go with 3. Any endpoint that supports
this draft should fully support SDP rtcp attribute and must be able to
parse rtcp attribute with and without the optional address. After the
attribute is parsed there is no additional burden to determine that rtcp
attribute points to the same address/port as c= and m= lines.

We can also specify that 1 SHOULD be preferred, simply to send less
redundant data in SDP.

> >2. In cases when trickle ICE is used, should rtcp SDP attribute contain
> "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your
> Of course, if we want to distinguish the cases, one option would be to
> e.g. use a port value of zero for mux-exclusive?
>

This is a tricky situation. When no initial candidates are collected, rtcp
attribute set to port 9 can either mean that no rtcp candidates are yet
available or that mux exclusive is used. I do not know what is the solution
here. We definitely do not want to change mux only to require rtcp
attribute with port 0, since this will break legacy interop with end points
that support rtcp attribute but do not rtcp-mux. We might need an
additional SDP attribute to indicate that rtcp mux exclusive is required.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Dec 2015 14:33:19 +0000

Hi,

>>> 1. Are you stating the rtcp attribute for mux-exclusive MUST not contain the optional [nettype space addrtype space connection-address] 
>>> or that it may contain this address and it should be set to the value from the c= line?
>>
>> Good question.
>>
> Unless there is a reason, we should go with 3. Any endpoint that supports this draft should fully support SDP rtcp attribute 
> and must be able to parse rtcp attribute with and without the optional address.
> After the attribute is parsed there is no additional burden to determine that rtcp attribute points to the same address/port as c= and m= lines.

Correct.

Then text is needed, saying that the address information must also be the same as for the associated c- line address.

> We can also specify that 1 SHOULD be preferred, simply to send less redundant data in SDP.

Sounds ok.

--------- 

>>> 2. In cases when trickle ICE is used, should rtcp SDP attribute contain "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep 
>>> section 5.2.1 or "9" per your draft? Does this mean that JSEP complaint offer is always rtcp-mux exclusive?
>>
>> Good question.
>>
> This is a tricky situation. When no initial candidates are collected, rtcp attribute set to port 9 can either mean that no 
> rtcp candidates are yet available or that mux exclusive is used. I do not know what is the solution here. We definitely do 
> not want to change mux only to require rtcp attribute with port 0, since this will break legacy interop with end points 
> that support rtcp attribute but do not rtcp-mux. We might need an additional SDP attribute to indicate that rtcp mux exclusive is required. 

Would we then need to require trickle UAs to understand such attributes?

(Of course, if the trickle agent is an WebRTC entity, it will support the attribute)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Dec 2015 17:21:23 +0000

One question related to this: is there are reason we need to use the SDP 'rtcp' attribute for trickle to begin with? What purpose does it serve? 

If someone sends "9 IN IP4 0.0.0.0" I think it is pretty clear it also applies to RTCP...

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 12 December 2015 16:33
To: Roman Shpount <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Hi,

>>> 1. Are you stating the rtcp attribute for mux-exclusive MUST not 
>>> contain the optional [nettype space addrtype space connection-address] or that it may contain this address and it should be set to the value from the c= line?
>>
>> Good question.
>>
> Unless there is a reason, we should go with 3. Any endpoint that 
> supports this draft should fully support SDP rtcp attribute and must be able to parse rtcp attribute with and without the optional address.

Correct.

Sounds ok.

--------- 

>>> 2. In cases when trickle ICE is used, should rtcp SDP attribute 
>>> contain "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your draft? Does this mean that JSEP complaint offer is always rtcp-mux exclusive?
>>
>> Good question.
>>
> This is a tricky situation. When no initial candidates are collected, 
> rtcp attribute set to port 9 can either mean that no rtcp candidates 
> are yet available or that mux exclusive is used. I do not know what is 
> the solution here. We definitely do not want to change mux only to require rtcp attribute with port 0, since this will break legacy interop with end points that support rtcp attribute but do not rtcp-mux. We might need an additional SDP attribute to indicate that rtcp mux exclusive is required.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Dec 2015 13:31:43 -0500

> If someone sends "9 IN IP4 0.0.0.0" I think it is pretty clear it also applies to RTCP...

Interestingly, the meaning of this is a bit subtle. Port 9 was chosen 
because it is the discard port. But technically, if there is no separate 
designation of the RTCP port, then (according to rfc3550) we need an 
even/odd pair, and so 9 is reduced to 8 for rtp, and 9 is used for the 
rtcp. That means that rtp is not being targeted to the discard port, but 
rather to an unassigned port. But of course this is moot since you can't 
send traffic to 0.0.0.0. So the effect is still as intended - the 
rtp/rtcp doesn't go anywhere.

But it doesn't mean "don't send rtcp", nor does it mean "multiplex rtp 
and rtcp".

So then you still need to specify rtcp-mux so that ICE doesn't gather 
separate rtcp candidates. But I don't think you need to specify a=rtcp.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sun, 13 Dec 2015 19:46:55 -0500

On Sat, Dec 12, 2015 at 12:21 PM, Christer Holmberg <
[email-masked]> wrote:

> One question related to this: is there are reason we need to use the SDP
> 'rtcp' attribute for trickle to begin with? What purpose does it serve?
>
I would think this attribute is completely redundant in such offer. I think
it was included there for logical continuity since rtcp attribute is
required for all ICE SDP even in cases when rtcp is sent to the c= address
m= line port+1, which are actually majority of session descriptions when
rtcp-mux only is not used. I think the question we need to ask is why rtcp
attribute is required for all ICE offers even when it is completely
redundant.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2015 05:23:53 +0000

Hi Roman,

Where is it stated that a=rtcp is required for all ICE offers? I could not find such statement in draft-5245bis.

Or, did you mean that draft-JSEP requires it?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎14/‎12/‎2015 02:47
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

On Sat, Dec 12, 2015 at 12:21 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
One question related to this: is there are reason we need to use the SDP 'rtcp' attribute for trickle to begin with? What purpose does it serve?

I would think this attribute is completely redundant in such offer. I think it was included there for logical continuity since rtcp attribute is required for all ICE SDP even in cases when rtcp is sent to the c= address m= line port+1, which are actually majority of session descriptions when rtcp-mux only is not used. I think the question we need to ask is why rtcp attribute is required for all ICE offers even when it is completely redundant.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Dec 2015 00:31:39 -0500

> find such statement in draft-5245bis.

I am not sure about the 5245bis, but in RFC 5245 section 4.3 (
https://tools.ietf.org/html/rfc5245#section-4.3):

If the agent is utilizing RTCP, it MUST encode the RTCP candidate
using the a=rtcp attribute as defined in RFC 3605
<https://tools.ietf.org/html/rfc3605>[RFC3605
<https://tools.ietf.org/html/rfc3605>].  If RTCP is not in use, the
agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556
<https://tools.ietf.org/html/rfc3556> [RFC3556
<https://tools.ietf.org/html/rfc3556>].

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2015 05:43:08 +0000

Hi,

That has changed in draft-5245bis, I believe.

Also, RFC 3605 is only an informative reference in draft-5245bis.

Regards,

Christer

Sent: ‎14/‎12/‎2015 07:31

On Mon, Dec 14, 2015 at 12:23 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Where is it stated that a=rtcp is required for all ICE offers? I could not find such statement in draft-5245bis.

I am not sure about the 5245bis, but in RFC 5245 section 4.3 (https://tools.ietf.org/html/rfc5245#section-4.3):

If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605<https://tools.ietf.org/html/rfc3605>[RFC3605<https://tools.ietf.org/html/rfc3605>].  If RTCP is not in use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556<https://tools.ietf.org/html/rfc3556> [RFC3556<https://tools.ietf.org/html/rfc3556>].

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Dec 2015 00:49:24 -0500

> Also, RFC 3605 is only an informative reference in draft-5245bis.

The same text is now in section 4.2 of draft-ietf-mmusic-ice-sip-sdp (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-07#section-4.2).
All SDP specific text got moved from draft-5245bis into a separate document.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2015 06:10:48 +0000

Hi,

You are right. So, that would have to be changed (unless there is a reason to always mandate the attribute when RTCP is used).

Also, the text says "MUST encode the RTCP candidate using the a=rtcp attribute", which sounds little confusing.

Regards,

Christer

Sent: ‎14/‎12/‎2015 07:49

On Mon, Dec 14, 2015 at 12:43 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
That has changed in draft-5245bis, I believe.

The same text is now in section 4.2 of draft-ietf-mmusic-ice-sip-sdp (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-07#section-4.2). All SDP specific text got moved from draft-5245bis into a separate document.

Regards,
_____________
Roman Shpount