Jump to content
Vodia PBX forum
HighCtenor

Deutsche Telekom

Recommended Posts

Oh, sorry. What I meant: for sure, my IP belongs to DTAG, because I'm a costumer of DTAG. And yes, this is a must to register.

Share this post


Link to post
Share on other sites
On 7/18/2018 at 6:33 PM, Bronko said:

Here we have the Log Entries for one of my DTAG Number with normal (currently failed Registration) "Proxy address": "tel.t-online.de"


[8] 18:23:52.446	TRUN:	Trunk 5: Preparing for re-registration
[8] 18:23:52.446	TRUN:	Trunk 5: sending discover message for tel.t-online.de
[8] 18:23:52.449	TRUN:	Trunk 5 (03????????) is associated with the following addresses: tls:217.0.20.212:5061 tls:217.0.3.228:5061 tls:217.0.3.244:5061
[8] 18:23:52.450	TRUN:	Trunk 03????????): Sending registration to sip:tel.t-online.de
...
[5] 18:24:24.451	TRUN:	Registration on trunk 5 (03????????) failed with code 408. Retry in 60 seconds

May be we don't have to use TLS here?

Since I doubted the TLS Trunk availability for DTAG private costumers I tried to extend "Proxy address"  by:

sip:tel.t-online.de:5060

sip:tel.t-online.de;transport=udp

Both is working fine:

[8] 0:19:09.003	TRUN:	Trunk 5: sending discover message for tel.t-online.de
[8] 0:19:09.162	TRUN:	Trunk 5 (03????????) is associated with the following addresses: udp:217.0.128.132:5060

Why the PBX was using TLS since July, 10 at 02:38 am?

Different NAPTR record in DNS of tel.t-online.de?

Share this post


Link to post
Share on other sites
On 7/11/2018 at 4:17 PM, Bronko said:

Yes... the time is typical for Deutsche Telekom to load new running_config in network devices.


$ dig -t NAPTR tel.t-online.de

; <<>> DiG 9.11.2-P1 <<>> -t NAPTR tel.t-online.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61953
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tel.t-online.de.		IN	NAPTR

;; ANSWER SECTION:
tel.t-online.de.	4425	IN	NAPTR	20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de.	4425	IN	NAPTR	10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de.	4425	IN	NAPTR	30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 11 16:19:24 CEST 2018
;; MSG SIZE  rcvd: 208

I'm currently on my investigation in wireshark, any special request?

Here we see _sips._tcp. have highest Priority (10), why the PBX don't fallback to next Prio _sip._udp. (20) or _sip._tcp. in the case of failure?

Share this post


Link to post
Share on other sites

Ehhhhhhhhhhhhhh so going back to UDP works for you? That would answer the question if your IP address works, but it would still make me wonder why TLS does not work. And if UDP works, maybe TCP also works (which is a lot more stable than UDP).

Share this post


Link to post
Share on other sites
On 7/20/2018 at 8:43 PM, Vodia PBX said:

Ehhhhhhhhhhhhhh so going back to UDP works for you? That would answer the question if your IP address works, but it would still make me wonder why TLS does not work. And if UDP works, maybe TCP also works (which is a lot more stable than UDP).

Sorry, once more: SIPS (5061) isn't available for private costumers on DTAG, but it seems they are playing currently on this feature.

"Proxy address:"

sip:tel.t-online.de;transport=tcp

is working too!

 

Share this post


Link to post
Share on other sites

 

On 7/20/2018 at 12:48 AM, Bronko said:

Here we see _sips._tcp. have highest Priority (10), why the PBX don't fallback to next Prio _sip._udp. (20) or _sip._tcp. in the case of failure?

Do you have an answer here?

Share this post


Link to post
Share on other sites

Aha I was not aware that private people cannot use TLS on DTAG... At plain sight I agree it would make sense to fail over. However the whole RFC 3262 area is very tricky; I would at this point say it is easier to explicitly specify the transport protocol.

Share this post


Link to post
Share on other sites

So, we had the issue that outgoing calls were not working for a few days. We would always get a "SIP/2.0 503 Service Unavailable" back. Incoming calls and registration worked fine.

I saw the tls:1.2.3.4 connections in the log and didn't think much of it ("well finally DTAG got their asses up and encrypted SIP"), though thanks to this thread I've found this to be the root cause of the problem. Changing the transport manually to either UDP or TCP solves the outgoing call problem 100 % of the time. Thanks for debugging this and sharing your findings!

Share this post


Link to post
Share on other sites
On 8/15/2018 at 12:22 PM, sfp0 said:

..Thanks for debugging this and sharing your findings!

You are welcome...

One additional comment for DTAG Trunk Setup:

Around the time of these issue (408) my extensions (phones: Gigasets, snom870) starts again to don't play a ringback tone for some  called numbers; some of these DTAG, too.

Over the years and for now I found these Ringback setup works as it should:

 

Screenshot from 2018-08-31 11-42-02.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×