Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-18.txt

From: Roman Shpount <[email-masked]>
Date: Sun, 1 Apr 2018 21:05:27 -0400

Hi Flemming,

I think the draft should have used SHOULD instead of MUST there, as in:

If an agent uses separate ports for RTP and RTCP, the agent MUST include an
SDP rtcp attribute in the "m=" section, as described in [RFC3605].  In the
cases where the port number for the RTCP is one higher than the RTP port
and RTCP component address is same as the address of the RTP component, the
SDP rtcp attribute *SHOULD NOT* be included.

Regards,
_____________
Roman Shpount

On Sat, Mar 31, 2018 at 6:12 PM, Suhas Nandakumar <[email-masked]>
wrote:

> Hi Flemming
>
> Earlier version of the draft didn’t had that restriction. It was added at
> later point due to wg discussion almost 2 years back. Roman and Thomas
> Stach would know more details on the exact reasons
>
> I am mobile right now and can try finding from archives for the reasoning
>
> Thanks
> Suhas
>
> On Sat, Mar 31, 2018 at 12:38 PM Flemming Andreasen <[email-masked]>
> wrote:
>
>> Understood, however is there a need to actively forbid its use in that
>> case ?
>>
>> Thanks
>>
>> -- Flemming
>>
>> On 3/31/18 2:43 PM, Roman Shpount wrote:
>>
>> On Sat, Mar 31, 2018 at 2:27 PM, Flemming Andreasen <[email-masked]>
>> wrote:
>>
>>> - Section 3.2.2: Why is it forbidden to include the "rtcp" attribute
>>> when the RTCP port number is one higher than the RTP port number ?
>>>
>>
>> The rtcp attribute in this case is redundant since if rtcp attribute is
>> absent, RTCP will be sent to same IP as RTP and port number one higher then
>> the RTP.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>>
>>
>>
>>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 02 Apr 2018 01:42:02 +0000

On Sun, Apr 1, 2018 at 6:05 PM Roman Shpount <[email-masked]> wrote:

> If an agent uses separate ports for RTP and RTCP, the agent MUST include
> an SDP rtcp attribute in the "m=" section, as described in [RFC3605].  In
> the cases where the port number for the RTCP is one higher than the RTP
> port and RTCP component address is same as the address of the RTP
> component, the SDP rtcp attribute *SHOULD NOT* be included.
>
>
Happy to make that change. Flemming, what do you think ?

Cheers
Suhas

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 1 Apr 2018 23:03:57 -0700

Hello Flemming

 Thanks for the review. Answered inline. Please let me know your thoughts.

cheers
Suhas

On Sat, Mar 31, 2018 at 11:27 AM, Flemming Andreasen <[email-masked]>
wrote:

> Hi Suhas
>
> Thanks for quickly updating and submitting the document, which I have
> reviewed. A couple of questions:
>
> - Section 3.2.2: Why is it forbidden to include the "rtcp" attribute when
> the RTCP port number is one higher than the RTP port number ?
>
>
[Suhas]  Since this topic is being discussed at present, i will wait on it
for the decision

- Section 3.2.5, list item 3 says:
> <quote>
>
>    3.  If the default candidates were relayed candidates learned through
>        a TURN server, the agent MUST create permissions in the TURN
>        server for the IP addresses learned from its peer in the SDP it
>        just received.  If this is not done, initial packets in the data
>        stream from the peer may be lost.
>
> </quote>
> The text in and by itself seems reasonable, however I am not following how
> this relates to ICE mismatch and hence why it is part of this list (which
> in turn makes it difficult to understand). Let's say it's an offer SDP:
> The default candidates are relayed through a TURN server that the offerer
> uses, however you are now saying the answerer (agent) needs to create a
> permission in the TURN server?
>

[Suhas]  This section was originally under title "Verifying ICE support"
and was Answerer specific procedures. We renamed to "ICE-Mismatch" to align
with ICE-Bis. Would the following clarification be more suitable
<quote>

3.  If the default candidates were relayed candidates learned through
       a TURN server, the responder agent MUST create permissions in the TURN
       server for the IP addresses learned from its peer in the Offer SDP it
       just received.  If this is not done, initial packets in the data
       stream from the peer may be lost.

</quote>

> - Section 3.3.4: What is considered the "lifetime of the ICE session" ?
> Does it end when we do an ICE restart ? Some clarification would be
> helpful.
>

[Suhas]. By lifetime, it meant ICE Restart. I will add text to clarify.

>
> - Section 10, IANA Considerations, SDP Attributes: Contact information has
> been changed to IESG and there is a new "URIs" section related to this in
> the References. I haven't heard about this new practice before - can you
> elaborate ?
>

[Suhas] The SDP contact information was updated based on feedback from
Christer where he suggested this is the new way. Bundle spec also does the
same. I will check on the new "URIs" section , its addition was
unintentional.

