Telekom Germany SIP Trunk SRV Records and pjsip

Did you ever test it with Deutsche Telekom (AllIP) or is it just theories? I definitely know that it’s not working using TLS (certificate validation error - yes, I used the correct server - not the one you mentioned here).
Using outbound proxy adds the following header to register:

Route: <;lr>

Deutsche Telekom expects as proxy, if any: SIP-Proxy: (see here)
I wouldn’t be surprised if they would drop the request if there is another route entry as they expect as they are pretty picky regarding other broken headers / values, too.

Here is the documentation of the interfaces of Deutsche Telekom.

Son-of-a-bitch, you are correct. I had not noticed this before, because it didn’t cause me any trouble.

However, you aren’t the only one plagued by this, and a gentleman with the problem submitted a patch that was accepted!

Outbound Proxy:\;lr\;hide
and you should be good to go. Of course, finding and fixing the real problem would be better.

1 Like

What does it mean to loose-route (;lr) when you aren’t going to include the Route header (;hide)?

;lr is probably meaningless with ;hide, but I tried the combination thinking that if ;hide just hides something, then I had better also include ;lr to avoid butchering the URI. It did what the OP asked for, so I stopped there.


This makes the Route header disappear, but doesn’t obviously fix the certificate error. May be it’s working with TCP.

Yes. As long as Asterisk isn’t fixed, it’s better or the only way, to do it via DNS manipulation and checking logfile of Asterisk for problems and accordingly changing DNS entries after unregistering the trunks. Finally reRegister to the new server.

As long as you don’t mind regarding availability, you may try the easy “Outbound proxy” - workaround (when not using TLS). This means, you’re not just unsecure (missing encryption), but also have reduced availability. From the Deutsche Telekom AllIP perspective, I can say, that the last 2 years those 3 servers (they are localized - others most probably see different servers) here never changed and had no outage at all - but that doesn’t say anything. Could be changed tomorrow.

I’m curious what the expected fix would be. It sounds like a stalemate. The provider blocks many registration attempts to one of its proxies for DDoS protection, so Asterisk uses the next proxy in the SRV. Both sides are doing what they should be doing.

Quoting myself:

That may not be desired behavior for everyone. Perhaps if you initiated a feature request for Asterisk it could be an optional parameter.

Yes, that’s true - an optional parameter would be absolutely fine. George Joseph does know about the problem since more than a year.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.