Subject: RE: [SIP] Cancel of Invite and affect (if any) on prack and reli ableprovisionalresponses

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 23:10:55 -0500

> -----Original Message-----
> From: Doug Hurtig [mailto:[email-masked]]
> Sent: Thursday, February 15, 2001 5:41 PM
> To: Christer Holmberg
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] Cancel of Invite and affect (if any) on prack and
> reliableprovisionalresponses
> 
> 
> Christer,
> 
>   Thanks for the response.
> 
> 
> Christer Holmberg wrote:
> 
> > Hi,
> >
> > >Hi,
> > >
> > >I have a question related to what should the UAC and UAS do with
> > >outstanding PRACK requests and reliable provisional 
> responses when the
> > >associated INVITE is canceled?
> > >
> > >     UAC                               UAS
> > >
> > >     INVITE -------------------------->
> > >
> > >            <-------------------------- 100 provisional response
> > >            <-------------------------- 18x reliable provisional
> > > response
> > >
> > >     PRACK  ------------> lost
> > >
> > >     CANCEL -------------------------->
> > >
> > >
> > >At this point the UAC is waiting the 200 OK for CANCEL and will
> > >resend PRACK on time-out. UAS is awaiting PRACK for 18x 
> and will resend
> > 18x
> > >on time-out.
> > >
> > >Should UAC abort the PRACK or let it continue?
> >
> > I see no reason why you would keep the PRACK alive, since you have
> > canceled your setup request. The problem is that if you 
> simply kill your
> > transaction the UAS is going to re-transmit the 18x response until
> > timeout. One answer would be to also CANCEL to PRACK, but that is
> > related to the issue about if CANCEL is allowed for other 
> requests than
> > INVITE...
> 
>   I agree with you. However, the 100Rel draft states that CANCEL of
>   PRACK is not valid.

The UAC should absolutely NOT abort the PRACK.

Fundamental theorem of SIP: each transaction completes independently.
Otherwise, you have all these proxy servers in the middle which all of a
sudden need to be call state aware to cleanup state. Very bad. 

So, the INVITE is cancelled. The 487 is sent. The PRACK is retransmitted
like any other non-INVITE until a final response is received. Of course,
this means that the UAS should still be prepared to complete the PRACK
transaction, sending a final response (200 OK) upon receipt.

> 
> >
> >
> > Also, you have a similar case if you receive the final 
> respones to your
> > INVITE while you still have ongoing PRACK transactions. Why 
> would you
> > then want to keep the PRACK transactions alive, since you (the UAC)
> > KNOWS you have received the provisional responses 
> (otherwise you would
> > never have started the PRACK transaction), and you already 
> have received
> > the final response? I think that CANCEL should be used here.
> >

No.

You cannot CANCEL PRACK. It doesn't make sense, since PRACK will be
responded to immediately when received.

When the UAS sends the final response, it can cease retransmitting any
provisionals (although, if they were so important as to be sent reliably, do
you really want to do that?), but has to allow the PRACK transactions in
progress to complete. 

> 
> >
> > Also (I have a number of issues on PRACK :),

Well, last call on this document occurred eons ago, and it has been in IESG
last call for some time. Just when did you plan on posting your issues?

 what should 
> the UAS do, if
> > it get triggered to send a final response to the INVITE it 
> received, but
> > it is still sending 18x provisional responses it hasn't 
> received a PRACK
> > for? Maybe this is more an implementation issue, but I 
> wanted to point
> > it out.
> 
>    Given the way the 100rel draft is currently written I 
> suspect that you
>   need to allow the PRACKs to continue.

Yes.

> 
>    The 100rel draft does recommend that the UAS not send the 
> next provisional
>    response until it the previous one is acknowledged.  If 
> this is the case, then
>    you could drop unsent provisional responses at the UAS if 
> it was determined
>   that a final response was to be sent. This works if media 
> is sent in first
>   provisional response or in the final response. If however, 
> media could be
>   in one of the dropped provisional responses you could have 
> a problem.

Err, no.

The UAS is sending a final response here. Final responses, 200 class ones in
particular, carry the complete media state in them. Therefore, this is
everything the UAC will need to know in order to set up a media channel.

> 
> >
> >
> > >UAS must send the 200 OK for the CANCEL and should send a 487
> > >response for the INVITE. Should the UAS abort the timer 
> associated with
> > any
> > >active 18x response? That is, stop waiting for the PRACK.

If the UAS doesn't care that these are received reliably, it can cease
retransmitting them. However, the PRACK transactions initiated by the UAC
must complete.

> >
> > This is also an issue. It is related to what I just wrote, but the
> > difference is that now the UAS hasn't received a CANCEL, but it has
> > still sent the final response to the INVITE.
> >
> > My personal opinion about PRACK is that it is a little 
> weird to spend
> > more resources to ack provisional responses, (PRACK request 
> + response)
> > than to ack the final response (only an ACK request), but I 
> guess that
> > is not related to your question, so... :)

Well, the alternative is to mandate that PRACK carry a Proxy-Require, since
all unknown methods generate responses. That, to me, is a complete failure
of interoperability. Thats why PRACK generates a response, so that it can
work through proxies that don't care about reliable provisional responses.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Mar 2001 10:35:37 +0200

Hi,

>>>simply kill your transaction the UAS is going to re-transmit the 18x response until
>>>related to the issue about if CANCEL is allowed for other requests than
>>>INVITE...

Ok.

>>Also, you have a similar case if you receive the final respones to your
>>would you then want to keep the PRACK transactions alive, since you (the UAC)
>>KNOWS you have received the provisional responses (otherwise you would
>>have received the final response? I think that CANCEL should be used here.
>No.

Ok again.
 
>responded to immediately when received.

Yes, I know. The issue was that the PRACK, or its response, may for some
reason get lost in the network, and the UAC may receive the final
response when it is still re-transmitting the PRACK.
 
>When the UAS sends the final response, it can cease retransmitting any provisionals 

Ok.

>(although, if they were so important as to be sent reliably, do you really want to do that?),

I guess this again depends on the node. For example, in a PSTN gateway
case it IS important that they are sent received BEFORE the CON (ie the
final response) is received. However, since the UAC GW doesn't ack ISUP
messages received from the PSTN network it will receive CON no matter if
the provisional responses reached the destination GW or not. And, AFTER
the final response is received it is NOT anymore important that the
provisional responses are received reliably, even if they were sent
before the final response, which was the reason to the proposal to be
able to CANCEL any pending PRACKs.

>but has to allow the PRACK transactions in progress to complete.

>last call for some time. Just when did you plan on posting your issues?

I think this mail points on most of them, and in most cases it is simply
about clarifying things. And, I do not think we should re-write
everything, and I do agree that the handling of transaction should be
general (even if it MAY not be the best solution in this case). The
important thing is that we got these special scenararios clarified. 
 
>>>what should the UAS do, if it get triggered to send a final response to the INVITE it
>>>received, but it is still sending 18x provisional responses it hasn't
>>>received a PRACK for? Maybe this is more an implementation issue, but I
>>>wanted to point it out.
>>suspect that you need to allow the PRACKs to continue.
>Yes.

Agreed.
 
>>next provisional response until it the previous one is acknowledged.  If
>>this is the case, then you could drop unsent provisional responses at the UAS if
>>it was determined that a final response was to be sent. This works if media
>>is sent in first provisional response or in the final response. If however,
>>media could be in one of the dropped provisional responses you could have
>>a problem.
>Err, no.

This is another issue, which I guess may be an implementation issue.
Let's assume that the UAS for some reason generates a big number of
provisional responses, which all have to be PRACKed. Now, if they are
generated faster than they are PRACKed we will have to do buffering.
Then, the UAS may generate the final response, so the question is: what
shall we do with all the provisional responses which still are in the
buffer? If they are not important, I guess the UAS can simply delete
them and send the final response. 

Another option is to send the remaining provisional responses
unreliably, and then send the final response. However, this will raise
issues if the UAC Required that all provisional responses must be sent
reliably...

>>>>associated with any active 18x response? That is, stop waiting for the PRACK.
> 
>>>weird to spend more resources to ack provisional responses, (PRACK request
>>>+ response) than to ack the final response (only an ACK request), but I
>>>guess that is not related to your question, so... :)
> 

I know why the response are needed. My point was just that I personally
think it's a little weird from a functional point of view.

A question:

Chapter 5.1 says:

"The Route header that is constructed from some provisional response
MUST NOT be placed in any other request except for the PRACK for that
specific provisional response".

Now, I HATE to raise the overlap dialing issue again, but this will
affect the routing stuff we spent a lot of mails discussing... We did
discuss the issue that it should be allowed to use the Route header from
a provisional response in re-INVITEs (ie. not only in PRACKs)...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Doug Hurtig <[email-masked]>
Date: Tue, 06 Mar 2001 09:02:04 -0600

Hi,

Christer Holmberg wrote:

> provisionals

I do agree that these special scenarios should be documented.  Might add
scenarios with reliable responses to the SIP Call Flows Example document.

> issues if the UAC Required that all provisional responses must be sent

 It will be up to the UAS to decide if it should send the "buffered" responses
 when the final response is generated. Of, course would need to handle
 any received PRACKs even if it canceled the sending of the buffered response.

> a provisional response in re-INVITEs (ie. not only in PRACKs)...

   Regarding the Route header in the PRACK. It is my understanding
   that this Route header is constructed from the response and used
   only in the PRACK and not in future re-Invites. Is this correct?

> (See attached file: christer.holmberg.vcf)

Thanks for the help!

--
Regards,
Doug Hurtig

Tekelec
2425 N. Central Expressway
Richardson, Texas 75080

[email-masked]
972.301.1203

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 07 Mar 2001 13:26:06 +0200

Hi,

>    only in the PRACK and not in future re-Invites. Is this correct?

This is what the PRACK draft says - and this is the problem. 

However, I think that we have agreed that Route headers ARE allowed in
the initial INVITE, so I don't think it matters if those Route headers
come from a provisional response, from a final response, or from the UA
configuration file...

I am not sure the text belongs in the PRACK draft anyway, becuase it's
general SIP. The only thing related to PRACK is that the Route in the
provisional response should/must be used in the PRACK.

Regards,

Christer Holmberg
Ericsson Finland