My advice would be to get the carrier to fix the buggy stack on their equipment, not to try to hack around it in various kludgy ways.
In general, if you're going to use some sort of SIP network element to deal with interop bugs, a proxy is not the best thing to use, anyhow. A B2BUA - preferably a "fat" one (less transparent than a "thin" one) - that is tolerant and can normalise some of these interop bugs toward the other call leg would be ideal.
In this case, the problem is too fundamental for any UA to have to reasonably cope with it, so that's irrelevant. But it is a best practice in principle, at least in my opinion. A proxy is more or less constrained to relay the requests and replies exactly as it receives them, and although the IETF SIP WG keeps approving kludgy hacks for unanticipated functional needs - like the draft (is it an RFC now?) that allows a proxy to modify the From and To headers - the fundamental precept here is a misguided one.
-- Alex
Daniel-Constantin Mierla wrote:
There is something wrong upstream, in the carrier network.
One observation -- the ACK is looping on .189.92 -- there are two Via headers.
Since the contact from 200ok is lost, the proxy does not how to handle the ACK which is part of INVITE dialog. You have to ask the carrier to fix it in its side. It is not much you can do unless you try some hacks, e.g., use a htable to store target asterisk based on callid, detect bad ACK and forward them using the IP from htable.
However, you probably have to do the same hacks for BYE (and other in-dialog requests), when coming from carrier.