Accepting Anonymous Calls

SpiceBlend · December 30, 2019, 2:07pm

Redhat Sangoma Linux release 7.5.1805 (Core)
14.0.13.23

I installed FreePBX on a VmWare server and registered our two Lifesize Icon 600 video conferencing units to it. I am able to make calls between the video conferencing units through the FreePBX server, but I am not able to receive anonymous, unauthenticated, calls.

I tested this by unregistering one of the units, removing the credentials, and trying to call the other unit. The call would fail without any ringing, and in the Asterisk logs I would see “authentication failed”.

I do have “Allow Anonymous Inbound SIP Calls” and “Allow SIP Guests” enabled.

I read some forum posts that indicated fixes involving a Chan SIP trunk, but I’m using Chan PJSIP, since my understanding is that’s the preferred protocol. I also read something about setting up trunks for each incoming number, is that what I need to do?

What is the right way to set these units up so that I can accept external calls from anonymous unauthenticated sources?

I feel like I must be missing something pretty simple, but I haven’t been able to solve my problem through documentation or old posts so far. Thanks in advance for the help.

billsimon · December 30, 2019, 2:34pm

Is the Lifesize unit still configured with the same username / caller ID information? If so, it is probably still matching the endpoint configured in FreePBX. You would have to remove that endpoint’s configuration from FreePBX (or change it in some way so that it cannot match) – not just unregister and remove the credentials from the endpoint.

Allow SIP Guests with PJSIP sets up the anonymous endpoint which should allow calls from anywhere, as long as they don’t match some other identifier (see above). Allow Anonymous SIP Calls directs those calls to the Inbound Routes section of FreePBX. It’s not documented clearly, but extensions can be direct-dialed in this way also, without setting up explicit Inbound Routes for them.

SpiceBlend · December 30, 2019, 2:46pm

I should have stated that I also changed the username/caller ID to an extension that doesn’t exist; “Potato”.

Sounds like it should have worked. Maybe I needed to restart the Lifesize unit or something. I’ll give this another try and post the error if I get one.

billsimon · December 30, 2019, 3:13pm

I agree; it does not sound like a complicated setup. If you’re stuck, post Asterisk logs (/var/log/asterisk/full) and maybe SIP in a pastebin (http://pastebin.freepbx.org/) for help reviewing.

SpiceBlend · December 30, 2019, 3:58pm

I’m not getting an authentication error, like I was seeing last time. This is the only thing that comes up in the asterisk logs when I try to dial from the “outside” video conferencing unit;

[2019-12-30 15:38:16] ERROR[17602] res_pjsip.c: Unable to retrieve PJSIP transport ‘udp,tcp,ws,wss’

Here’s the longer logs;
https://pastebin.freepbx.org/view/2c069bda

You’ll see a endpoint registered on “3”, that’s just my cell phone (voip) that I put on there for giggles. The two video conferencing devices are usually on “1” and “2”.

billsimon · December 30, 2019, 4:34pm

On the asterisk console (asterisk -r from an ssh session) you can get more verbosity real-time by using core set verbose 9 and you can get SIP traces real-time with pjsip set logger on. Try these to see if you can get more insight.

SpiceBlend · December 30, 2019, 4:46pm

That’s a helpful tool for sure, unfortunately it’s still not really telling me what’s going on. Presumably I broke something while trying to get this to work so I suppose I’ll reinstall the server from scratch and give it another go.

[2019-12-30 16:39:45] ERROR[17602]: res_pjsip.c:3031 ast_sip_set_tpselector_from_transport_name: Unable to retrieve PJSIP transport 'udp,tcp,ws,wss'
    <--- Transmitting SIP response (475 bytes) to TCP:192.168.31.52:16396 --->
    SIP/2.0 500 Internal Server Error
    Via: SIP/2.0/TCP 192.168.31.52:5060;rport=16396;received=192.168.31.52;branch=z9hG4bK-5e0a2851-57ad8004-5a21ed70;alias
    Call-ID: 2c77db30-341fa8c0-13c4-45026-5e0a2851-18df7ab8-5e0a2851
    From: "Conference Room" <sip:[email protected]>;tag=2c7708e0-341fa8c0-13c4-45026-5e0a2851-573e3bd6-5e0a2851
    To: <sip:[email protected]>;tag=z9hG4bK-5e0a2851-57ad8004-5a21ed70
    CSeq: 1 INVITE
    Server: FPBX-14.0.13.23(13.19.1)
    Content-Length:  0


<--- Received SIP request (715 bytes) from TCP:192.168.31.52:16396 --->
ACK sip:[email protected];transport=TCP SIP/2.0
From: "Conference Room"<sip:[email protected];transport=TCP>;tag=2c7708e0-341fa8c0-13c4-45026-5e0a2851-573e3bd6-5e0a2851
To: <sip:[email protected]>;tag=z9hG4bK-5e0a2851-57ad8004-5a21ed70
Call-ID: 2c77db30-341fa8c0-13c4-45026-5e0a2851-18df7ab8-5e0a2851
CSeq: 1 ACK
Via: SIP/2.0/TCP 192.168.31.52:5060;alias;branch=z9hG4bK-5e0a2851-57ad8004-5a21ed70
Max-Forwards: 70
User-Agent: LifeSize Icon 600/LS_RM3_2.9.0 (1982)
Contact: "Conference Room"<sip:[email protected];transport=TCP>
Allow: INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,INFO
Accept: application/sdp,application/media_control+xml,application/presentation_token_control+xml
Content-Length: 0

billsimon · December 30, 2019, 4:57pm

Before you tear it apart, I would like to call on expert @jcolp to comment on what that error might mean. That looks funny, as though it was a line from a chan_sip configuration that FreePBX attempted to apply to a pjsip configuration.

jcolp · December 30, 2019, 6:13pm

The “transport” option in chan_sip specifies the technologies that are allowed. The option in chan_pjsip specifies an explicitly configured transport. It looks like FreePBX logic isn’t correct in that scenario when writing the configuration and is treating it as a chan_sip one.

billsimon · December 30, 2019, 7:24pm

@SpiceBlend Do you have any reason not to use the latest distro? 7.5.1805 is old. This bug may have been fixed by now.

edit: indeed, the bug was reported and fixed: https://issues.freepbx.org/browse/FREEPBX-17841

Running updates on your machine should be enough (will take a while), as it was fixed in FreePBX 14.

SpiceBlend · December 30, 2019, 8:21pm

I thought I just downloaded whatever image was on the site under “stable releases”. It was a few weeks ago, maybe I clicked on the wrong thing.
I’ll go ahead and run updates instead of reinstalling, thanks for getting back to me!

sorvani · December 30, 2019, 9:33pm

This button:

Gives you this link: https://downloads.freepbxdistro.org/ISO/SNG7-FPBX-64bit-1910-2.iso

Which is FreePBX 15.

SpiceBlend · December 30, 2019, 9:50pm

Thanks all. Should I update to 15?

I ran updates on the current version and that did fix the issue I was having, though FreePBX was just immediately hanging up on the caller. So instead of calling anonymously I added a trunk, since I didn’t really want to do anonymous calls anyway, I was just doing it for testing.

That worked, but now it’s always connecting with “G.711 (µ-Law)” instead H264, so I’m only getting audio, and I didn’t see any way to enable video codecs on a trunk. Is there some place to turn this on or am I approaching this the wrong way?

billsimon · December 30, 2019, 10:09pm

It’s an open issue since 2017: https://issues.freepbx.org/browse/FREEPBX-15853

As a workaround, you can add it in the config files manually.

Edit /etc/asterisk/pjsip.endpoint_custom_post.conf.

Add a section like this:

[Zoom](+)
allow=h264

where “Zoom” (a trunk I have setup with that video provider) would be replaced with the name of your trunk (“Trunk Name” in the first tab of trunk settings).

Then run fwconsole r at the ssh command line to apply the setting.

SpiceBlend · December 30, 2019, 10:18pm

Great! I’m 99% sure I’m up and running. The web console on my video conferencing units are saying they’re connecting with H264 now, I’m just going to test with my eyes.
Thanks again for all the help!

system · January 30, 2020, 10:18pm

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.