Re: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?
Martin Thomson <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CABkgnnWSm0T3n0Lrqx3WCqDmPutLDXtkfwK8Pc+0fYdJa+q=hw@mail.gmail.com> |
On 23 May 2017 at 20:15, Christer Holmberg <[email protected]> wrote: > But, what about data received before the completion is received? Well, I'd prefer to drop that, because buffering is tricky, but as I said, holding it without even decrypting it could work. Note that many DTLS-SRTP implementations won't even allow you to call the exporter until the handshake is complete. In order to even get the data to arrive you have to do some inadvisable things to the stack, such as accepting the peer's certificate, then you have to kill the connection when the a=fingerprint arrives and doesn't match. It's much easier to validate inline. > Also, if I understand the FEDEX use-case, not only would you have to be > able to receive media - if you are e.g., going to provide DTMFs you could > also have to SEND data? Or? Yeah, sending DTMF to who-knows isn't a good idea. I'm not clear on whether sending DTMF is part of the arrangement. Sounds like a great way to avoid tarriffs altogether; I'm surprised that service providers would even allow that. This is why I think that this "unverified media" is the wrong solution here. It's not impossible to have an authenticated session and accomplish these goals.