Re: [Sipping] new draft on ICE for opening SIP dialogs: draft-lowekamp-sipping-ice-for-sip-00

[Henning Schulzrinne <[e-mail]>]

I'll also note that tunneling, without SIP ICE, one of the solutions  
mentioned in the draft, would essentially reduce the additional  
latency beyond DHT lookup to zero for the initial INVITE. Re-INVITE  
and BYE would still suffer the penalty, but they are typically less  
time-critical.

I admit that I'm rather worried about the additional complexity  
implied by the approach, given the various interactions of this  
mechanism with, say, outbound. We seem to have difficulties achieving  
interoperability of basic SIP functionality, including TCP and TLS, so  
adding yet more complexity and alternate mechanisms would seem to  
require a fairly careful consideration.

Henning

On Nov 17, 2007, at 1:50 AM, Jonathan Rosenberg wrote:

> Bruce,
>
> Interesting draft.
>
> My biggest concern is that in practice this would never be utilized  
> in a regular SIP proxy chain since it requires every proxy along the  
> path to support the mechanism. I wonder if there are intermediate  
> solutions that allow path optimization along subsets of the path.  
> Not obvious how to do that, but a thought.
>
> It was entirely unclear to me how the e2e TLS connection is  
> authenticated. What certificate does each endpoint use? It seems  
> like we need something like DTLS-SRTP that exchanges a fingerprint  
> of a self-signed cert in the SDP routed through the proxy chain, and  
> that is used to drive the e2e TLS connection.
>
> Seems like a big part of the motivation here is in p2psip, to find a  
> way to route the initial INVITE tunneled through the DHT, and then  
> later on do ICE to optimize this out. The purported reason for this  
> is that call setups are faster when the INVITE is tunneled through  
> the DHT. That may be true, but I think the difference is irrelevant.  
> In a consumer DHT, you'll have nodes all over the world. So each hop  
> through the DHT can be pretty long, 100ms+ perhaps. If it takes log  
> hops to get through, for any reasonable sized DHT this is between 10  
> and 20 hops. So you are already in the 1-2 second delay range to  
> cross the DHT. ICE itself will ideally complete in a few RTT between  
> caller and called party, and thus is a small percentage of the  
> overall penalty you already paid traversing the DHT. Given that the  
> mechanism in here is a big change in SIP and probably ONLY usfeul in  
> the p2psip case (given the comment above on limited applicability  
> because each hop needs to support it), I think we better understand  
> the real delay improvements associated with it.
>
> Thanks,
> Jonathan R.
>
>
> Bruce Lowekamp wrote:
>> Title:             Using ICE to establish SIP Dialogs
>> Abstract:
>> This draft explores a way SIP can be extended to allow a new dialog
>> directly between the endpoints to replace an initial dialog that had
>> one or more proxies in the signalling path.  This technique relies on
>> ICE to perform hole punching that allows a direct connection to be
>> used in deployments where a sip-outbound proxy or SBC is used to
>> establish SIP connections across NAT or firewall boundaries.  It can
>> also be used to replace such a dialog with a secure connection
>> directly between the endpoints.  This technique can be applied to
>> traditional proxy-based SIP routing as well as to emerging P2PSIP
>> deployments that lack centrally located proxies.
>> This draft describes early work that evolved from ideas initially
>> developed for P2PSIP that are no longer being pursued.  We are
>> interested in feedback on whether there is broader interest in these
>> techniques.
>> Author(s):
>> Bruce Lowekamp, [e-mail]
>> David Bryan, [e-mail]
>> The automatic submission tool failed on this draft, but it's  
>> currently
>> located at
>> http://www3.ietf.org/proceedings/staging/draft-lowekamp-sipping-ice-for-sip-00.txt
>> Bruce
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [e-mail]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP