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

[Roman Shpount <[e-mail]>]

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