Re: [rtcweb] Default proto transport in JSEP

[Justin Uberti <[e-mail]>]

Are you aware of any implementations that will trigger ICE mismatch if the
proto does not match? Also, this would only happen in situations where the
client offers *only* TCP candidates, which would require manual filtering
by the client and is clearly a corner case.


On Mon, Nov 19, 2018 at 4:16 PM Roman Shpount <[e-mail]> wrote:

> On Mon, Nov 19, 2018 at 6:08 PM Justin Uberti <[e-mail]> wrote:
>
>> Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245
>> <https://tools.ietf.org/html/rfc5245#section-5.1>:
>>
>>    The agent will proceed with the ICE procedures defined in this
>>    specification if, for each media stream in the SDP it received, the
>>    default destination for each component of that media 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.
>>
>> Ergo, I don't think this proposal will fly. Of the three options being
>> considered (below), only #1 avoids violating 5245 while simultaneously
>> minimizing busywork.
>>
>> 1) (current) Match IP and port, but stipulate an exact proto value
>> 2) Match IP, port and proto
>> 3) Set IP, port, and proto to fixed values
>>
>> If we think avoiding ice-mismatch when interacting with 5245 endpoints is
>> not important, that point needs to be made clearly. Otherwise, I think the
>> easiest path is to update ice-sip-sdp to permit #1 as a legacy interop
>> behavior (and it can continue to recommend #3 for interop with 8445
>> clients).
>>
>
> The RFC 5245 does not define any candidate transports except UDP, so it
> does not seem to mention protocol in most of the examples. I believe that
> language in 5245 that you are quoting actually specifies that default
> address, port and protocol foundation in c= and m= line must match.
>
> Specifically it says that  "for each media stream in the SDP it received,
> the default destination for each component of that media stream appears in
> a candidate attribute."
>
> If we look the term definitions,in
> https://tools.ietf.org/html/rfc5245#section-3 it says:
>
> Default Destination/Candidate: *The default destination for a component
> of a media stream is the transport address that would be used by an agent
> that is not ICE aware. *For the RTP component, the default IP address is
> in the c line of the SDP, and the port is in the m line. For the RTCP
> component, it is in the rtcp attribute when present, and when not present,
> the IP address is in the c line and 1 plus the port is in the m line. A
> default candidate for a component is one whose transport address matches
> the default destination for that component.
>
> Transport Address: The combination of an IP address and transport protocol
> (such as UDP or TCP) port.
>
> From this  it looks like the document simply assumes that port has type
> which is UDP or TCP and in order for port to match both its value and type
> must match.
>
> Furthermore, without protocol foundation candidate default destination is
> ambiguous and cannot be used without ICE.  So, 1, as proposed will likely
> to cause ICE mismatch with existing implementations and will not be RFC
> 5245 compatible.
>
> 2 is the only RFC 5245 compatible option.
>
> Regards,
> _____________
> Roman Shpount
>
>
>