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

[Eric Rescorla <[e-mail]>]

On Mon, Jan 16, 2017 at 4:53 PM, Roman Shpount <[e-mail]> wrote:

> For clarity, this is what I would suggest for JSEP:
>
> JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.
>

Yes.


If JSEP end point receives an offer with UDP/DTLS/SCTP or
> UDP/TLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.



> and MUST include udp candidates (and use udp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree with this. It should offer whatever candidates it wants
and/or are determined by policy. For example, if the implementation is set
to relay-only, it will be restricted to whatever the TURN relay will do.


If JSEP end point receives an offer with TCP/DTLS/SCTP or
> TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.



> and MUST include tcp candidates (and use tcp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree for the reasons above.




If non JSEP end point responds with a protocol that does not match the
> offer, this is considered an error regardless of the ICE candidate supplied
> in the answer.
>
> So, what I want is for JSEP not to generate offers with TCP/blah and not
> to generate answers were protocol does not match the protocol in the offer,
>

Yes.



> or does not match ICE candidates provided. I think this will improve
> interop and can be satisfied by all existing implementations.
>

I don't think trying to match the candidates to the proto line is useful,
especially when you are doing trickle ICE.

-Ekr


Generic requirements for ICE outside of JSEP can be more complex since we
> need to explain what will happen when end point receives an offer with
> TCP/blah but does not support TCP candidates. Also, outside of JSEP, things
> like ICE mismatch come into play. This, of cause, can be discussed and
> decided elsewhere, not in JSEP.
>
> Regards,
> _____________
> Roman Shpount
>