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

[Geoffrey Mina]

Hello,
I am wondering if anyone can help me determine what the problem is
with some SIP signaling.  I have two environments and in both
scenarios my configuration and topology are almost identical...
although I am dealing with two different carriers upstream.

In my environments, I have Kamailio (1.5) sitting in front of a
multitude of Asterisk machines.  I am using the dispatcher module to
distribute INVITE requests across the network.  I am doing some
interop with a new carrier and we are  struggling a bit with some
looping scenarios.  They are sending invites to my Kamailio server, I
am forwarding to asterisk.

On the one that is not working, I am seeing the following in sip_trace

INVITE (from carrier)
INVITE (to asterisk)
100 TRYING (from asterisk)
200 OK (from asterisk)
200 OK (to carrier)
ACK (from carrier) - this is where the loop starts.  Kamailio sends
the ACK to itself until the "max-hops" is reached... then it dies
ACK (from itself to itself)
ACK (from itself to itself)
ACK (from itself to itself)
...
200 OK (from asterisk - because it never got ACK)
200 OK (to carrier)
ACK (from carrier) - again the loop.
ACK (from itself to itself)


The only thing I can see that is different between the two carriers
(working and non-working) is that the working carrier appears to send
the ACK with an RURI equivalent to the Contact: header from the 200
OK.  On the carrier that isn't working, the RURI in the ACK is just
the IP of my Kamailio server.  Here is the relevant part of my route()
method which should catch all the ACK routing:

              if(has_totag()) {
                ##
                ## If we are in-dialog loose_route() should return
true and we should
                ## end up inside next IF.
                ##
                if (loose_route()) {
                        xlog("L_INFO", "Loose route has returned true,
attempting routing.\n");

                        ## Do Accounting ##
                        if(is_method("BYE")){setflag(2);}

                        route(3);   //this just does a t_relay() with
some extra logging
                        exit;
                }

                if ( is_method("ACK") ) {
                        # relay only ACKs belonging to an active transaction
                        # - otherwise we have no routing info for it
(should have
                        # gone via above loose_route() IF)
                        if ( t_check_trans() ) {
                                t_relay();
                        }
                        exit;
                }

                ##
                ## within-dialog messages without Route are rejected
                ##
                sl_send_reply("404","Not here");
                exit;
        }

I have read through the RFC 3261 to try and figure out what is
breaking this, but haven't been able to.  I basically need to
determine if the signalling is correct... what is wrong with my
config... and if the signalling is wrong, what the carrier is doing
incorrectly.

Thanks in advance!
Geoff