Incoming calls dont work on sip trunk

Hi all,

I am using Elastix 2.5 stable with asterisk 11.13.0. I
have connected to my voip provider via sip trunk and outgoing calls are
working. Incoming calls are also working but just for “any DID/any CID"
and “DID/any CID”. However, I tried to make incoming route for” DID/CID"
and “any DID/CID” and I got error “Received an unknown call with DID
set to myDID” with message “The number you have dialed is not in
service”. Why asterisk can not match the CID? (I tried with
allowquest=yes but without success )Am I missing something? Below is my
trunk configuration:

Outgoing setting
Trunk name: mytrunk

register_string=username:[email protected]/username

incoming setting:

Thank you

What about adding


to the peer details ?

Sorry I forgot to copy it, I have excatly the same in my peer details, and still the same problem.

in that case I probably can’t suggest much else than doing

asterisk -vvvvvvvvr  # not really sure how many 'v's, but 5 minimum to get very verbose output

from the ssh console, and using ngrep to catch transmissions on port 5060 in another console; it can reveal what exactly is your provider sending to you that you need to tell Asterisk/FreePBX to match to.
(the screen program/package helps a lot with this)
(it helped me when I had issues like that)


Here are prints from asterisk console when call is placed and not placed. Can I use tcpdum instead of ngrep I have some problems with installation, if you had experience with tcpdump. Thx

  1. Call is not placed
    any DID/CID

Executing [[email protected]:1] Set(“SIP/myprovider-out-0000009b”, “__FROM_DID=myDID”) in new stack
– Executing [[email protected]:2] NoOp(“SIP/myprovider-out-0000009b”, “Received an unknown call with DID set to myDID”) in new stack
– Executing [[email protected]:3] Goto(“SIP/myprovider-out-0000009b”, “s,a2”) in new stack
– Goto (from-trunk,s,2)
– Executing [[email protected]:2] Answer(“SIP/myprovider-out-0000009b”, “”) in new stack
– Executing [[email protected]:3] Wait(“SIP/myprovider-out-0000009b”, “2”) in new stack
> 0x2013fff0 – Probation passed - setting RTP source address to
– Executing [[email protected]:4] Playback(“SIP/myprovider-out-0000009b”, “ss-noservice”) in new stack
– <SIP/myprovider-out-0000009b> Playing ‘ss-noservice.gsm’ (language ‘en’)
== Spawn extension (from-trunk, s, 4) exited non-zero on ‘SIP/myprovider-out-0000009b’
– Executing [[email protected]:1] Macro(“SIP/myprovider-out-0000009b”, “hangupcall,”) in new stack

  1. Call is placed
    any DID/ any CID
    DID/ any CID

– Executing [[email protected]:1] Set(“SIP/myprovider-out-0000009e”, “__FROM_DID=myDID”) in new stack
– Executing [[email protected]:2] Goto(“SIP/myprovider-out-0000009e”, “s,1”) in new stack
– Goto (from-trunk,s,1)
– Executing [[email protected]:1] ExecIf(“SIP/myprovider-out-0000009e”, “0?Set(__FROM_DID=s)”) in new stack
– After macros are checked call is placed

Do you have the inward route configured for the DID in question ? (Extension Routes (fee)free module needs to be used)

Can you indicate in the log excerpts, where the DID is a number (say use the 555 555 555 there) and where it is a string/literal name ?

(my story is, that my SIP provider was setting the DID to … the SIP username so I had to set up the inward routes to match the /literal/ string received… towards which the route module was all like, huh, what? but it worked in the end)

Other than that,
ngrep (if from source) needs libpcap and libpcap-devel.
(excerpt from my .bash-history below)

# tar jxf ngrep-1.45.tar.bz2 # like, that was /real/ cool...  
tar jxf ngrep-1.45.tar.bz2\?download 
cd ngrep-1.45
yum install libpcap-devel
make clean
yum install libpcap
yum install libpcap-devel

you may get it to work then…


Thank you el_es for support . However, I contacted my provider who changed the line settings to trunk and now everything works.

Meanwhile I installed ngrep:)

So the problem was not on my side.


Might be beneficial for others if you share what did your provider had to change for you (and who is it) :slight_smile: other than that, glad it resolved.

Off course, but I do not know what they have changed exactly, some configuration on trunk at their side, I just complained to them that I can not figure out where is the problem. I think they configured DID number transfer on their side or something like that:)