onewhoknows <onewhokn...@gmail.com> writes: > I have a UAC sending an ACK for a 200OK (re-INVITE) to a proxy that never > gets to the UAS, this is what the ACK looks like: > > ACK sip:1000@10.69.69.70:5061 SIP/2.0 [...] > > The ACK goes to the proxy and goes no further, so the 200 OK from the UAS > keeps re-transmitting until the call drops. > > I'm trying to determine if the formatting for the ACK is incorrect or not. > The original re-INVITE does have route headers, the ACK above as you see, > does not.
The most likely problem is not that the ACK is incorrectly formatted per se, but rather that the proxy judges it is invalid within the already-established dialog. And there's no way to tell that without seeing the re-INVITE and the 200 response. You should check whether the proxy logs (or can be adjusted to log) information about the dropped ACK. Looking at RFC 3261, section 13.2.2.4 is about constructing ACKs in response to 2xx responses, and it references section 12 for how to construct requests within a dialog, specifically 12.2. 12.2 says "The UAC uses the remote target and route set to build the Request-URI and Route header field of the request." Since the re-INVITE has Route headers (which presumably duplicate the Route headers of the INVITE which established the dialog), this means that the ACK must have the same Route headers. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
