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)
became
if (uri!=myself)
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) …
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@domain which comes back as not found.
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
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.
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@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.
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
On Thursday 13 December 2012 12:09:46 Daniel-Constantin Mierla wrote:
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@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'm not using RT integration but I see the same "problem"[1] if I interpret Jon's message correctly.
The asterisk to kamailio invite will be something like: INVITE sip:31880100781@kamailio SIP/2.0 From: "Daniel" sip:0402938661@asterisk;tag=as67f9e721 To: sip:31880100781@kamailio
If you are using alias_db_lookup on invite to rewrite the request to a username at the kamailio domain to forward the request to a registered local subscriber the DNID will be replaced by the username:
INVITE sip:username@endpoint:5060;transport=udp SIP/2.0 From: "Daniel" sip:0402938661@asterisk;tag=as67f9e721 To: sip:31880100781@kamailio
Essentially the difference between asterisk extensions: exten => 123,n,Dial(SIP/123@username) and exten => 123,n,Dial(SIP/username)
A solution might be to forward to and external domain with unchanged "username", but that doesn't work if the current setup is natted without portforwards.
It shouldn't be to hard to write a custom sql query to figure out to which subscriber a block of number belongs and get the ip/port/protocol combinations from the subscriber list to create branches to t_relay() the INVITE.
[1]: I'm undecided whether if this is a problem of feature. Aastra devices can't handle the DNID format, but I prefer DNID INVITES for PBXs. But a decent PBX should be able to use the To header to figure out the dialed extension (but often not without manual reconfiguration).
On 13 Dec 2012, at 11:09, Daniel-Constantin Mierla miconda@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@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@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@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
On Wednesday 12 December 2012 04:19:48 Jon Morby wrote:
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 :)
Though it took me some time to figure this out, it really is very simple:
route[RELAY] { if(is_method("INVITE") && $avp(rewriterUtU)) { $rU=$tU; } ...
Seems to work perfectly for an Avaya IP Office:
INVITE sip:avayademo@172.16.0.4:5060;transport=udp SIP/2.0. ... To: sip:0123456789@172.16.32.42.
will be rewritten to
INVITE sip:0123456789@172.16.0.4:5060;transport=udp SIP/2.0. ... To: sip:0123456789@172.16.32.42.
The "hard part" it so set the avp for the legacy subscribers :)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Jon Morby