[SR-Users] 2 Asterisk servers re-inviting around kamailio even with t_relay being used?

JR Richardson jmr.richardson at gmail.com
Wed Jun 9 17:23:19 CEST 2010


> If that's really your complete Kamailio config, it's missing a number
> of critical checks and handlers, such as loose_route(), which handles
> sequential (in-dialog) requests differently from initial requests due
> to the presence of a Route: header and a To header tag.
>
> You can't just stick cr_route() in the main route { ... } block
> without those canonical checks and expect everything to work as desired.
>
> The reason that the proxy is not seeing the sequential requests
> (reinvites, BYE, etc.) is because you don't have a Record-Route
> header, which tells the endpoints to relay sequential requests through
> the proxy on the network and transport level.  Add this to your
> initial request route prior to (cr_route())[1]:
>
>    if(!is_method("REGISTER|OPTIONS|MESSAGE"))
>       record_route();
>
> That should take care of it.
>
> -- Alex
>
> [1] And ideally, add quite a few other things as well.  See the
>     stock configuration file for more insight.

Thanks Alex.  I am testing this in the lab so I don't have a
production config loaded, I am really focused on the carrierroute
module and trying to figure that out so I'm running bare bones using
the module example.  I looked into the RR functions and read in the CR
module that it invokes the TM when necessary so I was thinking it
would take care of keeping track of dialogs.  The thing that threw me
off was the handling of the scenario 1 session with sipp was ok but
with asterisk scenario 2 it was not.

So I loaded in the record_route function in the main routing block and
it did take care of the complete session with the asterisk server, so
that problem is solved.

What I am running into now is the failure route.  If the initial
session can not compete to the fist carrierroute, the call switches
over to the failure-route[1] which invokes carrierroute again with
another domain.  Then the receiving asterisk server retransmits the
initial OK 6 times, so the transaction is lost or not held in kamailio
state, then the whole session drops after a few more seconds.  I think
there is something going on with the append_branch function that is
throwing me off.  It is needed so the failure route completes but it's
not handling the complete dialog or I could be totally off.

Thanks.

JR
-- 
JR Richardson
Engineering for the Masses



More information about the sr-users mailing list