Jump to content
Vodia PBX forum
HighCtenor

Deutsche Telekom

Recommended Posts

Hi,

I'm back again with a new issue since today at 02:38 am.

TRUNKs setup completely unchanged, but no REGISTRATION since tonight:

TRUN:	Registration on trunk 4 (03********) failed with code 408. Retry in 60 seconds

It's seems there is no DNS resolving for "tel.t-online.de" in the "Proxy Address" to "sip:tel.t-online.de"  since my pcap shows not a single packet for Telekom SIP or destination IP 217.0.128.132 or .133 !

Vodia is running in ver. 59.0 (FreeBSD) and here is the DNS answer from host system itself:

dig tel.t-online.de

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

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

;; ANSWER SECTION:
tel.t-online.de.	3600	IN	A	217.0.128.132

;; Query time: 119 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 10 20:47:17 CEST 2018
;; MSG SIZE  rcvd: 60

Once more: It helps to set the "Proxy address" to "sip:217.0.128.132" for the trunk, but isn't really nice.

Flow Sequence in this case:

sip.jpg

Any ideas or hints for me?

Share this post


Link to post
Share on other sites

Try using host instead of dig, there you can also specify the type (e.g. host -t SRV). There were several outages last week on our VoIP phone in Germany (PBX not involved) where the phone would not register. Maybe this is just because too many people are on vacation in Deutsche Telekom right now... Hopefully nothing has changed in the setup on their side!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

What is strange:

When I change the "Proxy address" from "sip:tel.t-tonline.de" to "sip:217.0.128.132" the awaited packets with string "tel.t-online.de" in details present, like the first DNS NAPTR request:

 

NAPTR.jpg

Share this post


Link to post
Share on other sites

Did not find any hints...

I think the PBX is consulting anything/itself before consulting the operating system.

No idea so far.

Share this post


Link to post
Share on other sites

 

On 7/11/2018 at 4:00 PM, Vodia PBX said:

Try using host instead of dig, there you can also specify the type (e.g. host -t SRV). There were several outages last week on our VoIP phone in Germany (PBX not involved) where the phone would not register. Maybe this is just because too many people are on vacation in Deutsche Telekom right now... Hopefully nothing has changed in the setup on their side!

It seems Vodia in vacation mode too... ;-) Come on, lets debug again!

Service Ticket created at DTAG additionally.

Share this post


Link to post
Share on other sites

No just watching the soccer world sup LoL... The question is if this is always not working now or on/off. If it is permanent it would be interesting to see what is in the DNS cache of the PBX (web interface) and if this makes any sense. If this is on/off there must be something else, maybe even a unstable Ethernet connector or something like that. 

Share this post


Link to post
Share on other sites

It is permanent since 4 days.

DNS Cache:

Type 	Address 	Content 	TTL
A	d-eps-608.edns.t-ipnet.de	217.0.3.228	55:28
A	h2-eps-608.edns.t-ipnet.de	217.0.3.244	55:28
A	proxy.dus.net	83.125.8.71	01:28
A	proxy.live.sipgate.de	217.10.68.147	21:08:48
A	s-eps-608.edns.t-ipnet.de	217.0.20.212	55:28
A	sip.iptel.org	212.79.111.155	55:28
A	sipgate.de	217.10.79.9	02:55:28
AAAA	d-eps-608.edns.t-ipnet.de		25:28
AAAA	h2-eps-608.edns.t-ipnet.de		25:28
AAAA	proxy.dus.net		55:28
AAAA	proxy.live.sipgate.de	[2001:ab7::2]	21:08:48
AAAA	s-eps-608.edns.t-ipnet.de		25:28
AAAA	sip.iptel.org		02:46:08
AAAA	sipgate.de	[2001:ab7::4]	02:55:28
NAPTR	proxy.dus.net	0 50 s SIP+D2U - _sip._udp.proxy.dus.net 	01:28
NAPTR	sip.iptel.org		02:46:08
NAPTR	tel.t-online.de	30 0 s SIP+D2T - _sip._tcp.tel.t-online.de 20 0 s SIP+D2U - _sip._udp.tel.t-online.de 10 0 s SIPS+D2T - _sips._tcp.tel.t-online.de 	01:55:28
SRV	_sip._tcp.sip.iptel.org		02:46:08
SRV	_sip._tls.sip.iptel.org		02:46:08
SRV	_sip._udp.proxy.dus.net	0 0 proxy.dus.net 5060 	01:28
SRV	_sip._udp.sip.iptel.org		02:46:08
SRV	_sips._tcp.sip.iptel.org		02:46:08
SRV	_sips._tcp.tel.t-online.de	30 0 h2-eps-608.edns.t-ipnet.de 5061 20 0 d-eps-608.edns.t-ipnet.de 5061 10 0 s-eps-608.edns.t-ipnet.de 5061 	55:28

 

Share this post


Link to post
Share on other sites

Maybe a simple TLS problem? Does your PBX trust "T-TeleSec GlobalRoot Class 2"? This is the Root CA that was used to sign the connection to "h2-eps-608.edns.t-ipnet.de".

Share this post


Link to post
Share on other sites
On 7/12/2018 at 3:48 PM, Bronko said:

Service Ticket created at DTAG additionally.

Nearly closed, no technical assistance from DTAG. No once know how to escalate the SR.

Share this post


Link to post
Share on other sites

If this is a certificate related topic, try turning TLS log level to 9 then there should be a message that makes this clear.

Share this post


Link to post
Share on other sites

Well that is not good... IMHO it should all end up at tls:217.0.3.228:5061 or tls:217.0.3.244:5061. Maybe you also need to turn the SIP logging on, so that we can see how it steps through the DNS records. You are on a recent version, right?

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

×