Subject: RE: [Sip] reINVITE

From: "Gordon Ledgard" <[email-masked]>
Date: Thu, 4 Nov 2004 09:14:02 -0500

Perhaps someone will chime in and correct me if I'm wrong. I believe
I ran into the same issue a while back, concluding that if another
INVITE were accepted before the ACK to the previous invite arrived
it could cause rather serious instability problems in session 
negotiations, not to mention trying to align ACKS.

The answer is that you should not accept a new INVITE until the previous
INVITE transaction is complete. Complete means the ACK was seen. I
agree the spec is a bit vague there.

Gordon R. Ledgard
IPeria, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Marc Petit-Huguenin
Sent: Thursday, November 04, 2004 8:04 AM
To: [email-masked]
Subject: [Sip] reINVITE

I already asked this in sip-implementors, but I didn't received any 
conclusive answer.

RFC3261 is not clear about when an UAS must be ready to receive a new 
reINVITE in a dialog.

My reading of the RFC is that the UAS must be ready to receive a new INVITE 
in a dialog as soon a response was sent for the previous INVITE. More 
precisely, that the UAS must not wait for the ACK before accepting the next 
INVITE. Accepting in this case means that the INVITE is passed to the 
application - the INVITE can be rejected by the application because of the 
content of the SDP, but not because of a violation of the signalling protocol.

My reasoning is based on the fact that RFC3261 section 14.1 says that "If 
there is an outgoing INVITE client transaction, the TU must wait until the 
transaction reaches the completed or terminated state before initiating the 
new INVITE." As an INVITE transaction reaches the completed or terminated 
state as soon a non-provisional response is received, the next INVITE can 
be sent at the same time the ACK for the 200 response is sent. As the 
packet ordering can change, the INVITE can arrive at the UAS before the 
ACK. So this mean that the server should be prepared to receive the next 
INVITE before receiving the ACK.

Is it correct?

Please note that my question is not about how SIP implementations work in 
this case, but really on what was RFC3261's authors intent.

Thank you.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

_______________________________________________
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: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 04 Nov 2004 16:04:18 -0800

As the offer/answer cannot overlap, there is 4 different cases:

1.

UAC             UAS
  --INVITE offer->
  <---200 answer--
  --ACK---------->
  --INVITE------->
  <----200 offer--
  --ACK answer--->

2.

UAC             UAS
  --INVITE offer->
  <---200 answer--
  --ACK---------->
  --INVITE offer->
  <---200 answer--
  --ACK---------->

3.

UAC             UAS
  --INVITE------->
  <----200 offer--
  --ACK answer--->
  --INVITE------->
  <----200 offer--
  --ACK answer--->

4.

UAC             UAS
  --INVITE------->
  <----200 offer--
  --ACK answer--->
  --INVITE offer->
  <---200 answer--
  --ACK---------->

The only problem here is the fourth case, because the INVITE offer can
arrive before the previous answer.

Gordon Ledgard wrote:
> INVITE transaction is complete. Complete means the ACK was seen. 

No, the ACK for the 2xx is not part of the INVITE transaction. The 
transaction is complete as soon the 2xx is sent. See Figure 7 in RFC3261.

> I