Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

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

Hi Roman,

A question on your suggestion to use ICE candidates in order to indicate mux-exclusive by only providing RTP candidates: how do you separate the RTP/RTCP-mux cases from cases where RTCP is not used to begin with? In both cases you would only include RTP candidiates.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Dec 2015 14:03:19 -0500

Christer,

The rtcp-mux attribute will still be provided in cases when RTP/RTCP is
muxed. It will not be present in cases when RTCP is not used to begin with.

Essentially what I want to see are two options:

1. If, in the offer SDP, there is a valid IP in SDP c=line, then rtcp-mux
only is signaled by presence of rtcp-mux attribute and rtcp attribute set
to port from the m= line and optionally address from c=line. If ICE
candidates are present, they only present for RTP component.

2. If there is an IP4 0.0.0.0 address in the c=line (ICE only use case),
then rtcp-mux only is signaled by presence of rtcp-mux attribute and ICE
candidates for RTP component only.

Option 1 is for legacy interop. Option 2 is for new ICE only end points. I
do not want rtcp attribute to contain something artificial for the use case
where it is not needed to begin with.

Regards,

_____________
Roman Shpount

On Mon, Dec 7, 2015 at 9:38 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Roman,
>
>
>
> A question on your suggestion to use ICE candidates in order to indicate
> mux-exclusive by only providing RTP candidates: how do you separate the
> RTP/RTCP-mux cases from cases where RTCP is not used to begin with? In both
> cases you would only include RTP candidiates.
>
>
>
> Regards,
>
>
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Dec 2015 19:31:44 +0000

Hi,

>The rtcp-mux attribute will still be provided in cases when RTP/RTCP is muxed. It will not be present in cases when RTCP is not used to begin with.

Keep in mind that ICEbis does not talk about SDP, or any other signalling, only candidates. So, from a pure ICE candidate perspective, one will not see the difference between RTP/RTCP-mux and RTP-only: it needs to be indicated in signalling.

>1. If, in the offer SDP, there is a valid IP in SDP c=line, then rtcp-mux only is signaled by presence of rtcp-mux attribute and rtcp attribute set to port from the m= line and optionally >address from c=line. If ICE candidates are present, they only present for RTP component.

Correct. This is what I intend to write in the next version of draft-exclusive-mux.

>2. If there is an IP4 0.0.0.0 address in the c=line (ICE only use case), then rtcp-mux only is signaled by presence of rtcp-mux attribute and ICE candidates for RTP component only.

I see no reason to always keep the rtcp attribute. But, that is a separate discussion. This e-mail is about ICE candidates only.

>Option 1 is for legacy interop. Option 2 is for new ICE only end points. I do not want rtcp attribute to contain something artificial for the use case where it is not needed to begin with.

That is all fine for SDP. But, again, ICEbis only talks about ICE candidiates. So, I have suggested text to ICEbis, saying that the presence of RTP candidates (component ID 1) can mean two things: RTP/RTCP-mux or RTP-only. Which is used needs to be clarified in signalling (SDP, or whatever other signalling mechanism).

Regards,

Christer

_____________
Roman Shpount

On Mon, Dec 7, 2015 at 9:38 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Dec 2015 14:42:01 -0500

On Mon, Dec 7, 2015 at 2:31 PM, Christer Holmberg <
[email-masked]> wrote:

>
>
> That is all fine for SDP. But, again, ICEbis only talks about ICE
> candidiates. So, I have suggested text to ICEbis, saying that the presence
> of RTP candidates (component ID 1) can mean two things: RTP/RTCP-mux or
> RTP-only. Which is used needs to be clarified in signalling (SDP, or
> whatever other signalling mechanism).
>

I would clarify this that presence of RTP candidates (component ID 1) can
mean two things: RTP/RTCP-mux or a *non-RTP **transport that is not using
RTCP and can be transmitted over a single connection, such as SCTP or UDPTL*
.

There should never be a legitimate case why RTP would be used without RTCP.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Dec 2015 19:46:24 +0000

Hi,

>> That is all fine for SDP. But, again, ICEbis only talks about ICE candidiates. So, I have suggested text to ICEbis, saying that the presence of 
>> RTP candidates (component ID 1) can mean two things: RTP/RTCP-mux or RTP-only. Which is used needs to be clarified in signalling (SDP, or whatever other signalling mechanism).
>
> I would clarify this that presence of RTP candidates (component ID 1) can mean two things: RTP/RTCP-mux or a non-RTP transport that 
> is not using RTCP and can be transmitted over a single connection, such as SCTP or UDPTL. 
>

Is that really true?

If so, then I think some existing RTP-text in ICEbis needs to be fixed, because the text says "If RTCP is also supported". To me that sounds like RTCP is optional with RTP.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Dec 2015 15:00:04 -0500

On Mon, Dec 7, 2015 at 2:46 PM, Christer Holmberg <
[email-masked]> wrote:

> If so, then I think some existing RTP-text in ICEbis needs to be fixed,
> because the text says "If RTCP is also supported". To me that sounds like
> RTCP is optional with RTP.
>

It is common for legacy PSTN gateways or SBC not to generate RTCP to
decrease network load or number of generated packets. This being said, I am
not aware of any specification that says that RTCP is optional with RTP. I
can, of cause, be missing something.
_____________
Roman Shpount

---

From: Bo Burman <[email-masked]>
Date: Tue, 8 Dec 2015 20:33:55 +0000

Well, the Global Text Telephony feature of Voice-over-LTE in GSMA (PRD IR.92) mandates to not use RTCP (by requiring to set RS and RR bandwidths to 0). TTY type services are required in some markets. That is a very low-bitrate service where it makes sense to not use RTCP. So, at least one such spec does exist.

/Bo (as individual)

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: den 7 december 2015 21:00
To: Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Is that really true?

It is common for legacy PSTN gateways or SBC not to generate RTCP to decrease network load or number of generated packets. This being said, I am not aware of any specification that says that RTCP is optional with RTP. I can, of cause, be missing something.
_____________
Roman Shpount