13 Dec
2012
13 Dec
'12
3:04 p.m.
On Thursday 13 December 2012 12:09:46 Daniel-Constantin Mierla wrote:
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).
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
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.