[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Additional use cases? (Re: Plan for moving forward)




Actually the use cases probably won't be a big problem. If the ClientHello can be sent by the caller via the signaling path, both cases, the caller being the client or the server can be addressed. Nothing else needs to change, AFAICT.

thanks,
Lakshminath

On 6/7/2007 6:28 AM, Eric Rescorla wrote:
At Wed, 06 Jun 2007 22:41:34 -0700,
Lakshminath Dondeti wrote:
I guess I talked about the generic case a few times, so let's start with an example. Consider the use case of using calling cards

Alice is a SIP Phone, and Uma wants to use it to make a call to Bob (Calling card Server).

Case 1: Uma registers Alice as an authorized phone with Bob. The current model of DTLS-SRTP works (although it reverses the client-server relationship).

Why does this reverse the client-server relationship?

1. DTLS-SRTP requires that both sides have certificates, but EITHER
side can have a self-signed cert or a third-party cert. This is true
no matter which side is client or server.
2. The client-server relationship in DTLS-SRTP is actually independent
of who is the caller. It's controlled by passive/active attributes
in the SDP. In general, it's attractive for the answerer to be the
client, purely for the performance reason that if you're not using
ICE you want the ClientHello to be sent immediately to minimize RTTs.
[With ICE, the performance issues are more complicated and depend
on which side is controlling and whether you are doing aggressive
or regular nomination].


Case 2: Alice is any SIP Phone and Uma makes a call using it. Uma may accept Bob's identity asserted through the SIP infrastructure, but wants to authenticate via a secure channel established with Bob authenticated and Uma will authenticate by sending calling card information (username, password, or just password) as DTMF tones in the media path. (Note: Uma may not necessarily trust Bob's identity asserted through the SIP infrastructure.)

Case 3: Bob's identity is asserted in the media path and Uma enters the calling card information as DTMF tones in the media path.

In other contexts, the terms user-identity and device-identity have also been used.

Note that priority call placement use case is similar.

I don't understand why you think that any of these cases presents
a problem.
You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
which are all about protecting the signalling channel and binding
it to the media and then you pass the DTMF or whatever in the
media. This works fine.

-Ekr