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).