SOLVED nexmo and fusionpbx don't talk to each other

Status
Not open for further replies.
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
Hello,
I have a nexmo account and use it to get leads, but for some reasons my fusionpbx setup just doesn't talk to nexmo. A test call just terminates and doesn't go anywhere. Is there any way or if anyone has used nexmo with fusionpbx can help me?
Any suggestions would be really helpful.
 
A

atmosphere617

Member
May 19, 2018
31
4
8
Those are all response codes that end a transaction. Unfortunately that does nothing in the way of helping to narrow down your problem. I'd recommend installing sngrep on your server and start by posting a screen shot of the dialog between your server and the provider.
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
atmosphere617 said:
Those are all response codes that end a transaction. Unfortunately that does nothing in the way of helping to narrow down your problem. I'd recommend installing sngrep on your server and start by posting a screen shot of the dialog between your server and the provider.
Click to expand...
Thank you for suggestion,
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
This is the reply from nexmo rep,
". However, that SIP endpoint is challenging with the "Proxy Authentication Required" response."
Any idea how do I disable incoming calls authentication?
 
A

atmosphere617

Member
May 19, 2018
31
4
8
A default fusionpbx instance has an internal profile that runs on port 5060. The internal profile is pointed to each domains "authenticated context". This will always respond with a 487 which informs the client to perform digest authentication. The UA is expected to send another invite with a hash of it's creds.

IIRC, there is also an external profile on a default fusionpbx instance that runs on port 5080. The external profile points to the "public" context, which is where all the dialplan extensions for your inbound routes live. You might want to make sure you are pointing the carrier at the correct SIP profile: "your_sip_host:5080" instead of "your_sip_host:5060".
 
Last edited:
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
atmosphere617 said:
A default fusionpbx instance has an internal profile that runs on port 5060. The internal profile is pointed to each domains "authenticated context". This will always respond with a 487 which informs the client to perform digest authentication. The UA is expected to send another invite with a hash of it's creds.

IIRC, there is also an external profile on a default fusionpbx instance that runs on port 5080. The external profile points to the "public" context, which is where all the dialplan extensions for your inbound routes live. You might want to make sure you are pointing the carrier at the correct SIP profile: "your_sip_host:5080" instead of "your_sip_host:5060".
Click to expand...
Thank you,
But my problem seems to be something different, as this server used to work great but due to some reason a call used to ring 2 times even after answering 1st time it would ring 2nd time. So I was working on server but all of a sudden it stopped working.
 
A

atmosphere617

Member
May 19, 2018
31
4
8
Post some logs or a siptrace or at least some more details about your configuration. No one is going to be able to help you without more information.
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
ef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:620 (sofia/internal/as100@15.206.248.133) State Change CS_HANGUP -> CS_REPORTING
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/as100@15.206.248.133) Running State Change CS_REPORTING (Cur 2 Tot 60)
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/as100@15.206.248.133) State REPORTING
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:174 sofia/internal/as100@15.206.248.133 Standard REPORTING, cause: WRONG_CALL_STATE
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/as100@15.206.248.133) State REPORTING going to sleep
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:611 (sofia/internal/as100@15.206.248.133) State Change CS_REPORTING -> CS_DESTROY
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_session.c:1726 Session 59 (sofia/internal/as100@15.206.248.133) Locked, Waiting on external entities
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [NOTICE] switch_core_session.c:1744 Session 59 (sofia/internal/as100@15.206.248.133) Ended
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [NOTICE] switch_core_session.c:1748 Close Channel sofia/internal/as100@15.206.248.133 [CS_DESTROY]
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:739 (sofia/internal/as100@15.206.248.133) Running State Change CS_DESTROY (Cur 1 Tot 60)
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/as100@15.206.248.133) State DESTROY
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] mod_sofia.c:364 sofia/internal/as100@15.206.248.133 SOFIA DESTROY
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:181 sofia/internal/as100@15.206.248.133 Standard DESTROY
4db5834c-7973-4e04-aef8-39d1c80140bb 2021-01-17 15:15:36.027332 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/as100@15.206.248.133) State DESTROY going to sleep
92765648-41f8-4335-95ca-e83ed65b09b8 2021-01-17 15:15:40.187333 [NOTICE] switch_channel.c:1118 New Channel sofia/internal/as100@15.206.248.133 [92765648-41f8-4335-95ca-e83ed65b09b8]
92765648-41f8-4335-95ca-e83ed65b09b8 2021-01-17 15:15:40.187333 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/as100@15.206.248.133) Running State Change CS_NEW (Cur 2 Tot 61)
92765648-41f8-4335-95ca-e83ed65b09b8 2021-01-17 15:15:40.187333 [DEBUG] sofia.c:10280 sofia/internal/as100@15.206.248.133 receiving invite from 193.29.14.118:5070 version: 1.10.5 -release-17-25569c1631 64bit
2021-01-17 15:15:40.187333 [DEBUG] sofia.c:10374 verifying acl "nexmo" for ip/port 193.29.14.118:0.
2021-01-17 15:15:40.187333 [DEBUG] sofia.c:2434 detaching session 92765648-41f8-4335-95ca-e83ed65b09b8
2021-01-17 15:15:40.187333 [WARNING] sofia_reg.c:1794 SIP auth challenge (INVITE) on sofia profile 'internal' for [99801114705525188@15.206.248.133] from ip 193.29.14.118
92765648-41f8-4335-95ca-e83ed65b09b8 2021-01-17 15:15:40.187333 [DEBUG] switch_core_state_machine.c:604 (sofia/internal/as100@15.206.248.133) State NEW
66d574b6-7440-4c8b-a9a5-459485cccc33 2021-01-17 15:15:43.067336 [WARNING] switch_core_state_machine.c:688 66d574b6-7440-4c8b-a9a5-459485cccc33 sofia/internal/as100@15.206.248.133 Abandoned
66d574b6-7440-4c8b-a9a5-459485cccc33 2021-01-17 15:15:43.067336 [NOTICE] switch_core_state_machine.c:691 Hangup sofia/internal/as100@15.206.248.133 [CS_NEW] [WRONG_CALL_STATE]
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
atmosphere617 said:
Post some logs or a siptrace or at least some more details about your configuration. No one is going to be able to help you without more information.
Click to expand...
Please lemme know, If I have to do something else apart from following the quick install guide, then I change the firewall settings, then I do the sip profiles ip addition and in domains allow the 0.0.0.0/32 to allow all the incoming calls. but still no success
 
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,043
565
113
You shouldn't have needed to touch the firewall settings and you definintely should not have done 'in domains allow the 0.0.0.0/32 to allow all the incoming calls'
 
