SOLVED Ip Authentication Trunk/Gatwey Settings

[GVC]

Good day ! Using Fusion 4.2 wanted to know if some one can help with instructions on how to set a gateway based on IP authentication.

I am able to set them up via Registration but some providers require IP based trunk set up and we can not get it to work

thx

 

[DigitalDaz]

Just set it up as you would a registration trunk put set register to false. Its still requires you to put a username/password in though so just use dummyuser, dummypassord for example.

 

[Gordon Sims]

DigitalDaz,

I even tried setting this up as you suggested, but external dialing is not working. Keep getting the following error in the Freeswitch Logs:
[NOTICE] switch_ivr_originate.c:2841 Cannot create outgoing channel of type [sofia] cause: [INVALID_GATEWAY]

I have a private SIP Trunk that is delivered by my ISP that connects directly to a Cisco CUBE device, then over to an OpenSIPS Server which then routes the calls over to the appropriate servers. I was able to figure out that it still needed to be sent across port 5080 and once I got that established, figured the rest would be downhill. Unfortunately, this is not the case. I have even added listen=udp:ip.add.re.ss:5080 and listen=tcp:ip.add.re.ss:5080 to the OpenSIPS server to get it to recognize. However I did a ngrep from the FusionPBX server and not seeing it trying to establish a connection to the Gateway. The only thing I could figure is that the status shows 'Stopped' and not started. Not sure if this is because I'm not doing a registration with it or not. Is there a way around this, I've put in a dummyuser and dummypassword in as you noted above, but not sure what else I'm missing. Any advise would be greatly appreciated.

Thanks,

Gordon

 

[DigitalDaz]

When you edit a gateway you must stop it and start it again, have you done that? If so, see what you are getting in the log files when you do this start and stop.

This should absolutely not be showing stopped if it is configured correctly it should simply say NOREG and this does not depend on the remote gateway at all.

 

[Gordon Sims]

Hello DigitalDaz,

I'm definitely not getting the message of 'NOREG' on it. Log file shows the following when I try to start the gateway, but it always shows stopped, even after trying to start it.

