Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

[Harald Alvestrand <[e-mail]>]

Den 10. jan. 2017 16:44, skrev Magnus Westerlund:
> Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand:
>> Den 22. des. 2016 18:30, skrev Eric Rescorla:
>>>      __
>>>
>>>     Okay, I agree that having any rules for what you should offer here
>>>     based on what the actual outcome is not the best idea here. I think
>>>     the rules should be based on capability and intent. So if you only
>>>     are going offer TCP candidates, then you clearly should use TCP/…,
>>>
>>>
>>> I'm going to push on this. If we've already agreed that mismatches are
>>> normal, why should we do that? Wouldn't it be better to just effectively
>>> deprecate this field?
>>>
>>
>> Concur with EKR.
>>
>> This field (the TCP/UDP part of the protocol field) was defined in a way
>> that makes its original purpose (to negotiate profiles) not only
>> impossible while using ICE, but actively harmful, because you end up
>> telling lies in very many cases, so people will have to accept things
>> that don't match reality.
>>
>> Make the world as simple for implementors as possible: Send a fixed
>> string, and accept all strings.
>>
> 
> Okay, can we please be precise with what is suggested here. Because what
> you write above, and what EKR proposed is not really the same thing. The
> issue proposed that it was fine to set either of the strings. You saying
> a fixed string. I want to ask you which UDP/... or TCP/..., or even
> ICE/DTLS/RTP/SAVPF?

The current JSEP language is:

5.1.3.  Profile Names and Interoperability

   For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
   RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of
   these two profiles for each media m= line they produce in an offer.
   For data m= sections, JSEP endpoints must support both the "UDP/DTLS/
   SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

The current proposal (as I interpret EKR) is to replace

        ....and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

with

            ....and MUST indicate UDP/TLS/RTP/SAVPF for each data m= line
   they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, this consistent with ICE eventually
   selecting either either UDP or TCP.

> 
> From a strict clarity issue using ICE/... would be my preferred. But,
> that is probably going to throw some implementations, especially
> gateways. It will also require us to actually go write the registration
> to explain what it is.

We lost clarity when ICE was introduced without redesigning the
"protocol" field. Trying to get it back is not helping anyone.

> 
> Using UDP is likely the most compatible and will only fail in gateway
> cases where there are no UDP candidates and the gateway fail to pick
> that up.
> 
> Using TCP when there are no TCP candidates are equally misleading to
> gateway cases.
> 
> The above is why I proposed that implementation capabilities and any
> configuration to limit what functions being used would be an appropriate
> choice.
> 
> I hope at least we can agree that an JSEP Answer MUST use the PROTO
> string of the OFFER?

We agreed on that long ago.

Section 5.3.1 of JSEP:

   o  The <proto> field MUST be set to exactly match the <proto> field
      for the corresponding m= line in the offer.