Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt - change to draft-ice-sip-sdp

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Mar 2016 16:31:51 +0000

Hi Suhas,

...

>>> Note that again, this is a box of our own design, we can decide to update those documents here.  "The a=rtcp attribute MUST NOT be included
>>>unless other documents (other than RFC 5761) mandate its inclusion.  If present, a=rtcp MUST include a port number of 9."  Or something along those lines.
>>
>> Sure, I can add text like that to the draft, and we can update ice-sip-sdp.
>
> [Suhas] .. What are the specific updates for ice-sip-sdp. Sorry if i have missed the context. I am happy to consider the inputs for these updates if I get to know the concrete updates. 

ice-sip-sdp requires usage of a=rtcp if RTCP is used. My suggestion is to remove that requirement if mux-exclusive is used.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 13:37:21 -0500

Hi Suhas,

I have previously proposed the following, which will remove rtcp attribute
if RTCP is not used. This will also cover mux exclusive case, since RTCP
candidates will not be present in such case:

On Tue, Jan 12, 2016 at 3:48 PM, Roman Shpount <[email-masked]> wrote:

> Cross-posting to MMUSIC, since this affects both RFC 5245bis and
> draft-ietf-mmusic-ice-sip-sdp
>
> RFC 5245 and draft-ietf-mmusic-ice-sip-sdp currently say the following:
>
>    The default candidates are added to the SDP as the default
>    destination for media.  For streams based on RTP, this is done by
>    placing the IP address and port of the RTP candidate into the c and m
>    lines, respectively.  *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>].
>
>
> There is an ongoing discussion whether the rtcp attribute is required in case of trickle ICE, when an offer is sent without candidate information, the RTP port set to 9, and the RTP IP address set to 0.0.0.0.
>
>
>
> Example:
>
>                               a=rtcp: 9 IN IP4 0.0.0.0
>
>
>
> According to Christer this is not needed, as there is no candidate to “encode”, and it also conflicts with the suggested mechanism for indicating exclusive support of RTP/RTCP multiplexing (draft-holmberg-mmusic-mux-exclusive).
>
>
> Furthermore, according to section 2.1 of RFC 3605:
>
>
>    The RTCP attribute is used to document the RTCP port used for media
>    stream, when that port is not the next higher (odd) port number
>    following the RTP port described in the media line.
>
>
> RFC 5245 overwrites the guideline from RFC 3605 and states that SDP rtcp
> attribute MUST be present even when RTCP default candidate is not present
> or when RTCP candidate is using port rtp+1, which is currently the the most
> common scenario since sequential port is typically allocated for RTCP by
> TURN.
>
> I suggest changing the language in section 4.2
> of draft-ietf-mmusic-ice-sip-sdp to:
>
>    The default candidates are added to the SDP as the default
>    destination for media.  For streams based on RTP, this is done by
>    placing the IP address and port of the RTP candidate into the c and m
>    lines, respectively.  *If the agent is utilizing RTCP and if RTCP *
>
> *   candidate is present and not equal to the same address and *
>
> *   the next higher port number of the RTP candidate, the agent 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>].
>
>
>
_____________
Roman Shpount

On Tue, Mar 1, 2016 at 11:31 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Suhas,
>
> ...
>
> >>> Note that again, this is a box of our own design, we can decide to
> update those documents here.  "The a=rtcp attribute MUST NOT be included
> >>>unless other documents (other than RFC 5761) mandate its inclusion.  If
> present, a=rtcp MUST include a port number of 9."  Or something along those
> lines.
> >>
> > [Suhas] .. What are the specific updates for ice-sip-sdp. Sorry if i
> have missed the context. I am happy to consider the inputs for these
> updates if I get to know the concrete updates.
>
> ice-sip-sdp requires usage of a=rtcp if RTCP is used. My suggestion is to
> remove that requirement if mux-exclusive is used.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Mar 2016 19:55:55 +0000

Hi Roman,

a=rtcp: 9 IN IP4 0.0.0.0 no longer conflicts with mux-exclusive, because we define a new attribute to indicate it.

Having said that, I still don’t think a=rtcp: 9 IN IP4 0.0.0.0 in case of trickle ICE :)

…and, I agree with your suggested text change.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 01 March 2016 20:37
To: Christer Holmberg <[email-masked]>
Cc: Suhas Nandakumar <[email-masked]>; Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt - change to draft-ice-sip-sdp

Hi Suhas,

I have previously proposed the following, which will remove rtcp attribute if RTCP is not used. This will also cover mux exclusive case, since RTCP candidates will not be present in such case:

On Tue, Jan 12, 2016 at 3:48 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Cross-posting to MMUSIC, since this affects both RFC 5245bis and draft-ietf-mmusic-ice-sip-sdp

   lines, respectively.  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>].

Example:
                              a=rtcp: 9 IN IP4 0.0.0.0

RFC 5245 overwrites the guideline from RFC 3605 and states that SDP rtcp attribute MUST be present even when RTCP default candidate is not present or when RTCP candidate is using port rtp+1, which is currently the the most common scenario since sequential port is typically allocated for RTCP by TURN.

I suggest changing the language in section 4.2 of draft-ietf-mmusic-ice-sip-sdp to:

   lines, respectively.  If the agent is utilizing RTCP and if RTCP

   candidate is present and not equal to the same address and

   the next higher port number of the RTP candidate, the agent 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>].

_____________
Roman Shpount

On Tue, Mar 1, 2016 at 11:31 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Suhas,

...

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 13:03:44 +1100

> …and, I agree with your suggested text change.

The problem here is that the proposed text says (paraphrased) "if you
are using RTCP", which is technically still true even if you are
multiplexing.

How about:

   The default candidates are added to the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is uses RTCP and an RTCP
   candidate is present, the agent MUST encode
   the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
   [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 [RFC3556].

I don't like the exclusion for port+1, so I removed it.  New
implementations should never rely on that property.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 22:46:03 -0500

> are using RTCP", which is technically still true even if you are

Yes, this is true that RTCP is used when it is multiplexed, but not RTCP
candidate will be present in this case, thus no a=rtcp attribute will be
added.

> implementations should never rely on that property.

I put the port+1 exclusion to stop the practice of putting completely
redundant a=rtcp candidate for port+1 which all current implementation do
for some reason. I want to stop this practice.

Overall, I would prefer to have an option for "ICE only" connection which
will have IN IP4 0.0.0.0 address in the c= line, port 9 in m= line and no
a=rtcp attribute. I would also like this option to be recommended for all
new implementations. I would also strongly advise that address and port in
c= and m= lines as well as a=rtcp attribute should only be used if and only
if legacy interop is required. There is no excuse for new deployments
without ICE and consent.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 16:21:18 +1100

> for some reason. I want to stop this practice.

I agree, I also want to stop the port+1 practice.  But I think that
you wanted something smaller, like better SDP discipline, which I
disagree with.  Implicit rules suck.

I also think that ICE-only would be a nice looking future state.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 08:55:27 +0000

Hi,

ICE-only sounds interesting, but I think that is outside the scope of mux-exclusive. Please write a draft :)

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 02 March 2016 07:21
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt - change to draft-ice-sip-sdp

On 2 March 2016 at 14:46, Roman Shpount <[email-masked]> wrote:
> redundant a=rtcp candidate for port+1 which all current implementation 
> do for some reason. I want to stop this practice.

I agree, I also want to stop the port+1 practice.  But I think that you wanted something smaller, like better SDP discipline, which I disagree with.  Implicit rules suck.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 10:51:14 -0500

> disagree with.  Implicit rules suck.

Current specification (RFC 5245bis and draft-ietf-mmusic-ice-sip-sdp) both
specify that a=rtcp attribute MUST be present if RTCP is used. Event if
RTCP is multiplexed, no RTP or RTCP candidates are allocated yet due to
trickling, or if RTCP is on the RTP+1 port, a=rtcp MUST be present
according to the current language. With my proposed language, a=rtcp only
MUST be present if there is an RTCP candidate and it is not equal to RTP+1.
Implementations are still free to insert a=rtcp when RTCP is sent to RTP+1,
they are just not required to do so. This actually puts ICE implementation
inline with RFC 3556, which never intended a=rtcp to be inserted all the
time. What exactly do you disagree with here?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 Mar 2016 10:54:16 -0500

> mux-exclusive. Please write a draft :)

I think this can be handled by minor edits in draft-ietf-mmusic-ice-sip-sdp

All we need is to allow not to include RTP candidate in c= and m= line, and
RTCP candidate in a=rtcp, if this offer is not intended to work with
non-ICE end points. We should also remove a re-invite when ICE candidate is
selected. I think this will align draft-ietf-mmusic-ice-sip-sdp with the
current usage in webrtc.

Regards,
_____________
Roman Shpount