I had some issues with my Gigaset Go Box 100 (it's a VoIP DECT station) connected to an OpenWRT router (it's a TP-Link Archer C2600 with the latest 18.06.4 firmware).
I can't establish phone connections to some numbers of my callers. Sometimes I can't even here a free line signal on some phone numbers. And sometimes I can hear the ring signal and when the call is answered the connection can't establish.
If I quickly change my network to a router from my provider and connect there the Gigaset Go Box 100 it just works.
In the manual of the Gigaset it's described that I could change the SIP and RTP ports of the device and test it and furthermore if it's still not working to enable port forwarding to the Gigaset device.
Now I forwarded the ports 5060-5074 UDP for the SIP connection to my local Gigaset device and also the ports 5004-5020 for the RTP streams.
Now it seems to work. But I wonder why this works?
Normally the connection is initiated by the Gigaset device and I should not need to forward the ports. Also without the forwarding the Gigaset box is able to connect to my ISP and I can phone some (not all!) numbers.
I read that's not common to port forward all ports to the voip device. Especially I'm planning to use a second voip device and here I can't port forward the same standard ports to my provider (which seems just to accept the port 5060 for the SIP connection).
Is someone using voip from Deutsche Telekom AG (Magenta TV) in combination with an OpenWRT router?
I am using a Gigaset C530 IP, but I never had to open any ports for both my SIP providers.
Chances are that your SIP provider requires some ports to be opened and with your provider's router the ports are opened automatically with upnp. Ask them just to be sure and if necessary install upnp on OpenWrt.
Just by searching for the solution I think what I'm missing on the router is the stun-client? The Gigaset Go Box 100 does support stun and also my provider.
The registration was working even without the port forwarding. So I think I can disable the forwarding of the ports for SIP. The issues I experienced are related to the RTP, because all issues are beginning when the call line should be established.
Stun should normally handle the UDP-NAT-forwarding between the voip phones and the provider. I think I'll give it a try!
My spa941 and the gigaset support the stun, so check if you need to activate/deactivate on your unit too.
From gigaset faq:
If either you can only hear your call partner or your call partner can only hear you, change the STUN-settings in the web configurator of the base (activate if disabled and vice versa). If a call is possible afterwards, configure the send connection for all registered handsets.
If no call is possible after that, you can check your VoIP-line by echo test via Gigaset.net. The echo-service is available at the following telephone number: 12345#9 . After an announcement the echo-service will send back(directly as an echo) the voice data received from you. Please contact your provider if the echo test is okay.
I'm successfully using a Magenta VDSL connection with VoIP/ SIP using an OpenWrt router (nbg6817) and an AVM Fritz!Box 7430 in IPoE Client mode, used exclusively as SIP pbx/ ATA and DECT base station behind it (modem disabled, wlan disabled, no routing/ NAT etc. involved, it's merely a client of the OpenWrt router), locked into its own locked down VLAN/ subnet. I don't forwards any ports, but because of this and the NAT situation, the Fritz!Box needs to keep the SIP connection to the SIP servers open from the inside, by regularly pinging the ISP SIP servers and thereby keeping the conntrack table fresh ("Portweiterleitung des Internet-Routers für Telefonie aktiv halten", 30s intervals). This setup also allows multiple (independent) SIP devices to work in parallel (e.g. a fb7430 and a fb7362sl or throwing a native SIP phone into the mix).
So normally there is no port forwarding or installation of a siproxd or stun-client on the router needed? Than I have to tweak the settings on the VoIP client. I would love to close the port range again and still have a working telephone.
I don't need siproxd or stun-client, there's absolutely no special configuration on my OpenWrt router to make SIP work. The SIP client (in my case the Fritz!Box 7430) takes care of 'fooling' the firewall (conntrack table) by keeping the connection fresh (automated SIP pings in 30s intervals), to retain a 'tunnel' for the SIP server to reach it.
Works fine without needing uPnP or STUN in my experience across a number of different router environments (both OpenWrt and OEM). Probably works better with more recent SIP implementations though (i.e. those written with CG-NAT in mind - and I have tested this behind a CG-NATted ISP connection).
Toady I'll reverted the port forwardings and disabled the STUN protocol in the VoIP device. Now it seems to work but I could only test it with one number at the moment. So definitely more testing is needed.
Apologies for the thread-necro, but I've had a similar experience recently running davidc502's custom images. Originally posted over here:
Just noticed yesterday that my VOIP handset was no longer registering with Sipgate. It's a Siemens/Gigaset N510 Pro and was showing "registration failed" in the web UI for the basestation. This behaviour has only manifested since recently updating my WRT32X to build r12235. Previously i had been on r10307 since June last year, so a big jump, I know...
I did a little tcpdump'ing (VOIP telephony is my day job, lucky me!) and saw REGISTER requests going out but nothing coming back in. Previously I had no port forwards for this device configured and everything worked fine. I set up SIP and RTP port forwards to my basestation as per the Sipgate FAQs and everything is working fine again now.
So, very similar to the experiences shared above. The device used to work fine with no firewall jiggery-pokery, but an update in OpenWrt somewhere along the line broke it's tunnelling ability and I now have to set up port forwards. Fortunately I've only got the one SIP device, so this isn't a headache to manage.
From what I've seen and read any change in NAT behaviour, particularly timeouts with UDP registrations, can lead to this. If the VSP and VoIP device support TCP or (better yet) TLS connections this will frequently solve a lot of problems without requiring port forwards. Each individual SIP "channel" should also have unique source ports too (i.e. devices supporting multiple SIP connections should use a different source port for each connection).
It can sometimes be down to device configuration too - I have one UDP only VoIP service which used to work fine from a Yealink handset but something changed in the ISP's CG-NAT and that stopped working but a Fritz!Box used as an ATA and connected the same way has no trouble... (I've not been in a position to try comparing wireshark traces to attempt to figure out what the FB is doing differently as the FB uses hardcoded default values for many SIP related parameters that are never displayed).
Turns out it was because I'd enabled software flow offloading on my router; it was also affecting my Logitech Harmony Hub/Alexa interactions. There's a bit more discussion going on in the dc502 thread. I've turned off software flow offload, removed the SIP port forwards, and the basestation is registering perfectly again now.
I have two Gigaset GoBox 100 (each with 2 mobile devices connected via DECT to the GoBox). My SIP provider is easybell in Germany. ISP is Vodafone with CG-NAT via LTE.
I'm using yate (see openwrt repositories) on my openwrt router. Yate registers as a client with easybell, the GoBox registers as a client with yate. So yate acts as a client and as a server, it's just a PBX like asterisk.
Okay, it's overhead compared with connecting one GoBox directly to your SIP provider. But with several GoBoxes and several mobile devices you have the big advantage of phoning from one mobile device to another mobile device, independent to which GoBox the mobile device is connected.
First time I implemented this configuration on a GL-iNet MT300A, now it's running on a rpi4b. No problems with calls (inbound and outbound), no need for port forwarding.
it's a very old posting but I am very interested in this. Are you still successfully using VDSL with this setting ?
Just replaced my whole setting FB7360 with FritzOS as a router -- FB4020 with openWRT with Speedport entry 2 as a modem --Raspi4 with openWRT. I made FB7360 into IP client mode and set what you said about "Portweiterleitung des...." I didn't do anything on OpenWRT for this. Is it OK so ?
Is the whole thing going to work if
Now, FB7360 is an EOL device, does it matter as an IP client ? (You wrote once that an EOL router in modem mode isn't a problem, I wonder if that holds to IP client as well, because of its brainless nature?) What if I also use its internet function (like LAN port, wifi etc) in addition to using it as a telephone machine ?
And, with
do you mean putting in its own zone and rejecting forwarding to and from other zones ? (except perhaps from your management zone?)
I am doing this now as a practice for setting up the internet and three phones in another building next year. This way of setting telephones using fritzboxes seems easier than setting something up on openWRT and old FBs are pretty inexpensive. I am thinking of putting FB7360 (or something similar) for a dect phone for someone's private use (so he should keep the password, I don't want to see his call log, the whole thing should be in his own room), and FB4020 for two VoIP phones for our business calls (FB4020 should be in the patch box in the basement with other routers/switches and I manage it) What you wrote
seems to suggest that my plan should work. Is that right ?
Until ~3 weeks ago (having switched to another ISP with ISP meanwhile, but same situation with the VoIP setup there).
Yes, OpenWrt doesn't need any non-default configuration.
Yes, even if it's not directly exposed to the open internet, it is actively handling your VoIP/ SIP sessions - and that can get expensive fast, if an attacker calls random premium numbers around the globe. Look for a cheap second hand 7520 or 7530 for an actively selling/ supported device (the 7430 I'm now using is also still supported, but dropped out of the current catalogue a few months ago - so not a good choice to purchase new).
That's an optimization, to keep less-trusted commercial devices (Fritz!Box) contained, you can do that once everything is working - but you don't need to.
It should work, but more error prone than only running a single SIP pbx.
