Hi Paul

I think we have our nat stuff working on the kamailio server. The problem now for me seems to be that I have a restrictive nat going on my home network which is preventing me from receiving calls.

I am going to do some research on changing up my network here for testing.

Thanks again for all the great help.

I hope you have a wonderful weekend.

Will

On Fri, Oct 3, 2014 at 12:31 AM, Paul Smith <paul.smith@claritytele.com> wrote:
Great stuff.

NAT is a whole other basket of pain.  Again the example configs in the kamailio distribution are a good place to start... in particular the NATDETECT and NATMANAGE routines, and the nathelper and rtpproxy module usage.

good luck


Hi Paul

Just wanted to give you an update.

This looks like it has worked. Now I am dealing with my own natting issues on my home network to get the call but the invites are being sent right now.

Thanks again for the assistance.

All the best.

Will Ferrer

On Wed, Oct 1, 2014 at 11:53 PM, Paul Smith <paul.smith@claritytele.com> wrote:
Hi Will,
It sounds like your kamailio.cfg is not looking up the user location database before trying to relay the INVITE.  There is a relevant section in the kamailio-basic.cfg example configuration file:

       
request_route {
	...

        # user location service
        route(LOCATION);
}
 
...

# USER location service
route[LOCATION] {
        if (!lookup("location")) {
                $var(rc) = $rc;
                t_newtran();
                switch ($var(rc)) {
                        case -1:
                        case -3:
                                send_reply("404", "Not Found");
                                exit;
                        case -2:
                                send_reply("405", "Method Not Allowed");
                                exit;
                }
        }

        # when routing via usrloc, log the missed calls also
        if (is_method("INVITE")) {
                setflag(FLT_ACCMISSED);
        }

        route(RELAY);
        exit;
}


The logic is that if the call is for a local registered user whose location is available in the "kamctl ul"  then request_route() should pass the request to the route(LOCATION) routine.  The function call lookup("location") then does the magic if matching the address of record ([subscriber_name]@[our_domain_name]) and returning the $ruri of the registered phone ([realid]@[realip]).  route(RELAY) is then able to send the call on to the phone's actual IP address.

Hope that helps.

Paul Smith

On 02/10/14 03:33, Will Ferrer wrote:
Hi

I was wondering if any one had any advice or examples for me of how to get a call to be routed to a subscribed softphone.

We have 2 boxes in our testing deployment, a load balancer / sbc and a call processing box.

Calls come in to the sbc, and then are passed to the call processing box. The call is analyzed and the branch uri is rewritten to a destination address when applicable for the call (this is how we handle routing of calls to certain numbers -- we do this utilizing custom code and a custom db).

This works just fine when the destination sip uri is phone number (in which case we do lcr) or if the destination goes to a remote address.

However when the destination is a subscriber: sip:[subscriber_name]@[our_domain_name], the call is passed back to the sbc, which passes it to the callprocessing box, back and forth until a too many hops error occurs.

The subscriber I am trying to send the call too does show up under "kamctl ul show".

I feel like there is something basic I must be missing here.

Does any one have any advice for me?

Thank you very much in advance.

All the best.

Will Ferrer



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users