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

[Roman Shpount <[e-mail]>]

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.

If JSEP end point receives an offer with UDP/DTLS/SCTP or
UDP/TLS/RTP/SAVPF, it MUST respond with the same proto and MUST include udp
candidates (and use udp as a default candidate if JSEP endpoint is
providing default candidates).

If JSEP end point receives an offer with TCP/DTLS/SCTP or
TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto and MUST include
tcp candidates (and use tcp as a default candidate if JSEP endpoint is
providing default candidates).

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, or
does not match ICE candidates provided. I think this will improve interop
and can be satisfied by all existing implementations.

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