Re: [Sip-implementors] REFER received before ACK, What should be done !!
Hi Roman, Thanks for the clarification. I have changed the code and now the phone is resilient to “out of the order REFER and ACK”. Regards, Karthik From: Roman Shpount Sent: 06 September 2018 22:56 To: Karthik Sasupalli Cc: sip-implementors@lists.cs.columbia.edu; Brijesh Mishra - ERS, HCL Tech ; Ajit Kumar Singh Subject: Re: [Sip-implementors] REFER received before ACK, What should be done !! Karthik, You desk phone seems to be broken. It should handle REFER or re-INVITE before ACK. There is no reason in any RFC why UA should generate an error message for the next INVITE or REFER request, if it is received before ACK from the previous transaction. The main purpose of ACK is to stop 200 OK re-transmission. It is very often re-ordered by the network or proxies with request that starts the next transaction. If you are going to generate error responses to re-INVITE received before ACK, you are going to have serious interop problems, since a lot of SIP service providers do exactly this (send a re-INVITE at the same time as ACK) when trying to limit call to a single codec. Also, you cannot rely on Retry-After header in error response, since it is not always supported. In a lot of cases Retry-After is ignored and call simply ends. Error response 491 is wrong here as well, since it is intended for two UA sending INVITE to each other at the same time, not same UA sending INVITE twice. It will still work for re-INVITE (not REFER) but it is not the intended usage. Regards, _ Roman Shpount ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] REFER received before ACK, What to do!!
Thank you for the clarification. I have changed the code. Now the phone is resilient to handle out of order Refer an Acknowledgement in the problem scenario. On Fri, Sep 7, 2018, 8:17 AM Dale R. Worley wrote: > karthik sasupalli writes: > > I have a scenario, where the REFER to an INVITE is received before the > ACK. > > > > There is a Desk Phone and a Call server. The call is initiated by the > Call > > server. > > > > Desk Phone <-- INVITE <-- Call Server > > Desk Phone --> 180 Ringing --> Call Server > > Desk Phone --> 200 OK/SDP --> Call Server > > *Desk Phone <-- REFER <-- Call Server* > > Desk Phone <-- ACK/SDP <-- Call Server > > > > The dialogue becomes confirmed when ACK is received. But in this case, > the > > REFER is received before ACK and hence it is received even before the > > dialogue is confirmed. > > The first step is to isolate what the RFCs say about the situation. > > Unfortunately REFER is rather under-specified and in practice has a > number of different usages > (https://datatracker.ietf.org/doc/draft-worley-sip-many-refers/). But > RFC 3515 section 2 does say, in regard to REFERs sent within a dialog, > >Unless stated otherwise, the protocol for emitting and responding to >a REFER request are identical to those for a BYE request in [1]. > > RFC 3261 seciton 15 explicitly allows a UAC to send a BYE within an > early dialog, which means that a UAS can receive a BYE within an early > dialog (i.e., before receiving ACK): > >BYE outside of a dialog. The caller's UA MAY send a BYE for either >confirmed or early dialogs, and the callee's UA MAY send a BYE on >confirmed dialogs, but MUST NOT send a BYE on early dialogs. > > Hence, it seems the RFCs envision that a UA may receive a valid REFER > after sending a 1xx response to an INVITE but before receiving the ACK. > > The second step is to assess whether the stated rules need to be > adjusted to work well in practice. Roman Shpount's reply discusses some > of the practical considerations. One of the most important is: > > > It is very often re-ordered by the network or proxies with > > request that starts the next transaction. > > Even if the Server sends the REFER *after* the ACK, and there is no > guarantee that the network will deliver the REFER after the ACK. So > you want to make the Desk Phone's behavior resistant to this network > behavior. I.e., it should accept and act on the REFER if it arrives > before the ACK. > > > According to RFC3515, the server should retry REFER (in case the response > > is any one of the below) > > > > Retry-After 404,413,480,486 o > > > > Retry-After 500,503 o > > > > Retry-After 600,603 o > > I'm not sure of your meaning here. If the Desk Phone does send an error > response with a Retry-After header, the Server might retry the request. > But I would be confident of that; it is not a behavior I've heard of. > > > I have changed the code in Desk Phone, so that, when a REFER is received > > before the ACK is received, the Desk Phone responds with 603 Declined. > > > > The server should understand this 603 response and try to resend REFER > > after some time so that REFER is received after ACK. > > Notice the pattern of what you've written: "I have changed the code in > XXX so that ... . YYY should ... ." > > That is, you have decided that useful operation of your device, XXX, > depends on *somebody else's* device YYY doing what you desire. Of > course, you have to depend on other devices behaving correctly, but as a > general rule, you should depend on that as little as possible. "Be > strict in the behavior of your device, be liberal in the behavior you > tolerate in other devices." > > Dale > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] REFER received before ACK, What should be done !!
Hi All, I have a scenario, where the REFER to an INVITE is received before the ACK. There is a Desk Phone and a Call server. The call is initiated by the Call server. Desk Phone <-- INVITE <-- Call Server Desk Phone --> 180 Ringing -->Call Server Desk Phone --> 200 OK/SDP --> Call Server Desk Phone <-- REFER <-- Call Server Desk Phone <-- ACK/SDP <-- Call Server The dialogue becomes confirmed when ACK is received. But in this case, the REFER is received before ACK and hence it is received even before the dialogue is confirmed. If, in place of REFER, a RE-INVITE is received (before ACK), then the Desk Phone should send 491 Request Pending, informing the server that a previous request is still being processed. According to RFC3515, the server should retry REFER (in case the response is any one of the below) Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o I have changed the code in Desk Phone, so that, when a REFER is received before the ACK is received, the Desk Phone responds with 603 Declined. The server should understand this 603 response and try to resend REFER after some time so that REFER is received after ACK. Is my approach okay in terms of RFC compatibility and implementation point of view? Please give your views. Regards, Karthik ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] REFER received before ACK, What to do!!
Hi All, I have a scenario, where the REFER to an INVITE is received before the ACK. There is a Desk Phone and a Call server. The call is initiated by the Call server. Desk Phone <-- INVITE <-- Call Server Desk Phone --> 180 Ringing --> Call Server Desk Phone --> 200 OK/SDP --> Call Server *Desk Phone <-- REFER <-- Call Server* Desk Phone <-- ACK/SDP <-- Call Server The dialogue becomes confirmed when ACK is received. But in this case, the REFER is received before ACK and hence it is received even before the dialogue is confirmed. If, in place of REFER, a RE-INVITE is received (before ACK), then the Desk Phone should send 491 Request Pending, informing the server that a previous request is still being processed. According to RFC3515, the server should retry REFER (in case the response is any one of the below) Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o I have changed the code in Desk Phone, so that, when a REFER is received before the ACK is received, the Desk Phone responds with 603 Declined. The server should understand this 603 response and try to resend REFER after some time so that REFER is received after ACK. Is my approach okay in terms of RFC compatibility and implementation point of view? Please give your views. Regards, Karthik ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
