Madhuri , Do you mean that the PRACK is never sent because of which the 200 OK to INVITE never goes out ? Or there is some delay in the PRACK transaction because of which the 200 OK to INVITE is buffered for some time and then sent out ?
If it's the first case and you did not add 100Rel in the supported parameter of INVITE then the UAS is to blame , the UAS cannot expect a PRACK unless INVITE carries 100Rel support.You should correct the UAS side so that it does not expect PRACK,also I think your stack should provide some kind of event to the stack user so that the stack user knows when the PRACK transaction is complete , he can then send the 200 OK to INVITE. This way , even if the PRACK transaction is a failure the stack user can then decide not to send 200 OK but a error response. If you have added 100Rel as supported in your INVITE then you should send the PRACK from the UAC side to stop the 180 retransmissions. If it is the second case , then your UAC will receive the 200 OK for INVITE anyways after some time(Once PRACK transaction completes). You can then ACK it and BYE the dialog no issues at all. BTW , Venkatesh thanks for the thread it was enlightening. Regards , Sayan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Madhuri Sakhare Sent: Friday, May 26, 2006 1:01 PM To: [email protected] Subject: Re: [Sip-implementors] Query Regarding Collision case of CANCEL. Hi, The 180 Ringing is the provisional response. According to RFC 3262, Retransmission of 180 Ringing occurs till it receives PRACK. In this scenario, PRACK is not received; the 200 OK response of INVITE is generated before receiving PRACK and is buffered. As the 200 OK for INVITE is already sent. No further final response can be sent. After certain retransmissions of 180 Ringing, CANCEL is sent and 200 OK for CANCEL is received. How this INVITE transaction should be terminated. How should SIP stack respond? Also what happens when instead of CANCEL, BYE is sent? Regards, Madhuri ________________________________ From: Venkatesh [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 11:34 AM To: Nataraju A B Cc: Madhuri Sakhare; [email protected] Subject: Re: [Sip-implementors] Query Regarding Collision case of CANCEL. Please check this thread. The CANCEL will get a 2xx response. https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-May/012974 .html On 5/25/06, Nataraju A B <[EMAIL PROTECTED]> wrote: Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Madhuri Sakhare Sent: Thursday, May 25, 2006 7:40 PM To: [email protected] Subject: [Sip-implementors] Query Regarding Collision case of CANCEL. Hi, Consider this call flow: UAC UAS | INVITE | |----------------------->| | 180 RINGING | |<-----------------------| | CANCEL | |----------------------->| | 200 OK CANCEL | |<-----------------------| | | This is a collision case of a reliable 180 response and a CANCEL Request. The application on the callee side has sent a 200 OK response, and the response is left pending in the SIP stack. Then the collision occurs and the CANCEL is indicated to the application, but since it has already sent a final response, it has no way of sending another one. The call is not freed. How should the SIP stack responds to this? [ABN] This scenario has been discussed in the list quite a few times... if the callee UA had already sent 200OK for INVITE then 200OK will not be sent for CANCEL. CANCEL would be rejected with 481 responses... The call will go through... The caller's SIP stack has to initiate the BYE request to terminate the call once the INV/200/ACK transaction is completed... if the user had hung up the call... Regards, Madhuri _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