>
> - Section 10.1.8: Why not use a mux category of NORMAL instead of
> TRANSPORT for the session-level ice-pacing attribute (not that it matters
> much in practice since it's a session-level attribute) ?
>

[Suhas] I thought about it and decided to go with TRANSPORT to align with
ice and transport context for other similar attributes. Do you have a
strong recommendation for using NORMAL ?

>
> I also have some editorial comments which I will send to you off-line.
>

[Suhas] Thanks much. I will get to it ASAP.

>
> Thanks
>
> -- Flemming
>
>
>
> On 3/30/18 5:09 PM, Suhas Nandakumar wrote:
>
> Hello All
>
>   We submitted version 18 that fixes the section numbering issues pointed
> out by Christer
>
> Thanks
> Suhas
>
> On Fri, Mar 30, 2018 at 2:08 PM, <[email-masked]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Multiparty Multimedia Session Control WG
>> of the IETF.
>>
>>         Title           : Session Description Protocol (SDP) Offer/Answer
>> procedures for Interactive Connectivity Establishment (ICE)
>>         Authors         : Marc Petit-Huguenin
>>                           Suhas Nandakumar
>>                           Ari Keranen
>>         Filename        : draft-ietf-mmusic-ice-sip-sdp-18.txt
>>         Pages           : 42
>>         Date            : 2018-03-30
>>
>> Abstract:
>>    This document describes Session Description Protocol (SDP) Offer/
>>    Answer procedures for carrying out Interactive Connectivity
>>    Establishment (ICE) between the agents.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-18
>> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-18
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-18
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
>
> _______________________________________________
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 2 Apr 2018 09:42:50 -0400

On 4/1/18 9:42 PM, Suhas Nandakumar wrote:
>
>
> On Sun, Apr 1, 2018 at 6:05 PM Roman Shpount <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Flemming,
>
>         If an agent uses separate ports for RTP and RTCP, the agent
>         MUST include an SDP rtcp attribute in the "m=" section, as
>         described in [RFC3605].  In the cases where the port number
>         for the RTCP is one higher than the RTP port and RTCP
>         component address is same as the address of the RTP component,
>         the SDP rtcp attribute *SHOULD NOT* be included.
>
>
I think it's fine, but it could just as well be "MAY be included".

-- Flemming
>
> Cheers
> Suhas
>
>
>     Regards,
>     _____________
>
>     Roman Shpount
>
>     On Sat, Mar 31, 2018 at 6:12 PM, Suhas Nandakumar
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Flemming
>
>         Earlier version of the draft didn’t had that restriction. It
>         was added at later point due to wg discussion almost 2 years
>         back. Roman and Thomas Stach would know more details on the
>         exact reasons
>
>         On Sat, Mar 31, 2018 at 12:38 PM Flemming Andreasen
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Understood, however is there a need to actively forbid its
>             use in that case ?
>
>             Thanks
>
>             -- Flemming
>
>>             On Sat, Mar 31, 2018 at 2:27 PM, Flemming Andreasen
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 - Section 3.2.2: Why is it forbidden to include the
>>                 "rtcp" attribute when the RTCP port number is one
>>                 higher than the RTP port number ?
>>
>>
>>             The rtcp attribute in this case is redundant since if
>>             rtcp attribute is absent, RTCP will be sent to same IP as
>>             RTP and port number one higher then the RTP.
>>
>>             Regards,
>>             _____________
>>             Roman Shpount
>>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 2 Apr 2018 09:52:55 -0400

On 4/2/18 2:03 AM, Suhas Nandakumar wrote:
> On Sat, Mar 31, 2018 at 11:27 AM, Flemming Andreasen 
>     Thanks for quickly updating and submitting the document, which I
>     have reviewed. A couple of questions:
>
>     - Section 3.2.2: Why is it forbidden to include the "rtcp"
>     attribute when the RTCP port number is one higher than the RTP
>     port number ?
>
>
> [Suhas]  Since this topic is being discussed at present, i will wait 
> on it for the decision
Ok
>     The text in and by itself seems reasonable, however I am not
>     following how this relates to ICE mismatch and hence why it is
>     part of this list (which in turn makes it difficult to
>     understand). Let's say it's an offer SDP: The default candidates
>     are relayed through a TURN server that the offerer uses, however
>     you are now saying the answerer (agent) needs to create a
> [Suhas]  This section was originally under title "Verifying ICE 
> support" and was Answerer specific procedures. We renamed to 
> "ICE-Mismatch" to align with ICE-Bis. Would the following 
> clarification be more suitable
> <quote>

The problem is that it is preceded by the following:
<quote>

    The agent will proceed with the ICE procedures defined in [ICE-BIS]
    and this specification if, for each data stream in the SDP it
    received, the default destination for each component of that data
    stream appears in a candidate attribute.  For example, in the case of
    RTP, the IP address and port in the "c=" and "m=" lines,
    respectively, appear in a candidate attribute and the value in the
    rtcp attribute appears in a candidate attribute.

    If this condition is not met, the agent MUST process the SDP based on
    normal [RFC3264] procedures, without using any of the ICE mechanisms
    described in the remainder of this specification with the following
    exceptions:

......
</quote>

and hence the text reads as an exception to normal ICE processing (due 
to a mismatch), which I don't believe is what it should (on the contrary 
- it applies to normal ICE processing).

