Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords

[Roman Shpount <[e-mail]>]

On Tue, Jan 22, 2019 at 4:04 PM Adam Roach <[e-mail]> wrote:

> In terms of current offer-generation behavior, I had an brief exchange
> with the Chrome folks; the offers it generates *always* indicate its
> preferred (default) candidate in the m=/o= line, regardless of the
> candidate in use. Since the preferred candidate will always be UDP, the
> transport is always sent as UDP/TLS/RTP/SAVPF.
>
>
Just to clarify, there is no argument that preferred (default) candidate
should be used in the m=/o= line.

When ICE restart is initiated, UDP based candidate must be present (or in
case of trickle ICE eventually added), used as a default candidate, thus
UDP based protocol must be used in the m= line in both offer and answer.

The issue is the offer generated when ICE restart is not initiated and TCP
candidate is currently nominated. TCP candidate is the only candidate which
is present in both offer and answer. It is also the default candidate. No
UDP candidate will be added it any point during the offer/answer exchange.
Both end points support TCP protocol, since TCP candidate was already
successfully nominated. In  this case, according to RFC5245 abd
ice-sip-sdp, TCP protocol must be used in the m= line in both offer and
answer. JSEP is trying to change this to use UDP based protocol even though
default candidate is TCP.

Regards,
_____________
Roman Shpount