Telekom Germany SIP Trunk SRV Records and pjsip

Hello, there was an old thread bout this topic:

Now I need to pull this up again, as Telekom now has deleted its A-Record for tel.t-online.de so that the SRV frecords must be used. As I understand this old thread, I need to use one of the three names returned in the SRV lookup as the “SIP server” in the pjsip dialog and leave the port part empty? However, I always get
res_pjsip_outbound_registration.c: tk-XYXZ-0123456789: 403 Forbidden fatal response received from ‘sip:h2-epp-110.edns.t-ipnet.de’ on registration attempt to ‘sip:[email protected]

Maybe I have not understood correctly why I need to setup an own zone for this. We are not using BIND, so I cannot apply this recipe directly. Am I righth that we need to tell the DNS server to always return the same SRV answer if a requst goes to " _sip._udp.tel.t-online.de" and that I need to enter " _sip._udp.tel.t-online.de" into the PJSIP dialog??

@isol Were you able to solve the problem? Is the solution with SRV not working for you?

No - you always have to provide the correct and recommended addresses in FreePBX configuration (don’t use those final names - those like h2-epp-110.edns.t-ipnet.de e.g. won’t work) - but you have to take care, that asterisk doesn’t get more than one server from the DNS lookup - that’s why you need the RPZ zone in bind. It’s to workaround the problem, that asterisk can’t handle the fact, that all subsequent requests must go to the destination you are registered to - even if there are more than one servers returned by the original DNS answer. Goal of the RPZ zone is to hide 2 of the 3 servers presented by Telekom to Asterisk.
Configuration has to be done like this. It’s working perfectly!

You may test running w/o the RPZ workaround. It most probably will work most of the time - mainly if you are registering just one number. As soon as I’m registering more than one number, I’m sometimes facing the problem, that the second or third registration fails (at the first try on startup - it times out - I think there are some security rules active on Telekom side preventing DOS attacks - maybe they prefer to see each number on a different server?) and therefore asterisk uses the second server (which proceeds). If you’re doing later on an outbound call using this trunk, asterisk will use the primary server of the list again - which will horribly fail, because the first server doesn’t know you … .

Edit:
How to implement and test the basic configuration?
At first forget about RPZ and DNS. Just configure it as described here - don’t use UDP as SIP protocol! Use TCP! After the first start of asterisk check the registration like this:

asterisk -x "pjsip show registrations"

If you can see, that your trunks to Telekom are registered, check, if they are all using the same destination:

netstat -tpn | grep asterisk | grep 217.0

This assumes, that your asterisk process runs as user asterisk. Grep for another user if your asterisk process uses another user!
All destination servers listed here must be the same. It must be the first server (on base of priority - lowest number is highest priority) of the list you get by

dig +noall +answer _sips._tcp.tel.t-online.de SRV
_sips._tcp.tel.t-online.de. 3600 IN     SRV     20 0 5061 b-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 3600 IN     SRV     30 0 5061 h2-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 3600 IN     SRV     10 0 5061 d-eps-110.edns.t-ipnet.de.

Based on this example (it’s using TLS, which should be default nowadays), all open connects must go to this server: d-eps-110.edns.t-ipnet.de (because it has the highest priority 10 (lowest value!))

At this point, placing calls or receiving calls should work most of the time w/o any problem. If you are facing any problems here, you have another problem with your configuration or routing.

EDIT 2:
Another way instead of using a bind RPZ to reduce the server list to one server, could probably be to map all the servers you get by the above dig to the same IP address of of one of the servers in the list in /etc/hosts - but I didn’t test it - don’t know, if it really works. If you’re doing this dynamically, this would be a “solution”, too.

That’s exactly the goal of SRV records. Why are you defeating the purpose? If the provider is broken you should bring it up with them. An alternative to all this if you must implement a workaround would be to specify one of the SRV proxies as your outbound proxy. But it’s so hacky.

Whilst that is true for chan_sip, chan_pjsip honors properly all SRV records returned

1 Like

If it’s working with outbound proxy? Why not - I can’t say.

Why do you think the provider is broken? Because they present 3 completely independent working clusters which asterisk can’t handle? Asterisk isn’t the middle of the world - other clients are able to handle it correctly.

According to the SRV record you posted, there are three proxies with increasing priority. I don’t know why you are saying Asterisk can’t handle it. Asterisk will work with the highest priority proxy unless it is unavailable.

I do agree with this, but likewise, Asterisk works fine with other providers who publish SRV records, so it is not obvious that Asterisk is at fault.

We’re talking about pjsip - not chan_sip.

Please inform yourself about the actual problem here by carefully reading what I wrote above. I won’t explain the same facts again and again … .

Please carefully read what I wrote here and you will know the problem.

In my case using sketel

and using flowroute

both work as advertised

