SOLVED nexmo and fusionpbx don't talk to each other

[atmosphere617]

If you cannot anticipate the ip signalling originates from, you will need to use the external context. Allowing 0.0.0.0 is a terrible solution, since it allows anyone to assume the role of any extension on your pbx without authentication.

If you had the same trouble (487 response to an invite) then I would verify that you didn't mistakenly turn on auth-calls on the external context. If auth-calls is "false" you have a different issue, and need to address that directly.

 

[manindersinghajimal]

If you cannot anticipate the ip signalling originates from, you will need to use the external context. Allowing 0.0.0.0 is a terrible solution, since it allows anyone to assume the role of any extension on your pbx without authentication.

If you had the same trouble (487 response to an invite) then I would verify that you didn't mistakenly turn on auth-calls on the external context. If auth-calls is "false" you have a different issue, and need to address that directly.

I'll check it, btw it's in external sip profile right?

 

[atmosphere617]

I'll check it, btw it's in external sip profile right?

Yeah advanced -> sip profiles.The auth-calls param is what tells the profile to do digest authentication on inbound invites. The 487 is the "challenge" from freeswitch, a normal UA will respond to the 487 with a hash of it's creds and nounce string(sent in the 487).

The only way that a profile will respond to an invite with a 487 is if "auth-calls" is true.

Confluence Mobile - Confluence

freeswitch.org

If auth-calls isn't true, you have a different issue. Do another sip trace and confirm the carrier is actually routing to 5080. If so, there won't be a 487, and the sip trace may illuminate a different issue.

 

[manindersinghajimal]

Yeah advanced -> sip profiles.The auth-calls param is what tells the profile to do digest authentication on inbound invites. The 487 is the "challenge" from freeswitch, a normal UA will respond to the 487 with a hash of it's creds and nounce string(sent in the 487).

The only way that a profile will respond to an invite with a 487 is if "auth-calls" is true.

Confluence Mobile - Confluence

freeswitch.org

If auth-calls isn't true, you have a different issue. Do another sip trace and confirm the carrier is actually routing to 5080. If so, there won't be a 487, and the sip trace may illuminate a different issue.

Thank you for sharing this. And when doing sip trace, it give 407, not 487