A

atmosphere617

Member
May 19, 2018
31
4
8
Yeah, you are really opening yourself up to some serious toll fraud. If you disable authentication on the internal context you're going to get hacked very quickly. I would recommend pointing inbound calls from the provider to the external profile on 5080. Once you get a better understanding of how the ACL system works on the profiles, you can implement a more advanced config like it seems like you are going for.
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
DigitalDaz said:
You shouldn't have needed to touch the firewall settings and you definintely should not have done 'in domains allow the 0.0.0.0/32 to allow all the incoming calls'
Click to expand...
The aws firewall I updated for only allowing udp and tcp ports as mentioned in quick install guide.
And 0.0.0.0/32 is kind of last resort. Since I couldn't figure out what to do.
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
atmosphere617 said:
Yeah, you are really opening yourself up to some serious toll fraud. If you disable authentication on the internal context you're going to get hacked very quickly. I would recommend pointing inbound calls from the provider to the external profile on 5080. Once you get a better understanding of how the ACL system works on the profiles, you can implement a more advanced config like it seems like you are going for.
Click to expand...
On the vonage end, I point there sip to my "destination@myip" should I add 5080 as well to it?
 
M

manindersinghajimal

New Member
Oct 1, 2020
26
0
1
33
andycol said:
take a look at a sip trace as that will giving you a hint
Click to expand...
SIP/2.0 407 Proxy Authentication RequiredVia: SIP/2.0/UDP 169.55.62.70;branch=z9hG4bK1a69.26f7e6f39b5d8e2dc19d3938d4a0c73f.0Via: SIP/2.0/UDP 10.183.28.163:5060;received=10.183.28.163;branch=z9hG4bK3921b9db;rport=5060From: "SAN FERNANDO CA" <sip:+1747******@sip.nexmo.com>;tag=as579fd1abTo: <sip:1669******@15.206.**.**>;tag=ZmD0c7rtKtXUeCall-ID: 30ceedfc00a01332185f7bc2633a1632@sip.nexmo.comCSeq: 102 INVITEUser-Agent: FreeSWITCHAccept: application/sdpAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBESupported: timer, path, replacesAllow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, referProxy-Authenticate: Digest realm="15.206.**.**", nonce="90382937-6c32-47c0-8857-18ee875aa126", algorithm=MD5, qop="auth"Content-Length: 0
 
A

atmosphere617

Member
May 19, 2018
31
4
8
It looks like you are trying to route calls from your carrier directly to the internal context. The only way I can think of that you could get this to work would be to add the carrier IP to the "domains" ACL.

It would be much easier if you just used the external profile, and terminate calls from your carrier to port 5080 on your box.

Edit:
Context param on default fusionpbx is "internal" and the context is changed to <domain> via the xml user directory for an authed user(on a normal setup).
 
Last edited:
Status
Not open for further replies.
Top Bottom