Jump to content

Bronko

Members
  • Posts

    65
  • Joined

  • Last visited

Posts posted by Bronko

  1. 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

  2.  

    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?

  3. 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!

     

  4. 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?

  5. 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?

  6. On 7/10/2018 at 9:36 PM, Bronko said:

     

    
    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

     

     

    What do you mean?

  7. 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?

  8. 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

     

  9.  

    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.

  10. 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

  11. 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?

  12. 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?

  13. 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?

  14. 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

×
×
  • Create New...