Any idea ?
Even with debug 10 it’s not possible to see any incoming traffic on the Asterisk.
I’ve checked with X-Lite and it’s working fine (possible to dial and to be called).
It might be a firewall issue. Is your Asterisk server sitting behind a firewall and does it have a NATed connection?
If so the firewall may need configuration and also the Astertisk server need some NAT config in sip.conf (i.e. setup localnet=, externip=, nat=yes, etc).
no, the Asterisk is not behind a firewall (even the linux firewall is shut down).
A notebook connected via the same switch works fine with X-lite. So I’ve installed X-Lite for linux and found that this does have the same problems as the Asterisk itself (so register is possible but nothing else).
Looks like a Linux-issue now. Any idea ? (although it’s the incorrect forum now).
Thanks a lot
sorry, my fault. Of course there is a Firewall. The Fritz-Box does have a buit-in one
I changed the environment:
Asterisk + X-Lite (V2.0 for testing purpose only) on Linux server. 2 laptops in same network both with Windows and X-Lite 3.0. All computers connected over the same switch to the router (Fritz-Box). The Windows phones are able to register and to call / to be called, but still everything on linux is not.
I think X-Lite 2.0 does have NAT problems, so I stopped testing with this. This is now my sip.conf
I did now uncomment this line, did a sip reload in the CLI and tried to dial in. It still doesn’t work and there is no output in CLI.
After reload there was only
== Parsing /etc/asterisk/sip.conf: Found
== Parsing /etc/asterisk/users.conf: Found
== Parsing /etc/asterisk/sip._notify.conf: Found
On the webaccess from sipgate I can see a missed call and I received the announcement “the person you have called is temporarily not available. Please try again later…”
I had similar strange effects with an ubuntu intrepid install and switched to Asterisknow, because i was to lazy to debug this. Btw. i had the same strange behavior with siproxd on this intrepid install. Looked like all port 5060 udp traffic went to /dev/null while the packets themselfs were visibly coming in when i looked with tcpdump…