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