Elwell, John wrote:
Vijay,
This deals with straightforward forking scenarios. What about a proxy
that is scripted to fork in parallel to two destinations, and then, if
they both fail to answer, fork to a third destination? Or a proxy that
is scripted to forward to one destination, and then, if it fails to
answer after a certain time, fork to a second location without
cancelling the request at the first destination?
Some of these cases can be handled by attaching q-values to the contacts
in the 3xx, if the UA cooperates by doing the ones with equal q-value in
parallel and the ones with different q-values in descending q-value order.
But it doesn't deal with more complex policy. And of course if this is
done by the callee's home proxy then it can be certain the policy is
followed. If it is deferred to the caller then you can't be sure.
Of course this is to some extent a battle over who's policy should be
followed, and there is no single right answer here. But its probably
safe to assume that many callee's won't want to give up control over this.
An alternative I suggested earlier, that nobody commented on, is to
start out with a regular INVITE, which can potentially fork. After a
dialog is established, do a CONNECT/Replaces to establish a secure
session to the target. This could be done during an early dialog, or
after the final dialog is established. This could be triggered by
presence of "Supported:sipsec" in the response.
Paul
John
-----Original Message-----
From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED]
Sent: 19 June 2007 17:35
To: Francois Audet
Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John
Subject: Re: [Sip] draft-gurbani-sip-sipsec-01
Francois Audet wrote:
Agreed.
Basically, say the "CONNECT" ended up in 3 different
directions after
a 3XX with 3 contacts. The UAC would set up the end-to-end TLS
connections from the UAC to the 3 contacts.
Then the INVITEs have no intermediaries, so they can't fork.
OK; returning a 3xx seems to be preferred. Then, so that we can
update the next revision appropriately, here is some rough text:
A proxy that accesses a location service to route a CONNECT
request and discovers more than one contact bound to that
AoR MUST format a 3xx-class response with the contacts discovered
from the location service. This response is subsequently
sent upstream.
A proxy that receives a 3xx-class response as a result of
proxying a CONNECT request downstream MUST NOT recurse on the
receipt of the 3xx-class response. Instead, it MUST send the
response upstream.
When a user agent receives a 3xx-class response from its
downstream server with multiple Contact headers, it MAY decide
to fork in parallel or in serial depending on its software
capabilities and configuration policies. Alternatively, it
MAY analyze the received Contact headers and choose to send it
to a particular destination that it suspects would stand the
best chance of eliciting a successful response.
OK?
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
