SIP Problems on 155

Hi @raffe,

Thanks. I want to avoid this. Hopefully we can identify and fix the root cause of my problems.

Downgrading isn’t that easy for me. My last backup is some versions old :frowning:

Exactly: No public (dynamic) IP address has been exclusively assigned to you.

That’s right again.

DS Lite

DS Lite steht für Dual Stack Lite und ist eine Tunneltechnik. Das heißt: Jeder Kunde hat ein öffentliches IPv6-Präfix, also mehrere IPv6-Adressen. Zusätzlich nutzen bis zu 60 Kunden zusammen eine öffentliche IPv4-Adresse. So kann jeder Kunde sowohl IPv4- als auch IPv6-Dienste nutzen. Gleichzeitig werden die selten gewordenen IPv4-Adressen gespart.
[ Wissenswertes über DS Lite - Vodafone Community ]

Many more hints available by a simple search in
google.de → “Vodafone DS light” (restrict to ‘last year only’)

1 Like

Hello Manfred,

Thanks for your explanations. All your arguments sound reasonable to me that I seem not to have a real IPv4 address. Unitymedia sold it to me as IPv4 :frowning: :
I got a written confirmation like this '… und IPv4 Anschluss bleibt erhalten".

What does it mean to solve my problem?

Is there any IPFire core 155 user with Unitymedia as ISP, a Dual Stack Lite connection, and an ATA SP112 working behind the IPFire firewall?

Christian Morgenstern - “Die unmögliche Tatsache” :

Weil, so schließt er messerscharf,
nicht sein kann, was nicht sein darf.

Kind regards
Manfred

1 Like

Either live with it, and open the required (UDP) ports,
or upgrade your ISP contract.

As usual:

  • You get what you pay for.

Personally, I decided to pay for a business connection by M-Net (Munich)
which even provides a static IPv4 :slight_smile: ,
circumventing all of those problems initiated by “Geiz ist geil”.

From the experience with one of my customers in Bergisch Gladbach,
I humbly propose to look into serious contracts with NetCologne.
They offer cheap DS Lite - right;
but AFAICR they also offer connections on serious basis.

The weighing of interests is completely up to you.

1 Like

@ewald, okay, that all makes perfect sense, let me explain what happens here. Thanks for the details.
You have a typical VoIP NAT problem.

First of all, for your understanding, VoIP consists of two parts, signaling and media, signaling is done via SIP while the media (audio here) is done by RTP. Dialing, ringing, answering, forwarding, registration, all is handled by SIP, mostly using UDP on port 5060.
Once a connection is established between two partys, a media stream flows between the two endpoints using RTP on negotiated ports.

What is happening in your case?
Your SPA is registering itself at the ISP using SIP over UDP.
All it can do is to tell your ISP, “Hello I’m here and my IP is 192.168.1.5”. Your ISP sends an answer via UDP from where it got the request. Because IPFire has a port forward rule on port 5060, your SPA will receive this answer. So far, so good.

Outbound signaling works fine, this is like registering, you will receive an answer from the ISP.

But you won’t get any inbound calls, because your ISP just knows your SPAs internal IP, which the SPA has registered, but which can’t be reached, of course.
What your ISP should/must know is the external IP, the IP of IPFire’s red interface.

Media (audio), is pretty much the same, your SPA sends RTP to the ISP, the other party can hear you.
The ISP sends its RTP to the registered address, which is (again) your internal one. You won’t hear the other party.

An ALG “sniffs” all SIP messages and replaces the SPAs internal address with the external IP, so the ISP knows where to send SIP and RTP packages.
Replacing SIP IPs correctly, is often challenging and not all ALGs did it the right way.
But you don’t have an ALG anymore, so you need to setup a STUN server as alternative. Basically the STUN server helps the SPA to get/know its outside IP.
This is done in the SPAs SIP menu under “NAT Support Parameters”.
If your ISP has no own STUN server, just use a free one.
In your setup, using a STUN server is nearly the only alternative, I can see.

