search

rtcweb-wg / jsep

33 stars 32 forks source link

Resolve handling of m= line protocol identifier #70

Closed juberti closed 10 years ago

juberti commented 10 years ago

IIRC, discussion on mailing list came down in favor of emitting RTP/SAVPF but accepting RTP/SAVPF or UDP/TLS/RTP/SAVPF. Need to confirm and adjust document accordingly.

fluffy commented 10 years ago

Also need to address what you do if you an AVPF but with a fingerprint indicating it can do SAVPF, or a SAVP with with other SDP indicating it can do SAVPF. The most interoperable solution is if the ther3e is any indication in SDP that one can do the S or the F in in SAVPF, just do it even if there was no SAVPF.

juberti commented 10 years ago

Options as I see them: 1a) Generate RTP/SAVPF only. Accept RTP/SAVPF, but also UDP/TLS/RTP/SVPF. Echo back whatever we get in answer. 1b) Generate RTP/SAVPF only. Accept RTP/SAVPF, but also RTP/AVP and related variants. Echo back whatever we get in answer 2) UDP/TLS/RTP/SAVPF or TCP/TLS/RTP/SAVPF, depending on active candidate. Also, change to UDP/TLS/SCTP, or TCP/TLS/SCTP, as appropriate.

ekr commented 10 years ago
  1. Emit UDP/TLS/RTP/SAVPF. Ignore whatever people send you.
  2. Emit UDP/TLS/RTP/SAVPF. Echo whatever people send tou.
fluffy commented 10 years ago

The one key thing I want to work is if we receive a AVP but it has a a=fingerprint, we should not rejected it but treat it like SAVPF. Lots of people do this to offer both secure and insecure.

I would suggest we 1) emit what the specs say 2) receiver pretty much anything but more or less ignore the string - more specifically a) if there is a fingerprint, always treat it as having an S on AVP or AVPF b) if there is a=rtcp-fb then treat as if has an F on SAVP or AVP 3) answers echo what was in offer 4) future offers emit what spc says regardless of was in original offer

ekr commented 10 years ago

Cullen, I don't understand 2a 2b since S and F are required for WebRTC, right?

juberti commented 10 years ago

I am OK with this, although I could go either way on 2), and it would be nice to avoid 3) when the input is not what the specs say. I suggest we raise 2/3 to the WG.

fluffy commented 10 years ago

Ignore F for a second - This issue is an offer from a SIP device that do both SRTP and RTP. They are going to send you a RTP/AVP with a a=fingerprint to indicate they do SRTP. They do this so they are backwards compatible with things that only do RTP. So the browser needs to be willing to receive an offer with RTP/AVP and a fingerprint and treat it like it got UDP/TLS/RTP/SAVP

More or less the same story with the F if that things that do both AVPF and AVP, will send AVP to be backwards compatible with stuff that only does AVP.

The question Justing raised was if the Offer has RTP/APV, does the answer needs to be RTP/AVP or should it be UDP/TLS/RTP/SAVPF. I doubt it matters much as you are talking to something that supports both so I tend towards send UDP/TLS/RTP/SAVPF in the answer.

juberti commented 10 years ago

I am OK with what Cullen says since it basically means we always generate the correct thing, and always ignore what we get.

It is probably worth pointing out that even between "correct" endpoints, in half-trickle cases, there is the unlikely but possible case that you get an offer with TCP/TLS/RTP/AVPF and have to respond with UDP/TLS/RTP/AVPF.

juberti commented 10 years ago

Consensus in the room at IETF 90 to do [UDP|TCP]/TLS/RTP/SAVPF in offers/answers we generate (i.e. the correct thing), and tolerate /RTP/ in remote descriptions. Also need to update SCTP drafts to do [UDP|TCP]/TLS/SCTP instead of DTLS/SCTP in what we generate (and tolerate DTLS/SCTP from remote side).