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

["Bruce Lowekamp" <[e-mail]>]

Thanks for all the feedback.  Sorry to take so long to reply.  I'm
going to reply to all three responses at once, inline.


On Nov 17, 2007 1:50 AM, Jonathan Rosenberg <[e-mail]> 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.
>

I think if you had a sequence of proxies that all support this with
the tag in their header, it would be possible to do it; I would think
it should be a somewhat different mechanism where the proxies simply
collectively decide to start routing the same dialog over the direct
path.  But I am unsure how common such a long chain of proxies would
be and am concerned about the complexity of implementing it.  It would
be interesting to work out what would be involved, though.

> 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.
>

I think that allowing the end-to-end encryption is a pretty
interesting use, but you're right, I completely ignored
authentication, primarily because I was hesitant to specify a
particular mechanism.  SRTP would be a great way of handling it, and
is probably the most implementable, but I didn't want to ignore
leap-of-faith or some central authority that the two endpointsb both
trust.



> 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.

We should probably move this to p2psip if we get into too much detail,
but I think my thoughts on the cost are along the lines of Henning's.
If you do ICE across the DHT to open the SIP dialog, then send an
INVITE and do ICE to establish the media, you have paid the around the
overlay latency for the SIP connection, ICE for the SIP connection,
and then the direct ICE for media.  If you route the INVITE around the
overlay first, you have media flowing after the around the overlay
latency and first ICE negotiation.  So  you have media in one ICE
negotiation latency shorter time if you do the INVITE tunneled across
the overlay.  Then you can pay the cost of moving the dialog in the
background where the user doesn't perceive it.

I think there are some optimizations that can be applied to both
approaches in terms of pre-advertising candidates, but there are a lot
of open issues there, so I'd rather stick with the straightforward
approach for now.

On 11/17/07, Henning Schulzrinne <[e-mail]> wrote:
> 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.
>

I agree the complexity is an issue.  I think in terms of evaluating
the complexity, I'm willing to ignore the complexity of ICE because I
will assume implementors already have ICE for media.  The question is
of adding such negotiation for SIP.  I don't believe it's that
terribly complex (all the parts are already there, they just need to
be connected), and it has the virtue that the new dialog is being
created separately and the worst that will happen is that it won't be
established, so the replacement never occurs.  If it's just being
established as an optimization, nothing is lost and the UA doesn't
really have a particualr reason to notice or care.

Is the complexity that is there worth it?  The end-to-end security
scenario is, to me, one of the more convincing scenarios where it
achieves a benefit that is hard to achieve otherwise.  In terms of
removing proxies from dialogs as an optimization, I haven't done any
calculations or measurements, but I think it's an interesting question
how much load can be removed from proxies such as sip-outbound
deployments, especially in terms of offloading things such as
subscriptions that require periodic updates.


On Nov 19, 2007 2:17 AM, Christer Holmberg
<[e-mail]> wrote:
>
> Hi,
>
> Some questions.
>
> First, it is true that there may be an intermediate which doesn't need
> to be in the path once the call has been established. But, normally is a
> reason why a proxy/intermediate insert a Record-Route. Why would they do
> that if they at the same time say that it is ok to remove them from the
> call path?
>

I think the most important reason would be if the proxy is there for
NAT or firewall traversal, but not to accomplish a call-management,
policy, billing, etc roll that requires it to be on-path for the
dialogs.  I think the clearest example of this is a single
sip-outbound proxy, which is deployed solely to facilitate NAT
traversal, but really has no interest in monitoring ongoing dialogs,
just helping to establish them.

> Second, in some environments user plane resources are reserved by some
> intermediate, and/or gate type-of-functions are controlled by some
> intermediate. These resources must be available during the whole call,
> but if the resource controlling intermediates are removed from the path,
> how will they know when to release the resources? Or, do you assume a
> terminal will only once send a "normal" INVITE, resources will be
> reserved, and then they will be available "forever"?

It was important to us that we preserve the ability of a proxy to
remain in the route if it desires, although for maximum efficiency, it
seems like it's usually best to establish a direct end-to-end
connection.  I'm unsure about the "forever" aspect of this. We
deliberately left the concept of "use this new flow for future dialogs
between these two UAs" as an open issue.  That's a clear gain in
efficiency (especially for non-dialog exchanges such as MESSAGE), but
I think it would require all of the proxies on the route (not just the
record-route proxies) to agree to authorize it.


>
> Third, you seem to assume that the media path will be end-to-end from
> the beginning. But, a B2BUA may also control a media proxy. And, even if
> the B2BUA is removed from the signalling path, the media may still
> traverse it.

Sorry, certainly didn't mean to imply that.  Obviously if a b2bua
feels it needs to be on-path for media and there is no direct path, it
seems unlikely that the SIP connection could be direct.

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