Subject: [Sip] Some thoughts about CANCEL for specific legs, together with SIP extensions

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jun 2001 11:30:27 +0300

Hi,

Some thoughts/issues came to my mind when I read the thread (the SIP
implementors list) about using CANCEL for specific call-legs.

I KNOW we have spent lots of time discussing this, but I am not pretty
sure that we have really thought about all the scenarios when some of
the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
PRACK- and pre-call-setup requests features, and the scenario where the
UAC wants to choose specific call-legs for a call). 

Instead, I think we mostly have assumed that a call setup is simply an
INVITE, possible provisonal responses, and one or many final responses
plus their ACKs, and in those cases I don't think we have any major
problems.

I even think some of the extensions may LOOSE some of the good stuff
they are supposed to provide due to these issues.

Issue 1: Caller preferences

The Caller preferences feature allow the UAS to indicate the feature
parameter in the response. The draft mentions the 200 response, but I
guess it is (at least it should be) allowed also in a provisional
response with a To-tag and Contact header. So, now the UAC may at a very
early stage of the call setup find out about what kind of servers it has
received provisional responses from, which means it may at a very early
stage find out that it does not want a specific call-leg (for example,
one could receive provisional responses from two different answering
machinges, or something...). However, the UAC is not able to cancel any
call leg (without terminating the whole call setup) before it has
received a final response from one UAS, which means it may have to
handle PRACKs, INFOs, and who knows what, with all servers - also those
it will never establish a call with. A solution to this could be to
allow CANCEL for a specific leg (assuming that the provisional responses
included a To-tag and Contact). If PRACKs (or other requests used before
the call is setup) are involved, the provisinal responses most likely
will include the tag and Contact, so...

Issue 2: Multi-leg call

This could be related to the previous issue, but it can also be a "stand
alone" issue. Again, a UAC may receive multiple provisional responses.
It is going to establish a multi-leg call, ie it is going to accept a
specific set of final responses. Again, however, it receives provisonal
responses also from other servers, but again - it is not able to cancel
those legs before it has received the final responses for ALL parties
that will be in the multi-leg call. Allowing CANCEL for a specific leg
would help also here.

What also may happen here, is that we receive a final response for a leg
that we do NOT want in the call, but we still want to wait for another
final response. Now we could simply ACK and BYE that leg, but then we
come to the issue about sending BYE requests before the whole call has
been setup. However, the bis DOES say that BYE is used to terminate an
established call-leg, and that is what we would be doing here - no
matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
says "To terminate a call instead of just pending searches, the UAC must
use BYE instead of or in addition to CANCEL". So, I guess some
clarifications in the bis may be needed here.

Conclusion:

So, I don't know if we are talking about changes, or simple
clarifications, in the spec, but the issues are:

1. Should we allow CANCEL for a specific call-leg, IF we have received a
To-tag and Contact in the provisional response?

2. Should we allow BYE for an established call-leg, even if the whole
call is yet not setup (the UAC is waiting for another final response)?

I know that we have the issue about a UAS receiving the same request
from different locations (when the request has been forked), so we have
to find out in which scenarios this can be a problem, and how likely it
is that those scenarios will take place.

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jun 2001 12:52:45 +0300

Hi,

Some clarificatons to my previous mail.

>clarifications in the bis may be needed here.

First, since multi-leg calls, ie conferences, are handled in a different
way I guess that can be dropped from this issue. 

Also, when I talked about not accepting the first 200, I did not only
mean clients, but also a forking proxies (and, since it has been said
that proxies SHOULD cancel all the other legs when the first 200 is
received, it SHOULD not even be an issue for a client). However, the
issue is if the proxy should be able NOT to accept and forward the first
200, since it has received provisonal responses also from another UAS
that it wants to be in the call.
 
> call is yet not setup (the UAC is waiting for another final response)?

Again, the second issue is only valid for forking proxies, IF they
cancel all other legs when the first 200 is received.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 26 Jun 2001 09:53:45 -0400

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 26, 2001 5:52 AM
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, together
with SIPextensions

> > To-tag and Contact in the provisional response?

I personally like the idea.

> > call is yet not setup (the UAC is waiting for another final response)?

If by "established call-leg", you mean one that has received a 2xx response,
sending BYE is just for that leg is just fine.

Section 6 of bis-03 says we SHOULD NOT send a BYE to terminate a request
that has not recieved either a final or provisional response. Does that mean
we can send BYE if we have received a provisional response? A UAS is suppose
to cancel a call-leg that it has not generated a final response for if it
gets a BYE. Is it legal (and desireable) to terminate a provisional call-leg
with BYE?

> cancel all other legs when the first 200 is received.

If a provisional response had reached the UAC shouldn't that UAC still get a
487 response when the proxy cancels the call leg? Or would that only happen
if the provisional response is PRACK'd?

> > is that those scenarios will take place.

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 26 Jun 2001 10:34:49 -0400

Christer,

Could you clarify whether the multi-leg call is due to forking?  It is not 
clear why you invited the call-leg to begin with, then later wanted to cancel.

Issue 2 seems to be tied up in the meaning of call versus call-leg, where 
the existing rules about sessions apply to a call-leg, but are termed a 
call.  If each leg in the call is requested by different session 
transactions then the sequences of setup and release could progress 
independently.

Is there some nuance missing?

Mike

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jun 2001 08:01:04 +0300

Hi Michael,

Thanks for your comments.

>clear why you invited the call-leg to begin with, then later wanted to cancel.

It is due to forking.
 
>transactions then the sequences of setup and release could progress

From a UAC point of view it is the same transaction, because it sends a
single INVITE. However, the proxy then forks it, and it may receive
multiple final responses (including multiple 200 OK).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jun 2001 08:13:33 +0300

Hi Bob,

>I personally like the idea.

I think it can be useful also in other areas, for example when we talk
about EARLY MEDIA and media address/port verification. For example, if
the UAC receives multiple 18x, with multiple different session
descriptions, it can choose which leg to use and cancel the others - and
the good thing is that all this can be done before the call is
established.
 
Another scenario is when we send pre-call INFOs. If we have received
multiple provisonal responses, representing different call-legs, the UAC
may not know to which server it should send the INFOs, or if it has to
send the INFO to all servers, OR if the INFOs should be sent like the
original INVITE (and currently also like CANCEL), ie without any tags,
routes and other leg information. This problem was also mentioned in a
mail by Jonathan a few days ago, I think.

>gets a BYE. Is it legal (and desireable) to terminate a provisional call-leg

This has been discussed alot, and the decission was that it IS allowed.
However, I guess that we still have the same issue that we have with
CANCEL: are we allowed to BYE a specific call-leg before we have
received a final response for that leg, or is the BYE supposed to
terminate all call-leg setups?

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland