Re: [rtcweb] Default proto transport in JSEP

[Justin Uberti <[e-mail]>]

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

> On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti <[e-mail]> wrote:
>
>> 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.
>>
>
> I think a couple of popular hardware VoIP phones and one widely used SIP
> based business communication/messaging product will trigger a mismatch in
> case of incorrect protocol (non UDP if UDP candidates are present and non
> TCP, if only TCP candidates are present according to their ICE
> implementation document). I have to say, that these things do have a
> tendency to change between product updates and I have not tested this
> product for a while. Our own products currently match the protocol to
> default candidate, so we did not need to retest this issue.
>
> TCP based transport will happen for any subsequent offer/answer exchange
> when TCP candidate is nominated. Only a single TCP ICE candidate will be
> present in the session description, so that protocol in m= line will have
> to be TCP. In case of the above mentioned product, their ICE protocol
> implementation document says that call must be terminated, if in subsequent
> offer, protocol in the m= line does not match the protocol in the ICE
> candidate.
>

VoIP phones will almost certainly never receive TCP ICE candidates from a
WebRTC implementation, which only gather active TCP candidates.

Anyway, we have the 3 choices listed below. We differ on which is the most
pragmatic solution. If the WG has enough voices in support of #2 or #3 to
overturn the consensus of #1 from IETF 103, I will write it up accordingly.

>