You can track/log SIP messages on IPFire using tcpdump on the CLI.
Google “tcpdump SIP decode” for parameters and instructions.
Install tcpdump as Addon.

3 Likes

Hi @marco,

You are great! It is working now :grinning: Many, many thanks!

Adding a STUN server did the trick:

Now my phone works again without (!!) any additional forward firewall rules.

The solution is so simple.

Thanks again for your good explanation and your decisive hint how to solve my problem.

Happy Easter!

1 Like

This might work, but it must not.
You are counting on a technique, that UDP responses are being forwarded by IPFire to the SPA.
DNS over UPD works the same way.
Problem is, when your ISP initiates an UPD request at some time later which IPFire drops. SPA has a keep alive mechanism to circumvent this, but I would not rely on it.
So my advice is to leave the two forwarding rules in place.

2 Likes

Hi Marco,

thanks a lot again. So far the first telephone calls with the STUN server setting, but without any forward rule in place, were OK. I will observe the call quality and add the two rules as necessary.

Thanks again for helping me (and others with the same configuration) to overcome my telephone problems after the ALGs were removed in IPFire.

1 Like

@ewald Hello ewald

I recommended you if something works without opening from outside to inside (portforwarding), then prefer this way. Iam a big fan from only open if its absolute necessary!

My own experience how Voip works for me since several years in orange, ipv4 only (no CGN)

  • without portforwardings
  • without ALG (from beginning i never needed this)
  • without SIP Proxy
3 Likes

@anon33261557 Thanks Tulpenknicker for your recommendation and sharing your experience.

I share your opinion to use port forwarding only if absolutely needed. In my case, port forwarding is not needed, too. I am listening if my telephone shows any (short) audio interruptions. So far, no interruptions did occur.

Is there any security risk to switch on the SIP proxy inside the SPA112?

@marco: A very nicely written compendium, indeed!
There is only one point where I would like to expand your wording:

Exploiting one (dynamically assigned) external IP, this problem simply does not exist at all.
As proven, with proper distinct SIP / RTP configurations, neither ALG nor STUN are needed at all.

@ewald’s situation seems comparable to a huge housing block with 60 flats,
where the 60 families decide to share a single private class A network 10.0.0.0
and one ISP connection with ‘only’ one single (dynamic) external IPv4.
Any Problem? Not at all!
The SysAdmin will assign IP ranges and disjunct port number groups for each family - that’s it.
NAT and Masquerading will work their way.

BUT in case of Vodafone et al, they want to spare themself this administrative effort = cost.
And the users still expect to “just plug their devices in, and everything has to work out-of-the-box”,
without any ‘configuration burden’ for them at all.
But that comes with a cost:

  • disclosing internal information externally
  • allowing external techniques to open your firewall → broken by purpose

@ewald, with stun.t-online.de, you have chosen quite a reliable candidate.

But this night I came across a proposal for you to circumvent the need for ALG and STUN:
You can’t really get to know which ports the other guys in your up-to-60-customers-herd are using;
but with a very high probability, most of them are just using equipment defaults and ALG.
So if you are only a little bit prepared to test,
configure your ATA to some not-so-obvious UDP ports, e.g.

  • SIP TCP Port Min: nnn60
  • SIP TCP Port Max: nnn80
  • RTP Port Min: nnn04
  • RTP Port Max: nnn20
  • Per default, the RTP port range is specified from 16384 to 32767.

I expect NAT to work without ALG, without STUN,
hopefully without port forwarding rules,
at least as long as no other guy in your up-to-60-customers-herd starts
using exactly these same numbers by accident → bad luck for both :wink: ,
but not very probable; and you could re-select a-new in only a few seconds.

I’d like to encourage you to at least test this out, please.
That would clarify the situation for others as well.
Sorry, I have no chance to test that myself (no ‘DS lite’).

In the Vodafone Community Forums, you can find hints how to enforce Vodafone
to upgrade your connection to a (dynamic) exclusive IPv4 or a real dual stack.

Kind regards to NRW.

Thanks again to @marco.

1 Like

Not that I know of. But here I do it the same way. If I don’t need it, I don’t use it. Remember that I can only talk about what works for me. For example, I know that @arne_f has written here and in other threads several times that he needs a SIP proxy.

Right, that completely depends upon your ISP’s / your SIP provider’s demand.
In my case, I use identical “Proxy-Server-Adress” = “Registration-Server”.

In my Vodafone(UnityMedia) case a SIP proxy is NOT necessary.

Here my configuration once more:

  • Provider Vodafone (UnityMedia), Technicolor TC4400 cable modem in bridge mode, power upload option (dual stack), TC4400’s WAN address shown is 10.xx.xx.xx, IPv4 address (may be DS lite??)
  • Router IPFire core 155, w/o port forward, no open ports, no ALG,
  • ATA SPA112 w/ STUN server set, no SIP proxy necessary
  • BTW, even for business customers Vodafone does NOT offer in Germany, NRW a fixed ‘IPv6 prefix’, only the IPv4 address is fixed! The ‘IPv6 prefix’ can vary!

A good explanation about DS lite in German language is here

I will test Manfred’s proposal later on.

1 Like

I did now the experiment as suggested by Manfred @manfred_knick

SIP port: UDP 5060 (required by my ISP)
SIP TCP Port: Min 17860 Max 17880 (nnn=178)
RTP Port: Min 17804 Max 17820 (nnn=178)

STUN server set and enabled: Phone works incoming and outgoing properly
STUN server cleared and disabled: No incoming call possible

No port forwards defined in both cases. ALGs not available in IPFire core 155 anymore.

For this experiment, a working STUN server is necessary. Just choosing nnn differently from 080 does not help.

BTW:

@manfred_knick : In the Vodafone Community Forums, you can find hints how to enforce Vodafone
to upgrade your connection to a (dynamic) exclusive IPv4 or a real dual stack.

=> This upgrade is called ‘Power Upload Option’ which I have. I comes with a dynamic public IPv4, real dual stack, and a double upload speed, in my case 20 Mbps. It is a reasonable cheap upgrade. I purchased it since I need a VPN connection from outside which required IPv4 at that time.

Hope this helps. At least, I am very happy to have a working solution. Working with STUN is OK for me.

1 Like

Yes, indeed.

Last unknown combination:

  • no STUN
  • but port forwards

Could you provide us with the favor of this final experiment?

Thanks a lot!

Just remembered and found your post 57 above containing

and

which displays a private 10.xx.yy.zz address only.
I’m still puzzled :upside_down_face: .

To me, https://ip.zuim.de/ seems to be a good page to test for real dual stack.

Nevertheless:

  • Enjoy your phone working again !

Hi Manfred @manfred_knick ,

Happy Easter!

I was able to get a bit more detail on my internet connection type:

The config file of my TC4400 cable modem allows conclusions:

ex-Unitymedia/Vodafone is still using config files as follows:

native IPv4: cust-own_<download_rate><upload_rate>ipv4_sip_wifi-on.bin
Dual Stack lite: cust-own
<download_rate>
<upload_rate>dslite_sip_wifi-on.bin
Dual Stack: cust-own
<download_rate>_<upload_rate>_ds_sip_wifi-on.bin

There are some examples for this in the Internet.

My one is of type ‘native IPv4’. Therefore, I do have a public IPv4 address which is dynamically assigned, usually it changes once a day (after reboot of my modem).
Basically, I am an native IPv4 existing customer (Bestandskunde). BTW, this is what I requested ex-UnityMedia when I switched to my private modem TC4400.

However, I do not know whether my IPv4 is tunneled inside IPv6.

At least, this explains above test results.

1 Like

Hi All,

Here the final test result as suggested by Manfred @manfred_knick for my configuration:

port forward red => IP of SPA112 / UDP 5060
port forward red => IP of SPA112 / UDP RTP min : RTP max
port forward red => IP of SPA112 / TCP SIP min : SIP max (? not sure if this is necessary)
STUN server cleared and disabled in SPA112

Result: No incoming calls are possible.

Summary: For my configuration the definition of STUN server is the only working solution.

1 Like

@ewald: Thanks a lot!