Bronko
Members-
Posts
65 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by Bronko
-
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:
-
Do you have an answer here?
-
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!
-
Cool, six years old: [Resolved] How to Force SIP over UDP I have to learn to use the all-knowing, all-seeing Trash Heap! (May be the DTAG is playing currently with SIP-over-TLS...?)
-
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?
-
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?
-
Solved, next post.
-
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.
-
For sure....?!? I have masked out my IP for privacy, but I'm DTAG costumer since 20 years, believe me ;-) Let's debug!
-
What do you mean?
-
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?
-
Nope, I'm on ver. 59.0 (FreeBSD, see above) due to: FreeBSD: 59.0 -> 60.0, libstdc++.so.6 Fehler Once more, as a DTAG end user we are using nonTLS Trunks, isn't so? "It helps to set the "Proxy address" to "sip:217.0.128.132" for the trunk, but isn't really nice." (issue discription) Flow Sequence in this case:
-
Not a single message at log level 9 for TLS!
-
Nearly closed, no technical assistance from DTAG. No once know how to escalate the SR.
-
No, wasn't in there. To add T-TeleSec GlobalRoot Class 2 as "Trusted Root CA for server authentication" doesn't changed the behavior. As DTAG end user we are using TLS Trunks...?
-
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
-
It seems Vodia in vacation mode too... ;-) Come on, lets debug again! Service Ticket created at DTAG additionally.
-
Did not find any hints... I think the PBX is consulting anything/itself before consulting the operating system. No idea so far.
-
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:
-
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?
-
Forget to mention, the rest of Trunks for different providers are working as before...
-
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: Any ideas or hints for me?
-
Ich bin auf dem gleichen Release: [root@host]/root: freebsd-version 11.1-RELEASE-p6 Der Test mit der in diesem Release für mich einzig im Paket linux_base-c6 zu findenden libstdc++.so.6 zeigte: /usr/local/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/pbx/pbxctrl # strings libstdc++.so.6 |grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH Das Installationsscript der PBX kümmert sich um diese Abhängigkeit überhaupt nicht. Woher habt Ihr welche Version bezogen, damit ver. 60.0 läuft?
-
Hallo Vodia-Team, bis zur Version 59.0 läuft die PBX unter FreeBSD 11.1 mit einer vor längerer Zeit unter FreeBSD 10.0 statisch gelinkten libstdc++.so.6. Mit Update auf 60.0 erhalte ich nun folgenden Fehler: /usr/local/lib/libstdc++.so.6: version CXXABI_1.3.9 required by /usr/local/pbx/pbxctrl # strings libstdc++.so.6 |grep CXXABI CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_TM_1 CXXABI_1.3 CXXABI_1.3.2 CXXABI_1.3.6 CXXABI_1.3.1 CXXABI_1.3.5 CXXABI_1.3.4 CXXABI_TM_1 CXXABI_1.3.7 CXXABI_1.3.3 Welche Library läuft bei Ihnen? Bin vorerst wieder zurück auf 59.0
-
Problem solved! Thanks a lot!