RE: [Sip] Re-Invite before ACK

I consider that ACK to INVITE’s 200 OK is a individual transaction, but it must send rapidly after receive

200 OK, otherwise it is no significance to acknowledge the INVITE transaction. Even ACK send before the

re-INVITE, for the reason of network delay, UAS may receive ACK after re-INVITE.

Deal with this scenario may be an implementation or client policy.

Xiao

-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Manish Joshi
Sent: Thursday, January 19, 2006 3:42 AM
To: James M. Polk; Miloslavsky Evgeny; sip at ietf.org
Subject: Re: [Sip] Re-Invite before ACK

Iniline..

"James M. Polk" <jmpolk at cisco.com> wrote:

At 10:45 AM 1/18/2006 -0800, Manish Joshi wrote:
>Hi,
>
>The spec seems doesnt seem to be very clear on this.
>An ACK to first Invite is a new transaction as the Invite transaction
>completed as soon as UAS sends final response as 200OK. UAC is now free to
>send a new re-invite along with the ACK to the first Invite.

>>I don't believe so. I believe the stated behavior of the UAC is that it
>>cannot send a new INVITE within a dialog until the ACK is sent. The UAC >>is free to send any new INVITE outside of an existing dialog though. >>Section 14.1 covers this I believe.

Actually I think 14.1 supports more what I mentioned above:

Quote:

"   Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.

      1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE."

UNQUOTE

ACK is a new transaction and receiving a final response (200OK) actually completes the INVITE transaction and hence UAC is free to Initiate a new (re)Invite transaction.

>Now since the packet ordering is not _ensured_, a reinvite can always come
>to UAS before ACK and hence UAS should be able to accept it.

>>Section 14.2 faintly implies a 491 is appropriate for the reINVITE in this
>>situation (prior to receiving the ACK to the original INVITE/200 OK exchange)

>
>BTW, this might also be an implementation option, where you chose to
>Ignore the re-invite in case the first INVITE did not have an offer and
>200 OK was the one with the offer and ACK will contain the media-answer.
>
>My two cents.
>-Manish
>
>Miloslavsky Evgeny wrote:
>Yahoo! Photos – Showcase holiday pictures in hardcover
>Photo
>Books. You design it and we’ll bind it!
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors at cs.columbia.edu for questions on current sip
>Use sipping at ietf.org for new developments on the application of sip
>

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.