>     - Section 3.3.4: What is considered the "lifetime of the ICE
>     session" ? Does it end when we do an ICE restart ? Some
>     clarification would be helpful.
>
>
Sounds good.
>
>
>     - Section 10, IANA Considerations, SDP Attributes: Contact
>     information has been changed to IESG and there is a new "URIs"
>     section related to this in the References. I haven't heard about
>     this new practice before - can you elaborate ?
>
>
> Christer where he suggested this is the new way. Bundle spec also does 
> the same. I will check on the new "URIs" section , its addition was 
> unintentional.
Ok -maybe we can get Christer to clarify where he got that from.

>     TRANSPORT for the session-level ice-pacing attribute (not that it
>     matters much in practice since it's a session-level attribute) ?
>
>
> [Suhas] I thought about it and decided to go with TRANSPORT to align 
> with ice and transport context for other similar attributes. Do you 
> have a strong recommendation for using NORMAL ?
At some level, it doesn't really matter since it's a session-level 
attribute and hence the whole idea behind mux category doesn't really 
apply (but I guess we decided we need to specify it anyway). NORMAL 
seems to be the "least" non-sense way of specifying it then and also 
seems to be consistent with the majority of existing session-level 
attribute mux categories.

> [Suhas] Thanks much. I will get to it ASAP.

Sounds good.

Thanks

-- Flemming
>>       We submitted version 18 that fixes the section numbering issues
>>     pointed out by Christer
>>
>>     Thanks
>>     Suhas
>>
>>     On Fri, Mar 30, 2018 at 2:08 PM, <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>
>>         A New Internet-Draft is available from the on-line
>>         Internet-Drafts directories.
>>         This draft is a work item of the Multiparty Multimedia
>>         Session Control WG of the IETF.
>>
>>                 Title           : Session Description Protocol (SDP)
>>         Offer/Answer procedures for Interactive Connectivity
>>         Establishment (ICE)
>>         <https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/>
>>
>>         <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-18>
>>         <https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-18>
>>
>>         <https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-18>
>>
>>
>>         Please note that it may take a couple of minutes from the
>>         time of submission
>>         until the htmlized version and diff are available at
>>         tools.ietf.org <http://tools.ietf.org>.
>>
>>         <ftp://ftp.ietf.org/internet-drafts/>
>>
>>         [email-masked] <mailto:[email-masked]>
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 2 Apr 2018 10:44:32 -0700

Hello Flemming

 Please see inline.

Thanks
Suhas

> [Suhas]  Since this topic is being discussed at present, i will wait on it

[Suhas] Will update to say "MAY be included" as suggested.

>> The text in and by itself seems reasonable, however I am not following
>> how this relates to ICE mismatch and hence why it is part of this list
>> (which in turn makes it difficult to understand). Let's say it's an
>> offer SDP: The default candidates are relayed through a TURN server that
>> the offerer uses, however you are now saying the answerer (agent) needs to
>> create a permission in the TURN server?
>>
>
>
>
> and hence the text reads as an exception to normal ICE processing (due to
> a mismatch), which I don't believe is what it should (on the contrary - it
> applies to normal ICE processing).
>
>

[Suhas]. I will send a different email to keep the discussion focussed on
this topic.

>> - Section 10, IANA Considerations, SDP Attributes: Contact information
>> has been changed to IESG and there is a new "URIs" section related to this
>> in the References. I haven't heard about this new practice before - can you
>> elaborate ?
>>
>
> attribute and hence the whole idea behind mux category doesn't really apply
> (but I guess we decided we need to specify it anyway). NORMAL seems to be
> the "least" non-sense way of specifying it then and also seems to be
> consistent with the majority of existing session-level attribute mux
> categories.
>
>
>>> This draft is a work item of the Multiparty Multimedia Session Control
>>> WG of the IETF.
>>>
>>> Offer/Answer procedures for Interactive Connectivity Establishment (ICE)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Apr 2018 14:08:26 -0400

Hi Flemming,

> I think it's fine, but it could just as well be "MAY be included".

I think "SHOULD NOT be included" is cleaner. In the described case rtcp
attribute serves no purpose, so there is a reason not to add it. This
attribute will not break anything but it really should not be there.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Apr 2018 14:38:57 -0400

> attribute will not break anything but it really should not be there.
After thinking about this a bit more "MAY be omitted" also works for me and
makes more sense together with the previous sentence where rtcp attribute
MUST be included.
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 2 Apr 2018 11:51:33 -0700

On Mon, Apr 2, 2018 at 11:38 AM, Roman Shpount <[email-masked]> wrote:

>>>> MUST include an SDP rtcp attribute in the "m=" section, as described in
>>>> [RFC3605].  In the cases where the port number for the RTCP is one higher
>>>> than the RTP port and RTCP component address is same as the address of the
>>>> RTP component, the SDP rtcp attribute *SHOULD NOT* be included.
>>>>
>>>>
> After thinking about this a bit more "MAY be omitted" also works for me
> and makes more sense together with the previous sentence where rtcp
> attribute MUST be included.
>

[Suhas] Thanks Roman and Flemming. Will update in the next version.