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
