I call it UA forking (as opposed to proxy forking).

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

Reply via email to