Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

[Roman Shpount <[e-mail]>]

Hi Flemming,

On Tue, Nov 27, 2018 at 6:14 PM Flemming Andreasen <[e-mail]>
wrote:

> It doesn't seem like this thread has reached any conclusion - how do
> people suggest moving forward here ?
>
>
During this discussion I had a chance to think about this issue quite a bit
and I would suggest the following solution:

As far as I can see, RFC 5245, ice-sip-sdp, jsep-25 section-5.2.2, sctp-sdp,
rand fc4583bis all differentiate between initial offer/answer exchange
which initiates ICE restart and subsequent offer/answer exchanges which do
not. All these documents specify that UDP based m= line proto SHOULD be
used during ICE restart and that proto MUST match the only ICE candidate
present when not doing ICE restart. The only place that does not
differentiate between the two is JSEP Section 5.1.2. This section tries to
simplify things and apply the same rule to both exchanges saying that
"UDP/TLS/RTP/SAVPF"
proto MUST always be used. This is the root cause of the current issue. I
suggest to update JSEP section 5.1.2 to match the rest of the documents to
say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When
ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if
default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto
MUST be used if default (only) candidate is TCP candidate.

While discussing the current issue, I see that there is something that can
be clarified in ice-sip-sdp and potentially in JSEP. Specifically it make
sense to specify better what to do during ICE restart when UDP based proto
is used in the m= line, as it is recommended, but the only candidates
collected are TCP. This can happen in WebRTC implementations due to trickle
ICE, if only TCP candidates are collected initially. Outside of WebRTC this
can happen due to the client generating an answer being configured to
collect only TCP based candidates (Microsoft ICE implementation guide lists
such use case specifically). I think in such cases, if no ICE candidates
match the proto in the m= line, then address IN IP4 0.0.0.0 should be used
in the c= line and port 9 should be used in the m= line. This is consistent
with current behavior of trickle ICE when no candidates have been collected.

In any case, it looks to me that only JSEP section 5.1.2 needs to be
modified to make all the current documents consistent. JSEP is already
being modified to fix this issue, so I would suggest to modify it in a way
that will cause the least disruption. If needed I can provide the pull
request to fix this.

Regards,
_____________
Roman Shpount