Re: [rtcweb] Default proto transport in JSEP

[Roman Shpount <[e-mail]>]

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.

Regards,
_____________
Roman Shpount