Subject: [Sipping] Re: draft-worley-sipping-forking-02.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Feb 2007 16:28:55 -0500

Dale,

Interesting proposal. I see a few issues that may or may not be resolvable:

A big one is the possibility of multiple failure responses. After 
sending such a request, when does one give up? This is already an issue 
for INVITE, but only after receiving a 2xx. And in that case you are 
probably keeping some state around for the session anyway. This would 
require some significant reworking of the transaction state machines.

Another issue is that this requires (I think) the UAC to alter its 
behavior when no-cancel is in effect. But 3841 permits a proxy to add 
the Request-Disposition header. If it does, the UAC won't know about it.

I think there may be some other things, but these are the big ones that 
leap out at me.

Note that the origins of callerprefs are ancient - before I became 
involved. And in all the time I was involved I don't recall the 
Request-Disposition header ever being discussed at all. It is clearly 
underspecified and perhaps just plain broken. It might be worth taking a 
survey to see if anyone has implemented it. Making some incompatible 
changes to fix it might be quite acceptable.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Wed, 14 Feb 2007 13:43:51 -0500

From: Paul Kyzivat <[email-masked]>

   A big one is the possibility of multiple failure responses. After 
   sending such a request, when does one give up?

I assume you mean, "When does a UAC give up waiting for further
responses?"

In the cases I'm thinking of, the UAC is trying to accumulate a set of
responses, and expects that they will dribble in over time.  The
cannonical case is SUBSCRIBEs to obtain some sort of status info.  In
the call pick-up case, the agent trying to perform the pick-up has to
have such a time-out already, the point at which it decides what to
do.  In cases involving ongoing status monitoring, the information
from an additional subscription can be added to the information
already accumulated.

   This is already an issue for INVITE, but only after receiving a
   2xx. And in that case you are probably keeping some state around
   for the session anyway. This would require some significant
   reworking of the transaction state machines.

In the simplest implementation, the UAC can pick the first one, and
ignore the latter ones.  But if the UAC doesn't want to handle
multiple responses, it shouldn't ask for them.

I think that in various cases without Request-Disposition, the UAC can
be confronted with multiple responses anyway.  Mostly cases involving
stateless proxies or alternative routing of responses due to failure
of intermediate agents during the transaction.  But isn't ignoring all
latter responses an adequate solution?

Dale