At the end of the last installment, I’d been dealing with unavailable servers (turns out they were moving between datacenters, and there didn’t seem to be any announcement of this), and compiles that refused to compile. I decided to cut my losses for a bit, and move on to getting functionality like inbound calls working.

It’s taken multiple days of scratching my head and muttering at the system, but I can finally start focusing on getting DISA (direct inward system access) running, because I’ve got inbound calls working. The problem lay not in FreeSWITCH, but in the Sipura 3102s (aka Linksys 3102s) configuration for the PSTN Line tab. On this tab, there’s a SIP Port field, and a proxy field. I had set the SIP Port field to 5080, to match the “external” context available in FreeSWITCH. However, every inbound call would result in log entries like the following


[NOTICE] switch_channel.c:1104 New Channel sofia/internal/[email protected]
[DEBUG] sofia.c:10080 sofia/internal/[email protected] receiving invite from 192.168.1.94:5060
[DEBUG] sofia.c:10251 IP 192.168.1.94 Rejected by acl "domains". Falling back to Digest auth.
[WARNING] sofia_reg.c:1793 SIP auth challenge (INVITE) on sofia profile 'internal' for [[email protected]] from ip 192.168.1.94
[WARNING] sofia_reg.c:2915 Can't find user [@pbx] from 192.168.1.94

That inbound call should never be showing up in the “internal” context.

It turns out the SIP Port field on the PSTN Line configuration is a listening port. Altered the Proxy field to be “pbx:5080” instead of “pbx”, and the calls now come in on the correct context, and the logs look more like


[NOTICE] switch_channel.c:1104 New Channel sofia/external/[email protected]
[DEBUG] sofia.c:10080 sofia/external/[email protected] receiving invite from 192.168.1.94:5060
[DEBUG] sofia.c:7291 Channel sofia/external/[email protected] entering state [received]

Much better.

Adventures with FreeSWITCH and FusionPBX part deux
Tagged on: