[Kamailio-Users] Need Assistance Tracking Down A SIP Signaling Problem

[Alex Balashov]

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.

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671