Subject: [Sip] Fw: [Sip-implementors] Miss-ordered re-INVITE request

From: P Thejeswara Reddy <[email-masked]>
Date: Tue, 23 May 2006 15:15:51 +0530

Hi,
What is the response code in the following scenario.

UA-1                   UA-2
------INVITE --------->
<------200 ------------
------- ACK ----------->
------ re-INVITE-1----->
<------200 ------------
--------Ack lost--
------ re-INVITE-2----->
<------ Response code?? ----

Thanks
Thejeswara Reddy

----- Forwarded by P Thejeswara Reddy/BLR/HSS on 05/23/2006 03:11 PM -----

"Gupta, Ajay" <[email-masked]> 
Sent by: [email-masked]
05/23/2006 07:32 AM

To
"Leonid Fainshtein" <[email-masked]>, <[email-masked]>
cc

Subject
Re: [Sip-implementors] Miss-ordered re-INVITE request

The UA-2 should send a 491 response for the re-INVITE-2 with a
Retry-After header. It is true that the 491 response will not result in
the ACK generation for re-INVITE-1 but at the same time the UA-2 should
also retransmit the 200 response for the re-INVITE-1 which will result
in the ACK from UA-1

Ajay

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Leonid
Fainshtein
Sent: Saturday, May 20, 2006 3:24 PM
To: [email-masked]
Subject: [Sip-implementors] Miss-ordered re-INVITE request

Hi,

Is the following UAS behavior correct?

UA-1                   UA-2
------INVITE --------->
<------200 ------------
------- ACK ---------->
------ re-INVITE-1----->
<------200 ------------

------ re-INVITE-2----->
<------ 400( with Retry-After header) ----

As you can see, the second re-INVITE arrives to the UAS when the
previous re-INVITE transaction is not confirmed yet (ACK is not
received).
What should UAS do in this situation? Silently ignore re-INVITE2? Reject
it with response 400 or 500?
Thanks,
Leonid

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

***********************  FSS-Private   ***********************

_______________________________________________
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: Thomas Froment <[email-masked]>
Date: Tue, 23 May 2006 12:35:06 +0200

I think the answer is 491 "request pending":
see section 14.2 of RFC 3261:
"A UAS that receives an INVITE on a dialog while an INVITE it had sent  
on that dialog is in progress MUST return a 491 (Request Pending)"

Thomas

P Thejeswara Reddy wrote:

> *"Gupta, Ajay" <[email-masked]>*
>------------------------------------------------------------------------
>

---

From: Thomas Froment <[email-masked]>
Date: Tue, 23 May 2006 13:28:51 +0200

sorry, I realized this is probably not the right answer...
This case is actually not described, 491 is for the case where UAS has 
sent an INVITE on its side...

I found the following thread in archives:

http://www1.ietf.org/mail-archive/web/sip/current/msg12768.html

In Section 14.2 UAS Behavior of RFC 3261, it says:
   If a UAS generates a 2xx response and never receives an ACK, it
   SHOULD generate a BYE to terminate the dialog.

That is, the UAS SHOULD terminate the dialog. But because the misorder
of the SIP messages, sometimes the UAS SHOULD NOT terminate the dialog
as I considered.

The UAS can have several choices to handle in this case:
1. Terminate the dialog as the specification. This is not reasonable in
some cases and it is not a good idea.
2. UAS can accept the re-INVITE and wait for ACK. It can handle the
re-INVITE before the ACK comes or after ACK comes. If before ACK, the
case will becomes more complicated if maybe the ACK will take SDP answer
back. But if after ACK comes, it must buffer it. This is not a good
idea, I think.
3. UAS can ignore the re-INVITE because UAC will re-transmit again. UAS
can accept it after ACK comes simply.
4. As Section 14.2 of RFC3261:
   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.
UAS can reject the re-INVITE temporarily by 491 and UAC side will
initiate another try several seconds later.

[email-masked] wrote:

> "A UAS that receives an INVITE on a dialog while an INVITE it had 
> sent  on that dialog is in progress MUST return a 491 (Request Pending)"
>
> Thomas
>