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
Re: [Sip-implementors] REFER received before ACK, What to do!!
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
Re: [Sip-implementors] REFER received before ACK, What to do!!
On 9/6/18 1:05 AM, karthik sasupalli wrote: 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. Please provide more detail. In particular, the content of the key messages, and what the call flow is intending to accomplish. Thanks, Paul ___ 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
