[SR-Users] Help with Asterisk RT integration

[Jon Morby]

On 13 Dec 2012, at 11:09, Daniel-Constantin Mierla <miconda at gmail.com> wrote:

> Hello,
> 
> On 12/12/12 4:19 AM, Jon Morby wrote:
>> Hi
>> 
>> I'm trying to integrate a (K) front end cluster with an Asterisk back end cluster and Asterisk RT (legacy system)
>> 
>> I've followed the recipe at http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
>> 
>> (with one minor exception …)
>> 
>> 	if (from_uri!=myself && uri!=myself)
> this condition filters the traffic that comes from an external sip network and goes to an external sip network. Such requests are denied.



In my tests, the current example config forwards those calls directly to the Asterisk box from one of the accounts (randomly?) that are currently logged in and the asterisk box then forwards them over the PSTN/ITSP without further checks (causing the logged in user to be billed for the call)

I've tried several calls and it rotates around the logged in SIP users

This is all with 3.3.2-1.1 RPMs … I'm going to build 3.3.3 from source (as the RPMS aren't out yet) and see what happens


> 
>> 
>> became
>> 
>> 	if (uri!=myself)
> This condition is for destination to be a local address (domain part to match the server address or hostname).
> 
>> 
>> as with the original line in place we were able to spoof traffic from 3rd party sites and route out onto the PSTN (which I thought was bad) …
> The condition for pstn should be at least that caller is a local user and authenticated. This is in the route[PSTN] from kamailio's default config file.
> 
>> 
>> anyway …
>> 
>> 
>> The problem I'm seeing currently is that when a call is passed down a SIP trunk to an end user on the (K) platform we're losing the DNID
>> 
>> Asterisk delivers the call to SIP/account/DNID
>> 
>> (K) however just tries to deliver the call to DNID at domain which comes back as not found.
> 
> Maybe you can post ngrep trace of such call, taken on kamailio server, to see the incoming and outgoing traffic. I didn't understand what is the real problem, but with the ngrep trace we can see the signaling and tell where it may be the issue.

I think Daniel Tryba has hit the nail on the head

What I need to work out (and I'm sure K does this, I'm just struggling to locate the relevant docs) is route the inbound calls via the logged in trunk user

I'm going to investigate t_relay() and hopefully figure this bit out :)

What I want is inbound call to 123 to be delivered via username at domain with 123 intact as the recipient so the receiving PBX knows to route the call to the relevant extension

effectively 

exten => 123,n,Dial(SIP/123 at username)

as Daniel describes

Jon




> 
> Cheers,
> Daniel
>> 
>> I've had limited success hand coding aliases into the alias_db however we're still missing the DNID info and having to scrape it from the SIP To field (with a) limited success and b) fears of a support nightmare if we try and move existing customers onto the new platform).  If we were to do this for real I'd either have to modify usrloc or try some perl_exec magic I'm guessing … (although it might be possible with a view on the existing sql database … but I'd rather not have to do that if there is a simpler way)
>> 
>> I confess I'm struggling to get my head around the config and docs and hoped someone could point me in the right direction?
>> 
>> For legacy reasons Asterisk needs to be in the critical path on this particular build … what I'm looking for is a simple recipe and some helpful pointers on how to implement it that will allow enable me to swing (K) into the path between our end user SIP devices and the existing asterisk back ends without losing the ability to deliver hundreds of numbers down a single SIP trunk to a subscriber, and that doesn't require them to make any changes on their end as they will still see the equivalent of SIP:${DNID}@example.com arriving on their PBX
>> 
>> This should be simple, but I'm obviously missing something :)
>> 
>> Help and pointers gratefully received
>> 
>> 
>> 
>> 
> 
> -- 
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>