[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 


From: Rockson Li (zhengyli)
Sent: Sunday, September 14, 2008 9:06 PM
To: 'aayush bhatnagar'; sip at ietf.org
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of aayush bhatnagar
Sent: Sunday, September 14, 2008 8:27 PM
To: sip at ietf.org
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip