Subject: RE: [Sip] Stuck in Proceeding after Cancel

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 30 Jun 2003 07:55:04 +0200

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

>  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
> > 
> > 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 1 Jul 2003 07:20:54 +0200

Hi John,

>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.

Correct. However, I can't find any text saying that, and the bug description in bugzilla says it's pretty much an implementation issue. 

However, is it even said somewhere that/if/how timer B will be stopped when we receive a FINAL response, and go to the completed state? At that point we DO start timer D, but if we haven't stopped timer B it will most likely expire before timer D, so there would be no need for timer D in the first place, would there?

>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.

I agree. Reset it, or not touch it at all, but certainly not stop it.

>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.

Also, I wonder if it would be a good idea to also reset timer B when we get a provisional response, if we use PRACK, to equal time for the INVITE final response and PRACK final response.

Regards,

Christer Holmberg
Ericsson Finland

> > 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
> > 
> > 
> > 
> > >    and the CANCEL transaction will complete 
> independently.  However,
> a