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

[Roman Shpount <[e-mail]>]

On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <[e-mail]> wrote:

>
> Sounds like the ice-sip-sdp draft has not concerned itself much with
> working with the existing deployed endpoint which treat 0.0.0.0 as a hold
> indicator. I think the JSEP solution will work much better in practice.
>
> This is discussed a bit in
> https://tools.ietf.org/html/rfc6337#section-5.4
>
>
I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP,
and recently trickle ICE. The ice-sip-sdp draft did not break anything new.
All of this was broken in RFC 5245. None of these new protocols work with
endpoints which treat 0.0.0.0 as a hold indicator since all of them need
media addresses of both endpoints in order to work. End point cannot use
0.0.0.0 to create a send only stream. Both addresses are still needed to
creat it. All of these new protocols assume that endpoints use
a=sendonly/a=inactive instead of 0.0.0.0. This is not a major problem in
practice, since end points which use 0.0.0.0 hold, do not use ICE or
DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not
put candidate or fingerprint attributes for this m= line, which avoids the
conflict.

If we are being pedantic, it was trickle ICE that decided to re-use 0.0.0.0
hold for other purposes. The ice-sip-sdp simply added that if default
candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never
triggered, which has no effect on using 0.0.0.0 for hold. This language was
added to make ice-sip-sdp implementations to be compatible with future
trickle ICE implementations.

Also, if you are concerned with breaking changes, sdp-bundle changed using
port 0 for disabled m= lines, which will likely break a lot of B2BUA, since
B2BUA often drop all the attributes from disabled ports.

Regards,
_____________
Roman Shpount