The value (from an end-user perspective) is "Simultaneous or Parallel Ringing".
At the technical level it is implementable either using proxy forking, or with UA recursion. > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 13:49 > To: Audet, Francois (SC100:3055); Vijay K. Gurbani > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > > Hi, > > >I call it UA forking (as opposed to proxy forking). > > I don't think 3261 calls it UA forking. > > When triggering requests based on a 3xx response, I think > 3261 talks about "recursion". > > Regards, > > Christer > > > > > > > >I'm ok with calling it something else. > > > >I have a funny feeling that if we had made the distinction > clearer way > >back when we were discussing the merits of forking, we would > have had a > >different outcome. > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 19, 2007 12:57 > > > To: Vijay K. Gurbani; Audet, Francois (SC100:3055) > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > > > > > > > > Hi, > > > > > > A small comment. > > > > > > I don't think we in the draft should say that the UA forks. > > > Because, I don't think the UA behavior is different from when it > > > receives a 3xx response for e.g. an initial INVITE, is it? > > > It uses the contact in the response to initiates new > > initial request. > > > We don't call that forking, do we? > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > > From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] > > > > Sent: 19. kesäkuuta 2007 19:35 > > > > To: Francois Audet > > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ 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
