Telekom SIP Trunk becomes unreachable after some time

Started by Xaver, October 01, 2026, 02:57:32 PM

Previous topic - Next topic
Hello,

I am having an issue with the SIP trunk on my Telekom fiber connection.

In general, everything works correctly. The Grandstream HT802v2 successfully registers both telephone numbers (one for telephone and one for fax). Both lines can make and receive calls, caller ID works, and incoming numbers are displayed correctly.

However, after some time — sometimes after 3 hours, sometimes only after a day — the lines become "dead".

When someone calls in, the call is immediately forwarded to voicemail. When trying to make an outgoing call, I get a busy signal.

The Grandstream's status page still shows both lines as **Registered**.

The problem eventually resolves itself without any intervention. Sometimes this happens within 15 minutes, but often it takes 1–2 hours.

Sometimes only one of the two lines is affected. The Internet connection itself remains fully operational during this time.

### Troubleshooting

To diagnose the problem, I have already captured traffic on the LAN interface of the Grandstream while the problem was occurring. I also enabled debug logging on the Grandstream and forwarded the logs to an external syslog server.

From what I can tell, it looks as if Telekom is acknowledging the keep-alive packets, while the SIP registration itself may actually have expired.

In OPNsense, under **Firewall > Diagnostics**, the states/connections show that the Grandstream keeps its connections to Telekom open and that they remain **Established**. According to the keep-alive interval, packets are exchanged approximately every 30 seconds.

Despite this, the SIP connection eventually becomes unusable.

At this point, even with some help from AI, I have reached the limits of my knowledge regarding what is actually causing the problem or which setting I might need to change.

Network setup

┌─────────────────────┐
│    Fiber connection │
└──────────┬──────────┘
           │
           │ Fiber
           ▼
┌─────────────────────┐
│   Media converter   │
└──────────┬──────────┘
           │
           │ Ethernet
           ▼
┌─────────────────────┐
│      OPNsense       │
│      Firewall       │
└──────────┬──────────┘
           │
           │ Ethernet
           ▼
┌─────────────────────┐
│ Grandstream HT802v2 │
│                     │
│  FXS 1 ─────────────┼──────► Telephone
│                     │
│  FXS 2 ─────────────┼──────► Fax
└─────────────────────┘


Settings I have already tried

OPNsense:

  • Outbound NAT set to Hybrid
  • Static Port enabled in the Outbound NAT rule for the Grandstream's fixed IP address
  • Normalization disabled for the Grandstream's IP address on both the LAN and PPPoE interfaces, so that the QoS Layer 3 packet markings are not removed

Grandstream HT802v2:

  • Updated to the latest stable firmware (not beta): 1.15.1
  • Scheduled daily reboot at 03:00
  • SIP transport protocol: TCP (I also tried UDP)
  • SIP Server: tel.t-online.de
  • DNS Mode: SRV
  • Keep-Alive: On
  • Keep-Alive method: OPTIONS/NOTIFY → OPTIONS
  • Keep-Alive interval: 30 seconds
  • Register Expiration: 12 minutes
  •   I also tested 15 minutes, 8 minutes and 20 minutes
  • Only the following codecs are enabled:
  •   G.722
  •   PCMA

My questions

Has anyone experienced a similar problem with Telekom SIP trunks behind OPNsense?

Is there anything specific I should check in OPNsense regarding SIP over TCP, NAT, state timeouts, or connection tracking?

Could there be an issue with the SIP registration being considered valid by the Grandstream even though the registration has actually expired on the Telekom side?

Any suggestions on what I could check next would be greatly appreciated.

Thank you!

Have you tried killing the session on the firewall when the issue occurs? Basically just a data point, but it might help determine the point in the protocol stack where the issue lies.

October 01, 2026, 08:24:17 PM #2 Last Edit: October 01, 2026, 08:25:50 PM by nero355
Quote from: Xaver on October 01, 2026, 02:57:32 PMOPNsense:

  • Outbound NAT set to Hybrid
  • Static Port enabled in the Outbound NAT rule for the Grandstream's fixed IP address
  • Normalization disabled for the Grandstream's IP address on both the LAN and PPPoE interfaces, so that the QoS Layer 3 packet markings are not removed
Don't you need to do some Port Forwards for VoIP too ?!

The last time I was messing around with VoIP was around 15 years ago, so I don't remember all the rules exactly :)
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

@Xaver, if you are using an updated OPNSense version, you can migrate Outbound NAT to Source NAT. Once migrated there is a new option in the Source NAT rule called "endpoint independent". You can try enabling that. Is the "full cone nat"

It seems to me that this option is not present in the old Outbound NAT rule menu but if it is, you don't need to migrate to the new system.

Quote from: Xaver on October 01, 2026, 02:57:32 PMAny suggestions on what I could check next would be greatly appreciated.

Is this a new installation or has it worked in the past?

I'm unable to resolve any SRV records for tel.telekom.de, but this may be because I am elsewhere in the world.

Searching the net it appears the SIP server to use is tel.t-online.de and SRV records can be resolved for this address.

Perhaps this page will help: https://www.telekom.de/hilfe/internet-telefonie/telefonie/voice-over-ip-sip-client

Another tidbit I came across is you need to be querying the DNS servers offered by Telekom to ensure it works: https://support.yeastar.com/hc/en-us/articles/360014536894-Recommended-SIP-Configuration-for-Deutsche-Telekom

Which DNS servers are used by the ATA?

If you find you can receive a call as soon as the ATA has registered, but you can't receive an incoming call after a couple of minutes, or until the next registration, you could drop the Keep-Alive interval to 25 seconds. If you use TCP for the SIP connection the state timeout should be the default of 86400 seconds when it is established.

I recently moved some numbers to another ITSP and I'm using TLS and SRTP. I've set the registration interval for this service to 5 minutes.

Have you created specific firewall rules for your VoIP service?

You mentioned you disabled 'Normalization', are you referring to OPNsense?

Does the QoS from Telekom use DSCP and do you know what values these should be?

Quote from: nero355 on October 01, 2026, 08:24:17 PMDon't you need to do some Port Forwards for VoIP

I haven't encountered a situation where port-forwarding has been required for VoIP. Providing the connection that your registration is going through is kept alive, incoming calls should reach the ATA.

First of all Thank you all al lot for thoughts an pointers. Will try to work them through.

Quote from: muchacha_grande on October 01, 2026, 10:49:56 PM@Xaver, if you are using an updated OPNSense version, you can migrate Outbound NAT to Source NAT. Once migrated there is a new option in the Source NAT rule called "endpoint independent". You can try enabling that. Is the "full cone nat"

It seems to me that this option is not present in the old Outbound NAT rule menu but if it is, you don't need to migrate to the new system.

It is the current stable OPNsense 26.7.4 released, will upgrade to 26.7.5 this weekend. But didn't migrate to Source NAT till now, will take a look at this this weekend as well.

Quote from: lmoore on October 01, 2026, 11:11:15 PMIs this a new installation or has it worked in the past?

New installation, before my Provider was Vodafone via TV/Cable network, rest of setup, HT802v2 and opnSense is the same, the Vodafone box was operation in bridge mode, so all the login and stuff was managed by opnSense, same as with Telekom now.

Quote from: lmoore on October 01, 2026, 11:11:15 PMI'm unable to resolve any SRV records for tel.telekom.de, but this may be because I am elsewhere in the world.

Searching the net it appears the SIP server to use is tel.t-online.de and SRV records can be resolved for this address.

Perhaps this page will help: https://www.telekom.de/hilfe/internet-telefonie/telefonie/voice-over-ip-sip-client

Thnx for this pointer, there was an error in my post, I used the correct tel.t-online.de server, the page was also given form the Telekom support.

# nslookup -query=naptr tel.t-online.de
Server:        --SNIP--
Address:    --SNIP--

Non-authoritative answer:
tel.t-online.de    naptr = 30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
tel.t-online.de    naptr = 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de    naptr = 20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.

# nslookup -query=SRV _sips._tcp.tel.t-online.de.
Server:        --SNIP--
Address:    --SNIP--

Non-authoritative answer:
_sips._tcp.tel.t-online.de    service = 10 0 5061 mue000-l01-mav-pc-rb-001.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de    service = 30 0 5061 nes008-f01-mav-pc-ra-001.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de    service = 20 0 5061 hno002-f01-mav-pc-ra-001.edns.t-ipnet.de.

Quote from: lmoore on October 01, 2026, 11:11:15 PMAnother tidbit I came across is you need to be querying the DNS servers offered by Telekom to ensure it works: https://support.yeastar.com/hc/en-us/articles/360014536894-Recommended-SIP-Configuration-for-Deutsche-Telekom

Which DNS servers are used by the ATA?

If you find you can receive a call as soon as the ATA has registered, but you can't receive an incoming call after a couple of minutes, or until the next registration, you could drop the Keep-Alive interval to 25 seconds. If you use TCP for the SIP connection the state timeout should be the default of 86400 seconds when it is established.

I recently moved some numbers to another ITSP and I'm using TLS and SRTP. I've set the registration interval for this service to 5 minutes.

Have you created specific firewall rules for your VoIP service?

opnSenese uses the DNS it will receive during PPPoE login, and the ATA use the opnSense as DNS, this should be fine.

Apart from the normalization and static port in the Out-NAT there are no further rules for the ATA.

If I set the register expire below 7 Minutes, it looks like I run in a rate limit at the Telekom Server. Than it happens that I get a 403 response from telekom for  about 20 min in the  ATA SIP logs.

Quote from: lmoore on October 01, 2026, 11:11:15 PMYou mentioned you disabled 'Normalization', are you referring to OPNsense?

Does the QoS from Telekom use DSCP and do you know what values these should be?

Yes in OpnSense, I create a normalization rule for the LAN and WAN Network, this was given Tip form the AI, apparently Telekom is strict about the lifetime of SIP packages, can*t really verify if it will help or not.

I will now try to let a paket capture running for a whole session "Working - Failure - Working" to get an inside what the ATA doing or what answers it get or not.

The main problem is that I have to call my own phone periodically to find out if the Problem is currently occurring.

Quote from: Xaver on October 05, 2026, 02:25:31 PMopnSenese uses the DNS it will receive during PPPoE login, and the ATA use the opnSense as DNS, this should be fine.
AFAIK those two are not related in any way ?!

WAN DNS = DNS for OPNsense OS.
OPNsense LAN DNS Server = Unbound or DNSmasq depending on your configuration.
And those two never include the WAN DNS in their configuration ?!
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

Quote from: Xaver on October 05, 2026, 02:25:31 PMthe ATA use the opnSense as DNS,

Are you using Unbound as the DNS server on your OPNsense box?

Quote from: Xaver on October 05, 2026, 02:25:31 PMa normalization rule for the LAN and WAN Network

Unless they only accept VoIP connections with specific DSCP markings, the PF Normalisation may not provide you with any perceivable benefit. If you haven't configured FQ_CoDel queues in OPNsense, you may want to set it up as this will provide you with lower latency for your connections to the Internet - See https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html#fighting-bufferbloat-with-fq-codel

Can you be sure AI knows the DSCP settings for your VoIP service!?

There is a link in this posting to documentation which may provide the DSCP markings you require - https://telekomhilft.telekom.de/conversations/festnetz-internet/dscp-klassen-f%C3%BCr-voip/668669584ae73561dada193e