Dale Worley wrote:
On Fri, 2009-02-13 at 16:27 -0600, Vijay K. Gurbani wrote:
Pedantically speaking, it should be "0 or 1 final response".
Under what condition would you get more than 1 final response
for the same transaction from a downstream forking proxy?
If a call was parallel-forked to two UAs and both were answered at the
same instant, both UAs would send 200s upstream, and they would both
reach the UAC.
If a request was sent with "Request-Disposition: no-cancel", then we
expect to routinely receive multiple success responses. And for
SUBSCRIBEs, a strong argument can be made that no-cancel should be the
default mode of processing -- we've considered doing so in sipX.
Ah, OK -- you are talking about intermediaries implementing
rfc3841.
For SIP CLF, I am working with the base model of rfc3261 processing
in place where receiving multiple final responses is prohibited
from happening (unless a UAC forks off multiple requests itself
and is prepared to deal with the consequences.)
At this point, I am not sure what to do with rfc3841. This
certainly adds a level of complexity -- not as much to the
production of SIP CLF, but rather to the training of various
automata.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
