Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Thanks for the explanation!

> On 5. Aug 2019, at 20:27, Roman Shpount <[e-mail]> wrote:
> 
> Hi Mirja,
> 
> Thank you for your comments.. Let me try to address some of them
> 
> On Mon, Aug 5, 2019 at 1:19 PM Mirja Kühlewind via Datatracker <[e-mail]> wrote:
> 2) One quick question: Why is a port value of "9" used to signal use of the
> default destination, instead of e.g. "0"? Is that because port "0" is used to
> reset the data stream? However, couldn't this combination of address and port
> "0" not be treated differently? Or is that to avoid any potential false
> connections? How could that happen? Isn't there a better way to do that? I
> mainly would like to understand what the reason is and maybe request to also
> explain this in the document.
> 
> The reason port "9" is used is due to port "0" having a special meaning in offer/answer SDP negotiations. Port "0" specifies that "m=" section in SDP is not used in the offer or that data stream specified by this "m=" section is refused in the answer. Most of the SDP offer/answer implementations simply ignore the whole m= section when they see port "0" in the "m=" line. On the other hand, when port "9" is set in the "m=" line and "0.0..0.0"/"::" address is set in the "c=", this 'm=" section is still processed. Setting "c=" line address to  "0.0.0.0"/"::" with port in "m=" line to "9", tells the ICE agent that ICE mismatch is not triggered, regardless of what ICE candidates are specified for this "m=" section.  This is specifically used in combination of trickle ICE, where SDP can be sent before ICE candidates are collected, so default candidate cannot be picked and "0.0.0.0"/"::" and port "9" are used as a placeholder.
>  
> 4) Question on sec 4.1:
> "   <transport>:  indicates the transport protocol for the candidate.
>       This specification only defines UDP.  However, extensibility is
>       provided to allow for future transport protocols to be used with
>       ICE by extending the sub-registry "ICE Transport Protocols" under
>       "Interactive Connectivity Establishment (ICE)" registry."
> The registry also contain an entry for TCP (see RFC6544). However, I also
> wonder a bit why a new registry was created initially instead of just using the
> protocol numbers or keyword in the IANA Protocol Numbers Registry...?
> 
> This registry was setup to provide a place to register an RFC which defines ICE procedures for a specific transport protocol. ICE cannot operate over all the protocols defined in IANA protocol registry and requires specific procedures for protocols where it can operate.. Futhermore, protocols used by ICE are not necessarily protocols that are defined by IANA. For instance, there was a discussion of defining ICE over TLS/TCP, which is not a IANA protocol.
> 
> The rest of the comments are mostly editorial and I would let people primarily editing the document address them.
> 
>  Best Regards,
> ______________
> Roman Shpount