Subject: [Sip] reINVITE

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 04 Nov 2004 05:04:27 -0800

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

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 4 Nov 2004 09:05:10 -0500

> So this mean that the server should 
> be prepared to receive the next 

It should be prepared; however the re-INVITE can be rejected.  One of the
reasons could be associated with the need of an SDP within the ACK.  Other
reasons could be associated service interactions or product limitations
concerning race conditions.  Thus the uac should be prepared to receive 500
response with a retry-after.