Re: actpass redux
Iñaki Baz Castillo <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CALiegfka7-YatS0YGQEA_VmJDDQegr3ocb8kPLH=kLWyL6EZjA@mail.gmail.com> |
2017-06-13 20:23 GMT+02:00 Christer Holmberg <[email protected]>: > I don't necessarily disagree with you, and I don't know if your e-mail is off-topic for MMUSIC, but it for sure IS off-topic for THIS thread, and the draft/charter item discussed :) Hi Christer, Probably you are right, and sorry for that. Being honest, I started writing a very different email exposing my experience with the issue being discussed in the thread. It said something as follows: I've seen the "SDP DTLS role conflict" in many implementations. AFAIR older versions of Firefox and Asterisk wrote, in a re-offer, an a=setup attribute with the effective value (active or passive) as negotiated during the initial O/A, which breaks the RFC because it MUST be "actpass", so Chrome complained. I've also seen (and reported) that FreeSwitch changes its DTLS a=setup role during a re-negotiation, but the funny thing here is that it was just a cosmetic change in the SDP (internally FreeSwitch wants to keep the initially negotiated DTLS connection regardless what it actually writes in the re-offer): https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-10258/FS-10258.html But after writing it, I've realized that if it's so complex for existing implementations to deal with this specification rule (still in 2017) changing the spec or creating a new one won't help much (at least in the short term), so I got really frustrated and ended sending my original text. Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic