Subject: Re: [Sip] 200 OK for PRACK received after 200 ok for INVITE

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Sun, 14 Sep 2008 21:43:15 +0800

________________________________

From: Rockson Li (zhengyli) 
Sent: Sunday, September 14, 2008 9:06 PM
To: 'aayush bhatnagar'; [email-masked]
Subject: RE: [Sip] 200 OK for PRACK received after 200 ok for INVITE

IMO, the UAC should ignore the 200(PRACK) after 200(INVITE).
 
One thing you might be aware,
 
as per RFC3262,
 
   if any of the
   unacknowledged reliable provisional responses contained a session
   description. UAS must not send 200(INVITE) until
   those provisional responses are acknowledged. 
 
-Rockson

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
aayush bhatnagar
Sent: Sunday, September 14, 2008 8:27 PM
To: [email-masked]
Subject: [Sip] 200 OK for PRACK received after 200 ok for INVITE

Hello everyone... 

I am new to the mailing list..so let me introduce myself first. 

I am Aayush from India..working in the IMS domain. I had a doubt, and i
wanted to share this with the experts on the mailing list. 

Appreciate your inputs on this....

Suppose in an INVITE initiated dialog, the 200 OK of the PRACK is
received later at the UAC than the 200 OK of the INVITE provided that
the UAS had sent them in proper order..what should be the behavior of
the UAC?

In this scenario, the UAS had sent the 200 ok of the PRACK followed by
the 200 ok of the INVITE..as it should normally.

At the application level, there is no control on which path the
datagrams shall follow to reach the next SIP hop. If the 200 OK of the
INVITE takes a shorter path to reach the next hop SIP servers on the way
to the client and eventually reaches the client before the 200 ok of the
PRACK..it will be received out of 'order' at the client. 

This may be a possibility in large distributed SIP networks. SIP only
provides a way of determining the next SIP serer hops by Route
headers..and a CSeq header to check the proper sequencing of messages.
However, it does not guruantee what network links should be taken by the
packets to reach the next hop. This is in contrast to SS7, where we have
such provisions at MTP3 layer. 

How will the sip stack at the UAC behave if such a situation occurs?
Will it silently drop the packet? Or will it establish the dialog ? Or
should it tear down the session by sending a BYE?

I believe its an implementation issue at the UAC.

Best Regards
Aayush

_______________________________________________
Sip mailing list  https://www.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