Francois Audet wrote:
Right; agree. Forking is problematic. One way is to force
the issue with rfc3841's Request-Disposition header. But
that header elicits a normative strength of SHOULD in the
proxies, thereby lending it an advisory mode only. Another
way is to discourage forking for CONNECT in the draft, but
allow for it to occur and simply accept the first 200 OK,
closing the connection on subsequent ones. Clearly something
that needs to be worked out in the draft going forward.
Maybe we can just do the 3XX with multiple contacts?
(i.e., UAC-based forking)?
Yes, that is a third option; although, I would be curious to
see how many user agents fork (proxies of course need to).
Most user agents that I have used happily leave the complexity
of forking to their nearest friendly proxy.
Thanks.
- 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
