19 Dec
2012
19 Dec
'12
10:48 p.m.
On 13 Dec 2012, at 11:09, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
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
Hello,
On 12/12/12 4:19 AM, Jon Morby wrote:
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
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda