TIPS Inbound from different IP than registered trunk

[Phoenix]

Hello,
I am trying to get Callcentric DID to work, and so far the only way I have gotten it to work is by enabling Anonymous SIP calls. This seems to be also the only method I can find online...

Is there no way to register both callcentric.com and at the same time tell the system to accept call from specifically 66.193.176.35 (the IP it sends inbound calls from)?

I was thinking of creating a second trunk with this IP instead of the callcentric host, but that does not seem to work either - does anybody have an idea what I am missing?

Thank you!

 

[briankelly63]

post a sanitized version of your trunk config

 

[krzykat]

The second trunk concept should work if that is the IP that it is coming from. I recently had one of my carriers that had been working for quite a while start to fail on an inbound route out of the blue. Nothing had changed on the server, and it took me quite a while to trace down the issue. Like you, the only thing that would work is if it was set to allow guest = yes. The answer was to add a line to the trunk config of "insecure=very". Not sure if you have a similar issue, but might be worth a shot.

 

[Phoenix]

Thanks for your replies - I had the same thoughts with insecure=very, but I see no change (PBX picking up and claiming "not connected").

Here are my trunk configs:
Main trunk (which registers to the server using the register string):

username=1777275xxxx
type=peer
secret=xxxxxxxx
insecure=very
host=callcentric.com
fromuser=1777275xxxx
fromdomain=callcentric.com
dtmfmode=rfc2833
disallow=all
allow=ulaw&g729
context=from-trunk
canreinvite=yes

Inbound trunk (no registration):

username=1777275xxxx
type=peer
secret=xxxxxxxx
insecure=very
host=66.193.176.35
fromuser=1777275xxxx
fromdomain=66.193.176.35
dtmfmode=rfc2833
disallow=all
allow=ulaw&g729
context=from-trunk
canreinvite=yes

 

[jroper]

Hi

Don't forget that on later versions of Asterisk, insecure=very has been replaced with insecure=port,invite

Joe

 

[briankelly63]

This is quite right.... I still have a Callcentric account even though I don't use it so I took a look at their GUI config options.

Normally you make a choice regarding using registration or not for INCOMING calls. If you have a working registration string the carrier knows that you are there and what IP address you are at. It also serves to keep open a state table entry in your router otherwise there would be no path from one "side" of your router to the other. Some carriers allow you to configure a destination IP for a trunk that doesn't require a registration string at all BUT then you must provide a port forward on your router that allows ONLY their trusted IP's otherwise you'll have a security issue.
Outgoing calls don't require registration but instead rely upon your username and password.

On a Vitelity inbound trunk for example all I need in the trunk config is:

type=friend
dtmfmode=auto
context=from-trunk
canreinvite=no
host=64.2.142.15

But on the Vitelity GUI I have to tell them what my system IP is and do the port forward I mentioned.

You didn't mention if you have a static IP or if you have any port forwarding in place but if you didn't have any other trunks that were already doing a registration your non-registration trunk wouldn't work at all "anonymous" or not. The registration string is opening port 5060 and the router must be set so that its not rejecting traffic that doesn't come from the original IP address.

I don't see anyway in the Callcentric GUI to tell them to send a call to a specific IP and not require registration (as you can with other carriers). Your trunk config that doesn't do a registration doesn't really do anything on an "incoming" call. So having your username and password in there doesn't accomplish anything because its never being sent (only sent for outgoing). If I missed the fixed IP entry option on the Callcentric side let me know.

So..... you really should just use the registration method for your Callcentric trunk and that's it. There is no reason you need to allow the 66.193.176.35 as a separate "incoming" entry in Asterisk. Whether you need to set up a port forward from that address in your router is another story because it depends on how the router security is setup. Depending on the configuration the router may reject the incoming address because you never sent any outgoing packets to that incoming ip address. The registration you are doing is to a different ip address.

Configuring PEER details and having a registration string on the Callcentric trunk should be all you need.

It would also be helpful to have a CLI trace that shows what is hitting the box when you call your DID number.

 

[jeffmac]

I have had similar issues with Future Nine over the years. Very infrequently they will send me an incoming call from one of their backup servers. To avoid this I added additional trunks for the other hosts , with no registration string, but with 'qualify=yes'. This setting keeps iptables and the router happy to accept SIP invites from the address, and Asterisk can match the ip address so you don't get "unknown peer" issues. It has worked flawlessly for me since I put it in - I have no idea how often it gets used this way, I just know that the call failures I once saw no long occur.

Simply put, I use the addition trunk method without issue.

Jeff

 

[Phoenix]

Thank you Jeff and Brian for your help -
From what I can tell Callcentric forwards nicely to the Asterisk box, but Asterisk then does not recognizes the IP and tosses the call away.

