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
