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 <wor...@ariadne.com> wrote: > karthik sasupalli <karthiksasupa...@gmail.com> 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
