Cannot register extension

[Routhgen]

Hello,

Debian installation, forwarded UDP ports: 5062 -> 5060 5063 -> 5160

tried pjsip and chan_sip

from tcpdump I can see its coming inside trying to register, no response from inside container :-( extension created with name: 1111 and some password for testing purpose only registering from Zoiper, its trying to register (registering) and while no response it timeouts into 408

asterisk logs are empty, even in exec and looking inside asterisk -vvvvr its blank except reload

Any suggestions where to look? Totaly lost while there is no tcpflow/dump inside container

Thanks

[tiredofit]

First try to make sure the ports are listening though other means. netstat -tunap inside the container will also help to ensure they are listening. Asterisk should be providing logs or console output, so that is a bit bizarre. I can push a new build with both tcpdump and tcpflow for you.

[tiredofit]

New build tiredofit/freepbx:15-4.0.2 or 15-latest being built on Docker Hub now with sngrep, sipsak, tcpdump, and tcpflow utilities embedded.

[Routhgen]

udp 0 0 0.0.0.0:5060 0.0.0.0:* -
udp 0 0 0.0.0.0:5160 0.0.0.0:* -

thanks for super fast response pulled new version, new tcpdump is unable to do ip proto \udp just listening to port 5160 -> nothing while trying to register

sngrep -> totaly empty

Is there any required setting which I miss?

ports also allowed on iptables, forwarded from 5063 to 5160 on GW FW

yml ports ports: - "0.0.0.0:80:80" - "0.0.0.0:443:443" - "0.0.0.0:5060:5060" - "0.0.0.0:5160:5160" - "0.0.0.0:18000-18100:18000-18100/udp"

tcpdump on host machine tcpdump -i ens18 -v -n 'ip proto \udp and port 5160' tcpdump: listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes 23:26:09.035973 IP (tos 0x0, ttl 54, id 22138, offset 0, flags [none], proto UDP (17), length 620) 188.175.137.100.65015 > 10.0.0.16.5160: UDP, length 592 23:26:12.956051 IP (tos 0x0, ttl 54, id 22266, offset 0, flags [none], proto UDP (17), length 620) 188.175.137.100.65015 > 10.0.0.16.5160: UDP, length 592 23:26:17.038121 IP (tos 0x0, ttl 54, id 22524, offset 0, flags [none], proto UDP (17), length 620) 188.175.137.100.65015 > 10.0.0.16.5160: UDP, length 592

But nothing shows up inside container, weird

[tiredofit]

I think you have it all the right way - Someone posted the other day we should be calling 5060 and 5160 with the /udp ie (5060:5060/udp) however I personally haven't had to on my own install.

Do the ports show as even listening inside the container with a netstat -tunap ?

EDIT - Sorry I saw the output at the top of your last message they are indeed listening.

Anything special about your Docker/Host installation?

[Routhgen]

Typical Debian 10, install was fine unless the port bind have to be done with 0.0.0.0 to force assign it to IPv4 and GW in front for security reasons, ports forwarded from diff ones because they are already used for old Asterisk solution.

[tiredofit]

OK, so no funky OS combos which have shown issues in the past.. Lets see here... I don't see a problem with using different ports both inside and outside the container, you would just need to change the configuration inside of freepbx to support that change in the Sip/PJSIP settings. Hopefully tomorrow I can get some time to fire up a Buster VM and try to replicate this. This shouldn't be happening.

[Routhgen]

Do you have some updates on this issue? Need to move on and start using SIP trunk.

[isabyr]

I have the same issue. Changed chan_sip to TCP, now I can telnet the port 5160 from the outside. But still asterisk logs are empty and SIP client throws Request Timeout.

My setup: host: ubuntu 1804 image: tiredofit/freepbx:latest (05b8ca72bc43)

UPD: I forgot to change network settings on client to TCP. After restarting docker compose SIP clients are able to connect now.

UPD2: Tried the same thing pjsip, got similar results.

[Routhgen]

Its weird that netstat inside of the container points the SIP ports to "dash", no Asterisk mentioned.

[Routhgen]

Maybe I got it

docker-compose.yml Specifing of SIP ports 5060 and 5160. Without specifing it means TCP AND UDP, right? On FW I let provider allow 5060+5160 TCP (only), not UDP.

Can this be an issue?

But as I can see from netstat the TCP 5060 & 5160 is not listed. I can see only udp 5060 & 5160. How to fix that?

[tiredofit]

I made a change last week on request from someone to be specifying 5060:5060/udp and 5160:5160/udp - I have never had to do that on my own systems. Try switching it to 5060:5060 and 5160:5160.

Also, can you try switching images and use tiredofit/freepbx:develop - This is a rollback to Asterisk 16 temporarily. Will be available in ~3 minutes.

[Routhgen]

5060:5060 and 5160:5160

I had it like this. It was default. I just specified 0.0.0.0 to work with IPv4. But as I mentioned above maybe the problem is with binding TCP/UDP to Asterisk. Coz TCP is not visible in netstat (5060&5160).

I will try to open TCP/UDP 5060,5160 on FW and retest it.

[tiredofit]

The Docker Image upload failed, trying again.

[tiredofit]

OK, please try tiredofit/freepbx:develop if at all possible and see if this changes anything. This is a rollback to Asteirsk 16.

[Routhgen]

Still I cant see tcp 5060 & 5160 inside the container. Request Timeout 408 persists

tcpdump inside container listening for 5160 -> nothing tcpdump on base system it listen about REGISTER from Public IP with destination of Server internal IP - any here maybe is the problem. internal IP is 10.0.0.16 but docker container IP is 178.18.0.3

compose ports:

• "0.0.0.0:5160:5160/udp" or
• "0.0.0.0:5160:5160/tcp" or
• "5160:5160"

Didnt help at all

Another test: telnet from host to container HOST telnet 172.18.0.3 5160 Trying 172.18.0.3... telnet: Unable to connect to remote host: Connection refused

CONTAINER tcpdump -i any 'port 5160' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10:21:39.981396 IP 172.18.0.1.47402 > 63cc805a345a.5160: Flags [S], seq 1526348898, win 64240, options [mss 1460,sackOK,TS val 2427767918 ecr 0,nop,wscale 7], length 0 10:21:39.981467 IP 63cc805a345a.5160 > 172.18.0.1.47402: Flags [R.], seq 0, ack 1526348899, win 0, length 0

Also test for UDP HOST nc -z -v 172.18.0.3 5160 172.18.0.3: inverse host lookup failed: Unknown host (UNKNOWN) [172.18.0.3] 5160 (?) : Connection refused

CONTAINER tcpdump 10:31:39.758996 IP 172.18.0.1.47454 > 63cc805a345a.5160: Flags [S], seq 523469471, win 64240, options [mss 1460,sackOK,TS val 2428367690 ecr 0,nop,wscale 7], length 0 10:31:39.759064 IP 63cc805a345a.5160 > 172.18.0.1.47454: Flags [R.], seq 0, ack 523469472, win 0, length 0

In wireshark its just red

What I totaly miss here? Its for sure something stupid. Im lost :-(

[Routhgen]

UPDATE Chaning port bind to "5060:5060/udp" without 0.0.0.0 fixed problem with registration. Im able to register. Nice

So registered calling into ANY inbound route pointing into IVR with some recording. It picks up the call but no RTP received.

Also Asterisk shows this:

Connected to Asterisk 16.9.0 currently running on d479133f15f3 (pid = 1686) == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 > 0x7f920406e3a0 -- Strict RTP learning after remote address set to: 192.168.5.171:60200 -- Executing [1234@from-internal:1] ResetCDR("SIP/1111-00000017", "") in new stack -- Executing [1234@from-internal:2] NoCDR("SIP/1111-00000017", "") in new stack -- Executing [1234@from-internal:3] Progress("SIP/1111-00000017", "") in new stack -- Executing [1234@from-internal:4] Wait("SIP/1111-00000017", "1") in new stack -- Executing [1234@from-internal:5] Playback("SIP/1111-00000017", "silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer") in new stack -- <SIP/1111-00000017> Playing 'silence/1.ulaw' (language 'cs') -- <SIP/1111-00000017> Playing 'cannot-complete-as-dialed.ulaw' (language 'cs') -- <SIP/1111-00000017> Playing 'check-number-dial-again.ulaw' (language 'cs') -- Executing [1234@from-internal:6] Wait("SIP/1111-00000017", "1") in new stack -- Executing [1234@from-internal:7] Congestion("SIP/1111-00000017", "20") in new stack [2020-04-07 09:23:27] WARNING[16915][C-00000017]: channel.c:4963 ast_prod: Prodding channel 'SIP/1111-00000017' failed == Spawn extension (from-internal, 1234, 7) exited non-zero on 'SIP/1111-00000017' -- Executing [h@from-internal:1] Macro("SIP/1111-00000017", "hangupcall") in new stack -- Executing [s@macro-hangupcall:1] GotoIf("SIP/1111-00000017", "1?theend") in new stack -- Goto (macro-hangupcall,s,3) -- Executing [s@macro-hangupcall:3] ExecIf("SIP/1111-00000017", "0?Set(CDR(recordingfile)=)") in new stack -- Executing [s@macro-hangupcall:4] NoOp("SIP/1111-00000017", " montior file= ") in new stack -- Executing [s@macro-hangupcall:5] GotoIf("SIP/1111-00000017", "1?skipagi") in new stack -- Goto (macro-hangupcall,s,7) -- Executing [s@macro-hangupcall:7] Hangup("SIP/1111-00000017", "") in new stack == Spawn extension (macro-hangupcall, s, 7) exited non-zero on 'SIP/1111-00000017' in macro 'hangupcall' == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/1111-00000017'

Why is it trying to point on internal 192.168.5.171:60200? Its ZOIPER device internal IP (smartphone). Tested also over public IP (LTE), no luck.

Changing directmedia didnt help.

Any idea? SIP General Public IP specified RTP Range 18000-18100 sepcified Local networks: 172.18.0.3/16 172.18.0.1/16

Im close to throw a towel and install it normal way without docker coz it doesnt seems to be able to run stable in production. Pure asterisk is much better.

[tiredofit]

It definitely works but not for the faint of heart, I'm running successfully at a handful of very large (300+ extension) sites as are others, but there are definite quirks depending on host OS and FreePBX constantly changing things around.

Regarding RTP - Sounds like perhaps the same issue is happening with your networking as was your SIP Ports. Make sure they are exposed and active. Set a STUN server if possible. Your Local Networks looks just fine although I would just make it 172.18.0.0/16.

[tiredofit]

Another way to avoid all the NAT nonsense is just run it with network: host however that sort of defeats the whole purpose of the image so that you can run it behind reverse proxies and host other services on it.

[Routhgen]

network_mode: host isnt possible, backup container cannot start with links option while this mode is set. I already tried to switch to PJSIP. Same situation.

What I totally dont understand is this: RTP Allocating from port range 18000 -> 18100 And while in call: 0x7fc9d404d710 -- Strict RTP learning after remote address set to: 192.168.234.191:41532

Why? Its not set and suppose to be here that port. Where is the definition of using these ports? FW allows 18000-18100 its set in compose and even in RTP ports in GUI, and present in asterisk RTP conf.

From where is coming this 41532?

I really would like to use this dockerized solution but its very painful.