PBXact to Snom PA1 setup


(Mike Ledbetter) #1

I installed a Snom PA1 to our UC25 PBXact system, and I thought I could configure it by just creating an Identity with the Extension, Login Name and Password, Server IP and Port, and the PA system would register to the Extension I created in the PBXact. The extension is set up as SIP, and yet when I look under Asterisk Info and Peers, the device never appears to connect. What am I doing wrong?


#2

Is the snom pointing to the same port that CHAN_SIP is listening to?


(Mike Ledbetter) #3

Where do I find that information? Our PBXact is on 5160


(Dave Burgess) #4

When you created the extension, you identified the port number you would be using by deciding which driver you’d be using. If you created it as a Chan-SIP extension and your system is set up to use the default port numbers, the port on the PBX will be 5160. The SNOM needs to be told to access the server through that port by connecting through 192.168.x.x:5160 (if you just use the PBX address, it assumes 5060).

If you are pointing at the wrong port, the /var/log/asterisk/full log will be filled with failed connection attempts. Posting one of those may help us help you troubleshoot this.


(Mike Ledbetter) #5

OK, it shows connected but no voice comes through speaker. Snom PA1 Logs show this:
26/11/2019 14:00:48 [FATAL ] LID: LLDP: No Voice Application Type TLV packet found!
26/11/2019 14:01:18 [FATAL ] LID: LLDP: No Voice Application Type TLV packet found!
26/11/2019 14:01:49 [FATAL ] LID: LLDP: No Voice Application Type TLV packet found!
26/11/2019 14:02:19 [FATAL ] LID: LLDP: No Voice Application Type TLV packet found!
26/11/2019 14:02:49 [FATAL ] LID: LLDP: No Voice Application Type TLV packet found!
26/11/2019 14:02:59 [NOTICE] PHN: TPL: Socket 105 idle/connect timeout
26/11/2019 14:03:03 [NOTICE] PHN: TPL: Socket 104 idle/connect timeout
26/11/2019 14:03:07 [NOTICE] PHN: TPL: Socket 106 idle/connect timeout
26/11/2019 14:03:08 [NOTICE] PHN: TPL: Socket 107 idle/connect timeout


(Dave Burgess) #6

One-way audio (even if it’s failing in both directions) is almost always a NAT error. You’ll need to start checking the 10000-20000 port traffic now,