Subject: [Sip] Stuck in Proceeding after Cancel

From: "Hearty, John" <[email-masked]>
Date: Thu, 26 Jun 2003 12:47:09 -0600

We have come across what may be a bug in RFC 3261.  The following bug is
closely related, but it is not clear to me it is the same.

http://bugs.sipit.net/sipwg/show_bug.cgi?id=706

The issue involves the Invite client transaction state machine.  As the
above bug describes, there is no timer to exit the Proceeding state.
This is normally fine, as it is an application decision when give up.

However, when the application does give up and sends a Cancel, we still
rely on the UAS to return the forced 487 to properly exit the Proceeding
state.  If the 487 (or any final response) is never returned for
whatever reason, we remain stuck in Proceeding.

I am not clear if there should be a timer specified in the spec to allow
exit from this state in this particular scenario, or if this should also
be considered an application layer problem and covered under the
existing bug.

John Hearty
Level3

_______________________________________________
Sip mailing list  https://www1.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: "Hearty, John" <[email-masked]>
Date: Fri, 27 Jun 2003 12:44:50 -0600

Jonathan,

 I found the following text that covers this scenario, so it may not be
considered a bug.  I don't particularly like the idea of an unnamed
timer though, and the below text could be a bit more explicit about when
to start the unnamed timer (upon sending Cancel).  I would appreciate
this scenario being added to the existing bugzilla bug so it is also
included in some future clarification of the Invite client transaction
section.

   Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is

Rosenberg, et. al.          Standards Track                    [Page 54]

RFC 3261            SIP: Session Initiation Protocol           June 2002

   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request.

John Hearty
Level3

> -----Original Message-----
> From: Hearty, John
> Sent: Thursday, June 26, 2003 12:47 PM
> To: [email-masked]
> Subject: [Sip] Stuck in Proceeding after Cancel
>

---

From: "Hearty, John" <[email-masked]>
Date: Mon, 30 Jun 2003 09:13:55 -0600

From the duration, it sounds like timer B, though I didn't want to
presume anything.  However, the text is not clear when said timer gets
set.  Also, if it actually is timer B which is set when the original
request is sent, it could be stopped or ignored (exact action regarding
the timer is not specified) once a provisional response is received.
The below text appears to suggest said timer continues to run in this
specific scenario.

This just seems like another of the countless clarifications that the
evolving specification may need.  If I had to make the clarification, it
would be to reset timer B for the Invite Client Transaction upon sending
a Cancel for that Invite.  That would fix it, and provide an equal time
for a 487 response that a provisional response or other non-2xx final
response had.  I think 487 is a special case compared to other non-2xx
final responses.

John Hearty
Level3

> From: Christer Holmberg (JO/LMF)
[mailto:[email-masked]]
> Sent: Sunday, June 29, 2003 11:55 PM
> To: Hearty, John; [email-masked]; Jonathan Rosenberg
> Subject: RE: [Sip] Stuck in Proceeding after Cancel
> 
> 
> Hi,
> 
> Isn't the timer you are talking about timer B? I agree that it would
be
> more clear to write "timer B" instead of "64*T1 seconds".
> 
> I also think it is important to remember that timer B may expire AFTER
> CANCEL has been sent, but BEFORE 487 has been received, and since the
> transaction will be terminated there is no guarantee an ACK will be
sent
> when 487 eventually arrives. But, I guess this is similar to any case
> where the final response is sent too late by the UAS...?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> > > We have come across what may be a bug in RFC 3261.  The
> > following bug
> > is
> > > The issue involves the Invite client transaction state machine.
As
> > the
> > > exit from this state in this particular scenario, or if this
should
> > also