actpass redux
Eric Rescorla <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CABcZeBMd2BZgyeFnqafTVyGga4FMoK0xJkPCv0y_wvmBWsg+xg@mail.gmail.com> |
Hi folks, RFC 5763 required (and JSEP imported) that all offers include a=setup:actpass However, assuming I am reading: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 correctly, S 4.2 allows the initial offer to contain anything, though encourages actpass: When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique value. If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 'passive' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. For subequent offers, it also gives flexibility but points at 4145. So... 1. Changing the behavior for initial offers seems like it presents a serious interop risk, because previously you could depend on the offer being actpass. 2. JSEP requires actpass for all offers, so at least it's stricter. What was the rationale for these changes? Feel free to point me at the mailing list discussion where that happened. -Ekr Hi folks, RFC 5763 required (and JSEP imported) that all offers include a=setup:actpass However, assuming I am reading: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 correctly, S 4.2 allows the initial offer to contain anything, though encourages actpass: When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique value. If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 'passive' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. For subequent offers, it also gives flexibility but points at 4145. So... 1. Changing the behavior for initial offers seems like it presents a serious interop risk, because previously you could depend on the offer being actpass. 2. JSEP requires actpass for all offers, so at least it's stricter. What was the rationale for these changes? Feel free to point me at the mailing list discussion where that happened. -Ekr _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic