TIPS Trunk answering with "number dial not in service"

[guilain]

Hello,

I have several functioning trunks and tried to add one I forgot about for several weeks.

I copied the PEER Details from an other (functioning) one (changing user and password) but when I call it it says that this number is not in service.
I went to the CLI and saw that everything is different when I call this one then an other one : I get

    -- Executing [+352#######@from-sip-external:1] NoOp("SIP/sipregister.#####.com-00000012", "Received incoming SIP connection from unknown peer to +352#######") in new stack
    -- Executing [+352#######@from-sip-external:2] Set("SIP/sipregister.#####.com-00000012", "DID=+352#######2") in new stack
    -- Executing [+352#######2@from-sip-external:3] Goto("SIP/sipregister.#####.com-00000012", "s,1") in new stack
    -- Goto (from-sip-external,s,1)
    -- Executing [s@from-sip-external:1] GotoIf("SIP/sipregister.#####.com-00000012", "0?checklang:noanonymous") in new stack...

and I had on the working one :

    -- Executing [s@from-trunk:1] ExecIf("SIP/anveo-00000010", "1?Set(__FROM_DID=s)") in new stack
    -- Executing [s@from-trunk:2] Gosub("SIP/anveo-00000010", "app-blacklist-check,s,1()") in new stack
    -- Executing [s@app-blacklist-check:1] GotoIf("SIP/anveo-00000010", "0?blacklisted") in new stack
    -- Executing [s@app-blacklist-check:2] Set("SIP/anveo-00000010", "CALLED_BLACKLIST=1") in new stack
    -- Executing [s@app-blacklist-check:3] Return("SIP/anveo-00000010", "") in new stack
    -- Executing [s@from-trunk:3] Set("SIP/anveo-00000010", "CIDSFSCHEME=QUxMfEFMTA==") in new stack
    -- Executing [s@from-trunk:4] AGI("SIP/anveo-00000010", "/var/www/html/admin/modules/superfecta/agi/superfecta.agi") in new stack ...

Could you please tell me where I made a mistake and how to make this trunck work in inbound. Thanks.

 

[TwigsUSAN]

Did you create an inbound route for the new trunk?

 

[jeffmac]

My first question would be why are you getting "Received incoming SIP connection from unknown peer to +352#######" if you defined the trunk and got it successfully registered? That shouldn't happen unless your trunk definitions are incorrect.

Check on registration for the trunk (you can use Asterisk Info, Sip Info)

Jeff

 

[guilain]

First I would like to thank you for your help so far

@TwigsUSAN : all the trunks are using the same (default) inbound ... for the moment

jeffmac : this is what I have in sip-info :

sipregister.#####.com:5060            N      myusername            105 Registered          Sat, 06 Jul 2013 08:46:55 and[/COLOR]
 
 
[COLOR=#000000]#####/myusername          1.2.3.4                                N            5060    Unmonitored

Seems registered to me or am I wrong ?

One question following TwigsUSAN's query : how should I use the "Incoming Settings" part of the trunk config as in all the examples I have it is always empty so I remove the default settings when I create a trunk.

Thanks once more

 

[jeffmac]

If you're using type=peer or type=friend (which allow sending and receiving calls) then you don't need anything in the "incoming" section for sip trunks.
I'm still puzzled by the call appearing in the "from-sip-external" context, although it seems to know the IP address is sipregister.
Is you trunk defined with "context=from-trunk"? (this is the default with recent PIAF releases, I believe).

Jeff

 

[guilain]

Hello Jeff,

This is what I've got in the Peer details :

username=******
type=friend
secret=######
port=5060
insecure=port,invite
host=sipregister.------.com
disallow=all
context=from-trunk
allow=ulaw

So yes, it's both friend and from-trunk

Thanks for the hand

 

[briankyarb]

I am having the exact same issue as you, that is my trunk is answering with "number not in service".

 

[rossiv]

I am having the exact same issue as you, that is my trunk is answering with "number not in service".

You have told us almost nothing. If you read the rest of this thread, you can see that we need 'status' as well as relevant call logs and sanitized FreePBX screenshots.

 

[Stewart]

I've encountered this before when the registration string is correct but the IP is wrong in the trunk settings. Since you are using DNS and not an IP, perhaps it isn't resolving as it should. Switch to the IP address in both the context and registration string and tell us if it still happens.