Yeah, we tought about that. The problem is that the INVITE is loaded with too much information that would then leak.
The idea of the CONNECT is that it would have the bare minimum to route. Then the full blown end-to-end secure INVITE (with the SDP) could be exchanged. > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 15:52 > To: Elwell, John > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF SIP > List; Dean Willis > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > > 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
