Subject: [Sip] Re: Re-Invite before ACK

From: srinidhi n <[email-masked]>
Date: Fri, 20 Jan 2006 09:18:45 -0800 (PST)

Do Correct me if I am wrong.

1. I think unless an ACK is receved by the UAS, its
transaction will not be complete and the UAS will
continue to re-transmit the original 200 OK. 

2. As per sec.13 of RFC 3261, 
  If the server retransmits the 2xx response for 64*T1
seconds without receiving an ACK, the dialog is
confirmed, but the session SHOULD be terminated.  This
is accomplished with a BYE, as described in Section15.

In this case, it is really difficult from the UAS
perspective to predict if it will receive a "ACK"
after the "Re-Invite" although its more likely to
receive it.

Hence, the UAS may chose to send 491 response. 

-Srinidhi

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
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: Xiao Wang <[email-masked]>
Date: Sat, 21 Jan 2006 10:59:22 +0800

inline

Xiao

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> srinidhi n
> Sent: Saturday, January 21, 2006 1:19 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] Re: Re-Invite before ACK
> 
good
> is accomplished with a BYE, as described in Section15.
Note " but the session SHOULD be terminated ",there use " SHOULD" not
"MUST".
That is the protocol allow other cases to the session isn't terminated.
I think if ACK is used to acknowledge that UAC received 200 OK and not
taking SDP, the session may not be terminated if the timer fired and UAS
received re-INVITE.
Why may UAC send re-INVITE after send ACK?
Because the protocol doesn't forbid. If the protocol explicit set a rule
that UAC MUST wait 64*T1 after received the first 200 OK before send
re-INVITE, this will not be flexible. 
In many cases, UAC need rapidly to send re-INVITE to UAS for exchange new
SDP after old INVITE transaction complete.
Another cases, the value of T1 set in UAC may not equal to UAS's, therefore,
UAC don't know wait how long.
Alternatively, if UAS receive re-INVITE before ACK that means to UAC already
received 200 OK of old INVITE, and UAS must deal with the re-INVITE and not
simple to return 491 or else failure response.

---

From: srinidhi n <[email-masked]>
Date: Sun, 22 Jan 2006 09:08:03 -0800 (PST)

1. In case an SDP ofer was not made in the original
Invite,
there is no way we can honour this Reinvite before an
ACK and the session must be terminated. On the other
side, if a offer was made  in the Invite, the reinvite
either could be accepted/rejected(as being discussed).

Thus, the UAS needs to  exhibit a different behavior
in cases where an offer was made in Invite and when it
wasn't. This apart from cancelling the re-transmission
of 200 OK on recepton of ACK and also reinvites.

2. 64*T1 is the worst case time period before which a
ACK is to reach the UAS. For every T1 and doubling
thereafter till T2, the UAS retransmits a 200 OK.
Hence, the UAC can safely transmit the next message
from ACK after 2*T1, provided a 200 Ok is not
retransmitted, without worrying about any kind of UAS
problems.

3.Another problem from UAC side would be how it would
handle a retransmitted 200 OK(assuming the ACK is
lost) after initating a Re-Invite.

Considering UAS behavior differences it would be
easier to not to handle the reinvite at the UAS.

-Srinidhi
--- Xiao Wang <[email-masked]> wrote:

> > From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> > srinidhi n
> > Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

---

From: "Nataraju A B" <[email-masked]>
Date: Mon, 23 Jan 2006 19:22:15 +0530

RFC does not forbid sending re-INVITE soon after sent the ACK for the
200OK. 

I guess it would be reasonable to drop that particular retransmitted
INVITE when UAS was in expectation of ACK for the initial INVITE. If so,
the ACK Might reaches the UAS and the actual intention of the re-INVITE
would be taken care by the subsequent retransmitted re-INVITE. 

Here we are assuming, if re-INVITE can reach UAS, for sure ACK might
also reach UAS, 

Assume if all the re-INVITEs were dropped because ACK was not received
for the earlier INVITE transaction, that lead to call termination (BYE &
200) that is very much inline RFC.

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
srinidhi n
Sent: Sunday, January 22, 2006 10:38 PM
To: Xiao Wang; 'Jin, Haipeng'; 'Manish Joshi'; 'James M. Polk';
'Miloslavsky Evgeny'; [email-masked]
Subject: RE: [Sip] Re: Re-Invite before ACK

-Srinidhi