2016-12-19 15:51:15.436273 [INFO] mod_enum.c:878 ENUM Reloaded
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-version [tlsv1]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 sip-trace [no]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 sip-capture [no]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 rfc2833-pt [101]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 sip-port [5080]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 dialplan [XML]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 context [public]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 dtmf-type [rfc2833]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 dtmf-duration [2000]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 inbound-codec-prefs [G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 outbound-codec-prefs [PCMU,PCMA,GSM]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 hold-music [local_stream://default]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 zrtp-passthru [true]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 rtp-timer-name [soft]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 local-network-acl [localnet.auto]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 manage-presence [false]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 inbound-codec-negotiation [generous]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 nonce-ttl [60]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 auth-calls [false]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 rtp-ip [10.0.119.221]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 sip-ip [10.0.119.221]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 ext-rtp-ip [10.0.119.221]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 ext-sip-ip [10.0.119.221]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 rtp-timeout-sec [300]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 rtp-hold-timeout-sec [1800]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls [false]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-only [false]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-bind-params [transport=tls]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-sip-port [5081]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-cert-dir [/etc/freeswitch/ssl]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-passphrase []
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-verify-date [true]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 user-agent-string [Nexepe]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-verify-depth [2]
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 tls-verify-in-subjects []
2016-12-19 15:51:15.436273 [DEBUG] sofia.c:4429 debug [0]
2016-12-19 15:51:15.436273 [INFO] sofia.c:5745 Setting MAX Auth Validity to 0 Attempts
2016-12-19 15:51:15.436273 [INFO] switch_time.c:1415 Timezone reloaded 530 definitions
2016-12-19 15:51:15.436273 [DEBUG] freeswitch_lua.cpp:365 DBH handle 0x7fe0c40fa670 Connected.
2016-12-19 15:51:15.436273 [DEBUG] freeswitch_lua.cpp:382 DBH handle 0x7fe0c40fa670 released.

Hope these screenshots help

Keep in ming, I have tried a couple of different config settings. with and without the port set on the hostname, tried without having the realm set or the proxy and then with both of them set. If you have any ideas or suggestions, I'm all ears.

Thanks again,

Gordon

 

[DigitalDaz]

The hostname should never be filled in, its to do with something else entirely. If your gateway at the remote end is listening on the regular 5060, just use the following config:

 

[Gordon Sims]

DigitalDaz,

You sir are awesome. Worked like a champ. I guess I was confused as to the label on hostname, thinking it was to the destination. Just needed a good smack upside my head...

Thanks again,

Gordon

 

[DigitalDaz]

Gordon, glad it worked, could you please edit the title of your post to [SOLVED]

 

[Gordon Sims]

Gordon, glad it worked, could you please edit the title of your post to [SOLVED]

I'm looking to see where I can do that, but I think since this post was originally started by GVC, he has to edit the title. Also, is there a rating system where I can give you kudos or something like that?

 

[Edward Soares]

I have tried using these instructions for VITELITY IP Auth and can not get it working. It does not appear I need to change anything, any pointers?

 

[Edward Soares]

If anyone else has this issue, my issue was I had to add my Vitelity's IP addresses from their SBC(session border controller) to my ACL in CIDR Format. You add them under Advanced-->Access Controls-->domains which btw should be set to deny by default. Then at bottom add each CIDR such as 192.168.1.0/24 under CIDR and leave domain blank and set to allow. remember to add a note to each as this list can quite long! This setup is because I am utilizing a wholesale trunk with 30+ channels now as I have outgrown the few unlimited trunks I was using and this will prove more cost effective as a provider. This is not neccessary if you are using Registration with a username. Also this will work for IP Auth regardless of whether you are wholesale or unlimited trunk etc I think. Anyway if you are trying to get IP Auth working on a regular unlimited or per minute trunk, I believe you would add your inbound.vitelity.net the same way as above but as a domain and not a CIDR and set to allow. and same either way create an outbound trunk and leave username and password blank, place your outbound IP or outbound.vitelity.net in the proxy field and set REG to false and this will allow outgoing calls. Anyone correct me if this is wrong but this works and I did not have to manually edit any files which I believe is the point of FusionPBX?

 

[DigitalDaz]

This is kind of wrong for this particular thread. By adding the carrier to the ACL, what you are effectively doing is allowing them to send their calls to port 5060. The 'clean' way to do it is to get the carrier to send your inbound calls to port 5080.

If you are doing IP auth then the gateway only comes into play for outbound calls. You could receive calls without even having ANY gateway.

 

[Edward Soares]

Vitality will not and no longer allows other than use of port 5060' at least not on the wholesale side and I've never seen it on regular side in 3+ years or more. So only way is to allow the IP through ACL for inbound. My outbound is a non registering gateway just for pointing to the Vitelity IP accepting my outbound calls. A way without doing fancy file hacking... or complicated port forwarding rules etc.

 

[DigitalDaz]

Does vitality give you interop info? ie what needs setting and what doesn't?

 

[roger_roger]

It would really useful for users not to hijack a thread, but open a new one for new questions.

 

[Edward Soares]

@roger_roger how does this constitute a hijack when it is a generic question about IP Auth of which i was alos trying to figure and alas after figuring it out posted my results to help others in need?

 

[roger_roger]

@roger_roger how does this constitute a hijack when it is a generic question about IP Auth of which i was alos trying to figure and alas after figuring it out posted my results to help others in need?

Just my opinion... the original question was answered and perhaps that would cause people who were looking at it to not stop by again. By posting a new thread for Vitelity specifically, it might have helped others who were looking for that question. It just gives more granularity to the various questions. My 2 cents...

 

[Edward Soares]

Ah ok that makes sense. I did not intend for it to happen this way, this was the thread that came up in my search and when I did figure it out I answered my own high level question I posted already for when someone came across it. Is there a section we can add specific provider information to?

 

[roger_roger]

Ah ok that makes sense. I did not intend for it to happen this way, this was the thread that came up in my search and when I did figure it out I answered my own high level question I posted already for when someone came across it. Is there a section we can add specific provider information to?

Yes! There's a section that DigiDaz created called SIP Providers.

 

[MTR]

If anyone else has this issue, my issue was I had to add my Vitelity's IP addresses from their SBC(session border controller) to my ACL in CIDR Format. You add them under Advanced-->Access Controls-->domains which btw should be set to deny by default. Then at bottom add each CIDR such as 192.168.1.0/24 under CIDR and leave domain blank and set to allow. remember to add a note to each as this list can quite long! This setup is because I am utilizing a wholesale trunk with 30+ channels now as I have outgrown the few unlimited trunks I was using and this will prove more cost effective as a provider. This is not neccessary if you are using Registration with a username. Also this will work for IP Auth regardless of whether you are wholesale or unlimited trunk etc I think. Anyway if you are trying to get IP Auth working on a regular unlimited or per minute trunk, I believe you would add your inbound.vitelity.net the same way as above but as a domain and not a CIDR and set to allow. and same either way create an outbound trunk and leave username and password blank, place your outbound IP or outbound.vitelity.net in the proxy field and set REG to false and this will allow outgoing calls. Anyone correct me if this is wrong but this works and I did not have to manually edit any files which I believe is the point of FusionPBX?

i followed this step by step guide
outgoing calls are working for inbound its not working
below is what i see in the logs
2017-10-25 04:14:06.554015 [WARNING] sofia_reg.c:2906 Can't find user [pt@45.77.106.23] from 64.2.142.90
You must define a domain called '45.77.106.23' in your directory and add a user with the id="pt" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
2017-10-25 04:14:06.554015 [WARNING] sofia_reg.c:1737 SIP auth failure (INVITE) on sofia profile 'internal' for [7186331442@45.77.106.23] from ip 64.2.142.90
0e31c260-f020-4d3e-ba22-378c3f319469 2017-10-25 04:14:06.554015 [NOTICE] sofia.c:2332 Hangup sofia/internal/3476783994@66.241.99.236 [CS_NEW] [CALL_REJECTED]