Christer Holmberg (JO/LMF) wrote:
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?
whatever you call it, there is still a difference between trying things
serially and trying them in parallel. If the UA gets a 3xx with one
contact and recurses on it then you have serial forking. If the UA gets
a 3xx with multiple contacts and tries them one by one you still have
serial forking. If the UA gets a 3xx with multiple contacts and tries
them all at once then you have parallel forking.
Paul
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