This is my CLI:

[2013-09-11 13:13:13] VERBOSE[4287][C-00000002] netsock2.c: == Using SIP RTP TOS bits 184
[2013-09-11 13:13:13] VERBOSE[4287][C-00000002] netsock2.c: == Using SIP RTP CoS mark 5
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [17772751505@from-sip-external:1] NoOp("SIP/66.193.176.35-00000002", "Received incoming SIP connection from unknown peer to 17772751505") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [17772751505@from-sip-external:2] Set("SIP/66.193.176.35-00000002", "DID=17772751505") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [17772751505@from-sip-external:3] Goto("SIP/66.193.176.35-00000002", "s,1") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Goto (from-sip-external,s,1)
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:1] GotoIf("SIP/66.193.176.35-00000002", "0?checklang:noanonymous") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Goto (from-sip-external,s,5)
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:5] Set("SIP/66.193.176.35-00000002", "TIMEOUT(absolute)=15") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] func_timeout.c: -- Channel will hangup at 2013-09-11 13:13:28.811 UTC.
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:6] Answer("SIP/66.193.176.35-00000002", "") in new stack
[2013-09-11 13:13:13] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:7] Wait("SIP/66.193.176.35-00000002", "2") in new stack
[2013-09-11 13:13:15] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:8] Playback("SIP/66.193.176.35-00000002", "ss-noservice") in new stack
[2013-09-11 13:13:16] VERBOSE[4538][C-00000002] file.c: -- <SIP/66.193.176.35-00000002> Playing 'ss-noservice.gsm' (language 'en')
[2013-09-11 13:13:21] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:9] PlayTones("SIP/66.193.176.35-00000002", "congestion") in new stack
[2013-09-11 13:13:21] VERBOSE[4538][C-00000002] pbx.c: -- Executing [s@from-sip-external:10] Congestion("SIP/66.193.176.35-00000002", "5") in new stack
[2013-09-11 13:13:21] VERBOSE[4538][C-00000002] pbx.c: == Spawn extension (from-sip-external, s, 10) exited non-zero on 'SIP/66.193.176.35-00000002'
[2013-09-11 13:13:21] VERBOSE[4538][C-00000002] pbx.c: -- Executing [h@from-sip-external:1] Hangup("SIP/66.193.176.35-00000002", "") in new stack
[2013-09-11 13:13:21] VERBOSE[4538][C-00000002] pbx.c: == Spawn extension (from-sip-external, h, 1) exited non-zero on 'SIP/66.193.176.35-00000002'

My Callcentric incoming trunk is now this but I still get the same issue - I use PIAF Green, is there another command for qualify that would be applicable?
I must be missing something very simple here - or do I just have to abandon the idea of free DIDs and start paying for it?

type=friend
insecure=port,invite
dtmfmode=auto
context=from-trunk
canreinvite=no
host=66.193.176.35
qualify=yes

 

[briankelly63]

change type to peer

 

[briankelly63]

see also "Sip Peer's"

http://kb.smartvox.co.uk/asterisk/secure-asterisk-pbx-part-2/

 

[billsimon]

To deal with CallCentric's many gateways, I threw the following list into /etc/asterisk/sip_custom_post.conf to let Asterisk know that these gateways are allowed to send calls to us:

[alpha1_cc]
type=peer
context=from-pstn
host=alpha1.callcentric.com
 
[alpha2_cc]
type=peer
context=from-pstn
host=alpha2.callcentric.com
 
[alpha3_cc]
type=peer
context=from-pstn
host=alpha3.callcentric.com
 
[alpha4_cc]
type=peer
context=from-pstn
host=alpha4.callcentric.com
 
[alpha5_cc]
type=peer
context=from-pstn
host=alpha5.callcentric.com
 
[alpha6_cc]
type=peer
context=from-pstn
host=alpha6.callcentric.com
 
[alpha7_cc]
type=peer
context=from-pstn
host=alpha7.callcentric.com
 
[alpha8_cc]
type=peer
context=from-pstn
host=alpha8.callcentric.com
 
[alpha9_cc]
type=peer
context=from-pstn
host=alpha9.callcentric.com

Someone else recommended adding qualify statements to enable firewall/NAT traversal. Good idea; just add a qualify=yes to each of the blocks.

 

[gpuser]

I am not sure what I am going to suggest would be good or bad but it's an idea. Since we have an easy install script and a tutorial to install Skype and FreeSwitch on PIAF, why not use FreeSwitch to connect to such providers that send incoming from various IPs? Just a matter of configuring another gateway in the xml config and send calls to something like 127.0.0.1:5071 from where Asterisk takes over.