Re: [MMUSIC] Default proto transport in JSEP

It doesn't seem like this thread has reached any conclusion - how do 
people suggest moving forward here ?

Thanks

-- Flemming (with MMUSIC co-chair hat on)

On 11/20/18 8:25 PM, Roman Shpount wrote:
> On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <fluffy@iii.ca 
> <mailto:fluffy@iii.ca>> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic