Telekom SIP Trunk becomes unreachable after some time

[Xaver]

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

Code Select Expand

┌─────────────────────┐
│    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.telekom.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!

[pfry]

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.

[nero355]

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

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 :)

[muchacha_grande]

@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.

[lmoore]

Any 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?

Don'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.