Telekom Germany SIP Trunk SRV Records

siptrunk
pjsip
configuration
Tags: #<Tag:0x00007f70296607b0> #<Tag:0x00007f70296604e0> #<Tag:0x00007f7029660170>

(Nick Heal) #1

Hey guys,

we use the free version of FreePBX for the phones in our home.
And after a couple of start problems with the setup, we are very happy with it.
Our internet provider (Telekom Germany) has VOIP as part of the internet package, which is why we use them as SIP Trunk.

Currently, the Telekom is contacting customers of which they think, that they are still using the DNS A-Record for the SIP trunks.
They write, that this will be discontinued and removed, and they instruct to configure the phones, routers etc. to instead use DNS SRV.

We got such a letter and are a little afraid that the phones will stop working in a couple of weeks.
We thus tried to find that DNS option in the Webinterface, and also saw the Wiki entry on it - but unfortunately, we were not able to find the appropriate settings.
Is this something that is not supported with the free version, or will this just continue to work when they delete the A-records?


(Dirk2358) #2

First of all, you have to use pjsip. You may have a look here as an example how to configure it.


(Namerp) #3

we got the same letter for the Telekom sip connection, but not for the Telekom trunk connection we also have (different DSL connection)

basically the same machines with the same pjsip setup
on both machines are the srv records working from the shell

I already contacted the Telekom support + some engineer but they had no idea how these letters are generated and how to test if it is correct or not. Maybe someone has a good idea how to verify the working state.


(Dirk2358) #4

It’s pretty easy to check if it’s working as desired. Just trace your DNS traffic until you see queries like this (assuming it is not encrypted):

tcpdump -npi any udp port 53

This should reveal queries like this (for tls here):

05:20:00.948315 IP a.b.c.d.44707 > e.f.g.h.domain: 57655+ [1au] NAPTR? tel.t-online.de. (44)
05:20:00.948518 IP a.b.c.d.60916 > e.f.g.h.domain: 16895+ [1au] SRV? _sips._tcp.tel.t-online.de. (55)

(Nick Heal) #5

Thanks for the response!

If I understood the link from you correctly, this basically means that Asterisk does not support the SRV setup from Telekom yet, and one should do the resolution to an IP address manually and enter it permanently, right?


(Jared Busch) #6

Asterisk absolutely supports DNS SRV records. Has for a long time. As noted use PJSIP for your trunk type and things should just work.

You can manually to a SRV lookup to get the IP that are being used and then block them one at a time in a firewall rule to see FreePBX route to the next one.


(Dirk2358) #7

Yes. You got it right. It’s best to provide a complete RPZ (as it is called by Bind) and provide Asterisk a reduced answer to the DNS lookups. This could look like this (a script periodically creates the following code):

server $yourBindIP
zone rpz-tonline
update delete tel.t-online.de.rpz-tonline.
update delete _sips._tcp.tel.t-online.de.rpz-tonline.
update delete _sip._tcp.tel.t-online.de.rpz-tonline.
update add tel.t-online.de.rpz-tonline. 60      NAPTR   10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
update add tel.t-online.de.rpz-tonline. 60      NAPTR   30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
update add _sips._tcp.tel.t-online.de.rpz-tonline.      60 SRV  10 0 5061 s-eps-110.edns.t-ipnet.de.
update add _sip._tcp.tel.t-online.de.rpz-tonline.       60 SRV  10 0 5060 s-epp-110.edns.t-ipnet.de.
send

which can be send to Bind with nsupdate.

It results in

$ORIGIN .
$TTL 660        ; 11 minutes
rpz-tonline             IN SOA  localhost. root.localhost. (
                                51         ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      localhost.
$ORIGIN rpz-tonline.
$TTL 60 ; 1 minute
tel.t-online.de         NAPTR   30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
                        NAPTR   10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
$ORIGIN _tcp.tel.t-online.de.rpz-tonline.
_sip                    SRV     10 0 5060 s-epp-110.edns.t-ipnet.de.
_sips                   SRV     10 0 5061 s-eps-110.edns.t-ipnet.de.

named.conf

options {
...
        response-policy {
            zone "rpz-tonline";
        };
}
zone "rpz-tonline" {
        type master;
        file "/var/named/rpz-tonline-override";
        allow-query { any; };
        allow-transfer { any; };
        allow-update { any; };
};

The final destination servers (*.t-ipnet.de) are resolved directly again via DNS (they provide just one answer, which is fine). You have to take care if one of the SRV results above you’re using changes / disappears. If this happens, you have to unregister, update the DNS and register again. To be sure to not break any ongoing call, you have to wait until no call is active (that can be done in the script, too, via a CLI call checking for running calls to the trunk).

@sorvani: German Telekom provides 3 different servers (I think these are completely different and solely acting clusters) and expects that you register to one of them and all further requests must go exactly to this server you initially registered to - requests to any other server / cluster is denied (they don’t know you). Asterisk can’t handle this at the moment.
There are situations where a registration fails (mostly on startup - if you register more than one number). Asterisk then switches to the second server (and proceeds) and afterwards uses for an outgoing call (or options-request) the first server again. All those requests are failing because they get access denied, because you’re registered to another cluster.