So you are sending multiple distinct registration requests from the same PBX to the same provider, and they are blocking some of your requests due to rate limiting?

Then don’t send a bunch of duplicate registrations…

We are talking here about Deutsche Telekom, you most probably don’t know anything of. Therefore it’s completely useless if you’re presenting other providers … . Carefully read this and you might hopefully understand the problem.

First: it’s asterisk, which sends them - not I. Second: These are no duplicates! These are different registrations for different numbers to the same destination.

I say “duplicate” because they are coming from the same host. To a firewall or simple rate-limiting solution, it would be considered duplicate.

Yes, that’s true. But the key problem is: Asterisk can’t assure, that all subsequent requests must always go to the same destination as it initially registered to. Same problem could happen if the priority is changed in the SRV records some time later after registration. At this point, Asterisk would have to register to the new destination as soon as no more calls are active to this trunk.

Edit:
That’s what I’m doing with my script providing the RPZ (monitoring any change) and checking at the same time for any active call to the trunks before starting reRegistration to the new server after changing the RPZ.

To answer @AdFun7911 's question: not yet. We have managed to get NAPTR and SRV record serving going with dnsmasq ( we do not use bind) and the nameserver lookups seem promising:
15:12:13.935296 IP 127.0.0.1.52816 > 127.0.0.1.53: 63005+ SRV? _sip._tcp.tel.t-online.de. (43)
15:12:13.935600 IP 127.0.0.1.53 > 127.0.0.1.52816: 63005* 1/0/1 SRV h-epp-100.edns.t-ipnet.de.:5060 10 0 (104)
15:12:13.935794 IP 127.0.0.1.46217 > 127.0.0.1.53: 1578+ A? h-epp-100.edns.t-ipnet.de. (43)
15:12:13.935808 IP 127.0.0.1.46217 > 127.0.0.1.53: 54585+ AAAA? h-epp-100.edns.t-ipnet.de. (43)
15:12:13.936095 IP 127.0.0.1.53 > 127.0.0.1.46217: 1578 1/0/0 A 217.0.21.2 (59)

i.e. the pbx always gets the “h-epp-100” server. However, we do not see any auth requests after this DNS request and the asterisk log says
" WARNING[15527] res_pjsip_outbound_registration.c: tk-ABC-0123456789: No response received from ‘sip:tel.t-online.de’ on registration attempt to ‘sip:[email protected]tel.t-online.de’"
. Some piece seems to be missing - it gets the IP of the server (217.0.21.2) but then never queries that server, according to tcpdump. I will continue to investigate, probably early next week.

Have you ever thought of changing your SIP-trunk provider. There are many private companies out there in Germany/Austria, which might do a better job than Deutsche Telekom.

EDIT: By the way…you can still use SiP-trunks instead of pjsip too…If this helps…

@isol Could you provide us with a screenshot of the pjsip trunk settings (general and advanced) with removed sensitive information?

Well, pjsip says, that there has been a timeout. Are you using NAT? Did you correctly set your NAT rules in the firewall for TCP/5060? tcpdump is attached to the correct device?

Please add additional log for pjsip:
Add the following line to logger_logfiles_custom.conf:

pjsip.log => debug

This will add a new log file to /var/log/asterisk/pjsip.log, containing some more information about the transport and what’s happening.

BTW: Asterisk seems to be somewhat buggy regarding NAT (and not each SIP provider ignores the wrong requests). You may take a look here if you are facing any problems during REGISTRATION when on NAT.

This thread seems weird to me. There is no reason to use any customized DNS, host files or similar shenanigans.

Doing nothing special, pjsip registers ok to DT and both inbound and outbound calls mostly work.
However, something goes wrong that causes Asterisk to jump to other than the highest priority DT server. When this happens, some outbound calls fail because DT (unlike most providers) requires the caller to be registered to the same server to which the call is being sent.

There are (at least) two approaches to this problem. The simple one is to constrain registration to a specific server. This is easily done by setting (for example)
Outbound Proxy: sip:f-epp-110.edns.t-ipnet.de\;lr
The downside is a loss of robustness; if the specific server chosen is down or unreachable, all calls will fail.

Though more difficult, it is better to find out what is going wrong and fix it. I can’t believe that in spite of 19 posts in this thread, there is almost no meaningful diagnostic info.

That’s a good start, but we need to find out why. Possibilities include:

  1. Malformed REGISTER or response.
  2. Request or reply blocked by FreePBX firewall.
  3. Request or reply blocked or corrupted by hardware router/firewall.
  4. Request blocked by DT, presumably in response to ‘excessive’ or ‘erroneous’ requests.

To troubleshoot:

  1. Use pjsip logger.
  2. Use sngrep (or tcpdump).
  3. Capture traffic on WAN interface and/or use router’s debugging tools.
  4. Get documentation of limits from DT, or experiment with Expiration: 3600 and no qualify.
1 Like