Problem: Asterisk/dus.net - Registrierung verloren?

[ObelX]

Hallo Christian,

Die Multiserver-Konfiguration von Dusnet gehe ich jetzt mit 'dig' und 'crontab' an. Der Hinweis zu 'dig' in diesem thread hat mich animiert. Ich poste meine Lösung hier. Vielleicht hilft es dem Einen oder Anderen. Es würde mich freuen.

Interessante Lösung, aber natürlich ein absoluter Work-arround...

Bleibt die Frage, warum dus.net meint, man bräuchte dies alles bei der 1.6er nicht mehr. Ich habe vorgestern den von mir geposteten Server meiner Konfiguration hinzugefügt und seitdem alle Anrufe erhalten, zumindest soweit ich weiß (ich hatte nicht die Geduld alle Logeinträge durchzugehen).

Kann man zu dieser zentralen Frage nicht mal ein Statement mit konkretem Beispiel von dus.net erhalten? Die entsprechende Hilfeseite ist ja offenbar von 2008 und die dort genannten Server-Einträge sind somit nicht mehr up-to-date. Also wäre hier evtl. eine Überarbeitung mit Klarstellung angesagt.

Wenn das Wetter wieder schlechter ist, werde ich evtl. noch etwas weiter testen, aber solange mein Setup läuft, ist meine Motivation da natürlich begrenzt.

In jedem Fall könnte Dein Code für alle User des "Mehr-Server-Setups" eine verlässliche Lösung sein, die meine ursprüngliche Frage nach der Kontrolle beantwortet, tnx dafür.


Gruß ObelX

 

[Christian_]

Die Problematik besteht genau so seit einigen Jahren. Eine allgemeine Lösung scheint schwierig zu sein, da die diversen Voipanbieter unterschiedliche Setups und unterschiedliche DNS Informationen verwenden. Vielleicht hilft mein Script den Asterisk Entwicklern und sie setzen den Grundgedanken in C-Code um.

Hier eine weiterentwickelte Version von meinem Script.

Ergänzungen:
1. Validierung der gefundenen Server. Bei Fehlern wird 'sip.conf' nicht verändert und nicht nachgeladen.
2. Wenn das Server-Setup unverändert ist, dann wird 'sip.conf' nicht nachgeladen.

#! /bin/sh
# sip_dusnet.sh
# Version: 0.2
# Date: 2010-05-23 15:10
# Author: Christian_ , www.ip-phone-forum.de

SERVERS=`dig voip.dus.net +short| sort -n`

# Verify the response of 'dig'. Do not change the asterisk setup in case of
# network trouble.
for DUSNETSERVER in ${SERVERS} ; do
  HOSTREPLY=`host "${DUSNETSERVER}"`
  [ "$?" -ne 0 ] && {
    echo "'dig' returned an invalid server: '${DUSNETSERVER}'"
    echo "---snip 'dig voip.dus.net +short| sort -n' ---"
    echo ${SERVERS}
    echo ---snip---
    echo
    echo "'host' failed on: '${DUSNETSERVER}'"
    echo "---snip 'host ${DUSNETSERVER}' ---"
    echo ${HOSTREPLY}
    echo ---snip---
    echo
    echo Not reloading sip.conf!
    echo exiting...
    exit 0
    }
done


# Rewriting '/etc/asterisk/sip_dusnet.conf'
COUNT=0
for DUSNETSERVER in ${SERVERS} ; do
  let COUNT++
  echo
  echo "[dus.net_in_server${COUNT}]"
  echo "type=peer"
  echo "fromdomain=${DUSNETSERVER}"
  echo "host=${DUSNETSERVER}"
  echo "insecure=port,invite
  echo "context=xxxx"
done \
> /etc/asterisk/sip_dusnet.conf

# Tell me if Dusnet uses new servers.
/usr/bin/diff -ua /etc/asterisk/sip_dusnet.conf /etc/asterisk/sip_dusnet.conf__2010-05-18__

# If nothing changed, there is no need to reload sip.conf.
[ "$?" -eq 0 ] && exit 0

# If there are changes, please show as well the new server names.
echo
echo "Current Dusnet servers:"
for DUSNETSERVER in ${SERVERS} ; do
  host "${DUSNETSERVER}"
done

/usr/sbin/asterisk -rx "sip reload"

Viele Grüße, Christian

 

[dfroe]

Hallo,
ich persönlich glaube nicht, dass dieser Ansatz "the way to go" sein sollte. Für mich ist diese ganze DNS-Abfrage-Geschichte nämlich immer noch ein ziemlicher quick&dirty Workaround.
Da muss man sich z.B. nur Sipgate anschauen. Da brauche ich keinerlei DNS-Krücken, es läuft immer über eine einzige IP. Ich vermute stark, dass auch die mehrere SIP-Server im Hintergrund stehen haben (um die Last zu bewältigen), aber nach außen hin geht alles über eine einzige IP an den Kunden. Hinter dieser einen IP steckt womöglich ein hochverfügbarer Reverse-Proxy, der die Verbindungen dann intern auf die einzelnen SIP-Server verteilt. Der Konfigurationsaufwand (und auch die Investitionskosten) ist seitens des Providers natürlich deutlich höher, als bei dem einfachen Round-Robin-DNS. Dafür skaliert diese Variante aus Kundensicht quasi beliebig.

Jedenfalls sollte meiner Meinung nach eher dus.net sich Gedanken machen, in Zukunft nicht doch von diesem Round-Robin-DNS weg zu kommen, und eine saubere Infrastruktur z.B. über einen Load-Balancing Reverse-Proxy aufzubauen.

Wenn irgendwelche Gründe gegen einen solchen Reverse-Proxy und für die DNS-Variante sprechen, würden mich die natürlich auch interessieren.

 

[jussuf]

habt' Ihr denn noch Probleme mit der Registrierung ? Seit dem 22.05. läuft's bei mir einwandfrei, ich meine sogar besser als vorher.

De-Registrierungen seh' ich gar keine mehr - und die hatte ich vorher immer mal zwischendurch, wenn auch nur für 'ne Minute oder so ... und den Server-Reset um 05.00h scheint's auch nicht mehr zu geben.

 

[Tippfehler]

Ich melde mich seit einiger Zeit mit drei Accounts an drei verschiedenen dus.net-Servern direkt an. (Den problematischen Server lasse ich aus.) Seit der Änderung hatte ich keine Probleme mehr. Ich werde es auch vorerst so lassen.

 

[dfroe]

Seit alle vier Cluster-Server wieder online sind, tut bei mir eigentlich wieder alles so wie es soll. Wobei ich sagen muss, dass mir auch vor diesem Ausfall keine größeren Probleme aufgefallen sind. Mein Telefonvolumen ist nun nicht gerade sehr hoch, aber es hatte sich nie jemand beschwert, mich nicht erreicht zu haben. Kleine De-Regstrierungen sowie die Server-Rests um 5 Uhr kann ich nicht beurteilen, da ich diese nicht geloggt habe, und wohl zufällig zu dieser Zeit mich auch niemand anrufen wollte.
Mein Setup läuft mittlerweile so, dass ich meinen vier SIP-Accounts explizit jeweils einen festen der vier dus.net Server zugewiesen habe. Ich habe in den letzten Tagen bei keinem der vier Probleme beobachtet.

 

[Christian_]

Die Telefonie via Dusnet funktioniert bei mir zur Zeit auch wieder zufriedenstellend. Die Meldung 'Peer 0123..' is now UNREACHABLE!' sehe ich täglich nach wie vor um 5:00 Uhr und um 0:30 Uhr. Das Thema dieses Threads hat sich für mich damit erledigt und ich würde sagen, Problem gelöst.

 

[Christian_]

Über das DNS-Problem von Asterisk mit der Multi-Server-Konfiguration von Dusnet denke ich, daß es sich ein wenig vom Thema in diesem Thread entfernt hat. Dennoch hier mein Antwort, ich habe eure Beiträge gerne gelesen.

Die Netzwerktechnik im Hintergrund kann ich schlecht beurteilen. Ich weiß nicht ob Sipgate mehr oder weniger Telefonate als Dusnet zu bewältigen hat. Ich weiß auch nicht ob der Ansatz von Dusnet als Round-Robin-DNS ungünstig oder sogar nicht regelkonform ist. Ich gehe davon aus, daß der Ansatz von Dusnet regelkonform ist und unter Fachleuten auch Befürworter findet.

Das Kernproblem sehe ich darin, daß Asterisk DNS-Informationen teilweise ignoriert und zudem nicht aktualisiert. Dusnet bringt Server an den Start, publiziert diese per DNS und Asterisk nimmt nun aber nur den ersten zur Kenntnis. Damit das Telefonieren überhaupt möglich wird müssen nun noch helios.dus.net etc., also die DNS-Informationen, die zuvor ignoriert wurden, in der Asterisk-Konfiguration für eingehende Telefonate eingetragen werden. Bei dieser Vorgehensweise fallen auch alle neuen Server unter den Tisch, die Dusnet nach dem Laden der 'sip.conf' an den Start bringt. Das wird alles von Hand seit Jahren praktiziert und ist akzeptiert. Ich möchte von diesem Huddel unabhängig werden, der im günstigsten Fall beim Laden der 'sip.conf' eine aktuelle Netzwerksituation abbildet.

Allen anderen SIP-Telefonen und Adaptern genügen die DNS-Informationen. Vielleicht irre ich in diesem Punkt und die SIP-Telefone und Adapter kommen auch ins straucheln wenn Dusnet den nächsten Server ins Netz stellt.

Ich gehe nicht davon aus, daß Dusnet Geld in die Hand nimmt um auch für Asterisk einen störungsfreien Betrieb zu ermöglichen. Ich wünsche mir auch ein Asterisk welches sich mit den allgemeinen Voip-Provider-Informationen hinreichend ohne Zusatzscripte für alle Provider konfigurieren läßt.

 

[FrankIT]

Das Kernproblem sehe ich darin, daß Asterisk DNS-Informationen teilweise ignoriert und zudem nicht aktualisiert. Dusnet bringt Server an den Start [...] Damit das Telefonieren überhaupt möglich wird müssen nun noch helios.dus.net etc. [...] in der Asterisk-Konfiguration für eingehende Telefonate eingetragen werden. Bei dieser Vorgehensweise fallen auch alle neuen Server unter den Tisch, die Dusnet nach dem Laden der 'sip.conf' an den Start bringt. Das wird alles von Hand seit Jahren praktiziert und ist akzeptiert. Ich möchte von diesem Huddel unabhängig werden, der im günstigsten Fall beim Laden der 'sip.conf' eine aktuelle Netzwerksituation abbildet.

Allen anderen SIP-Telefone und Adaptern genügen die DNS-Informationen. Vielleicht irre ich in diesem Punkt und die SIP-Telefone und Adapter kommen auch ins straucheln wenn Dusnet den nächsten Server ins Netz stellt.

Die ganze Fummelei mit den verschiedenen dus.net-Servern in der sip.conf braucht man eigentlich nur, wenn man ankommende Anrufe anhand der IP-Adresse unterscheiden möchte. SIP-Telefone und "Adapter" verzichten meistens darauf. Ihnen ist die IP-Adresse bei ankommenden Anrufen egal, und deshalb haben sie damit auch keine Probleme.

Die gängige sip.conf für dus.net sieht ungefähr so aus:

[general]
register => 0003872xxxxx:[I]SIP-Passwort[/I]@proxy.dus.net/0003872xxxxx
...
[dusnet]
type=peer
context=dus-inbound
username=0003872xxxxx
secret=[I]SIP-Passwort[/I]
host=proxy.dus.net
fromdomain=dus.net
insecure=port,invite

[dusnet-in-talos]
type=peer
host=talos.dus.net
context=dus-inbound
insecure=port,invite

[dusnet-in-zelos]
host=zelos.dus.net
...
[dusnet-in-helios]
host=helios.dus.net
...
[dusnet-in-taris]
host=taris.dus.net
...

Ankommende Anrufe, die über dus.net kommen, werden anhand der IP-Adresse einem der dus.net-Peers zugeordnet und dadurch unmittelbar in den Kontext dus-inbound im Dialplan geschickt.

Im Grunde kann man sich die verschiedenen Peers aber sparen und alle ankommende Anrufe direkt einem globalen Kontext zuordnen:

[general]
context=sip-inbound
register => 0003872xxxxx:[I]SIP-Passwort[/I]@proxy.dus.net/0003872xxxxx
...
[dusnet]
type=peer
context=sip-inbound
username=0003872xxxxx
secret=[I]SIP-Passwort[/I]
host=proxy.dus.net
fromdomain=dus.net
insecure=port,invite

Möchte man trotzdem unterscheiden, ob ein Anruf über dus.net herein kommt oder über einen anderen Weg, dann muss man das im Dialplan anhand der Extension machen. Dazu könnte man z.B. einen allgemeinen Inbound-Kontext in der folgenden Art verwenden (AEL-Syntax):

//  Standardkontext fuer alle ankommenden SIP-Anrufe
//
context sip-inbound {
        0003872xxxxx => {
                jump ${EXTEN}@dus-inbound;
        };
        9876543 => {
                jump ${EXTEN}@sipgate-inbound;
        };
        ...
        _X. => {
                jump ${EXTEN}@inbound-from-unknown-source;
        };
};

 

[Christian_]

Die ganze Fummelei mit den verschiedenen dus.net-Servern in der sip.conf braucht man eigentlich nur, wenn man ankommende Anrufe anhand der IP-Adresse unterscheiden möchte. SIP-Telefone und "Adapter" verzichten meistens darauf. Ihnen ist die IP-Adresse bei ankommenden Anrufen egal, und deshalb haben sie damit auch keine Probleme.

Das hört sich logisch an. Ich denke Du hast hier recht. Damit sehe ich in der IP-abhängigen Rufannahme eine zusätzliche Funktion von Asterisk. Es ist in der Tat so, daß mein default context fast leer ist um Problemen wie [post=1507697] hier [/post] vorzubeugen. Diesen Zustand möchte ich im Moment auch nicht ändern, denke darüber aber noch einmal nach.

Besteht denn die Möglichkeit in der sip.conf unter [dusnet-in...] statt einer IP ein subnet anzugeben?

[dusnet-in-talos]
type=peer
;host=talos.dus.net
host=83.125.8.0/24      ; ist so etwas möglich?
context=dus-inbound
insecure=port,invite

 

[sparkie]

Im Grunde kann man sich die verschiedenen Peers aber sparen und alle ankommende Anrufe direkt einem globalen Kontext zuordnen:

die Idee ist zwar gut, funktioniert aber nur, wenn man dabei keine Probleme mit dem lokalen Firewall bekommt.

Die gezeigte Methode haelt naemlich immer nur einen einzigen (statt alle derzeit 4) der dus.net Server in den conntrack Tables aktiv, wodurch Anrufe verloren gehen koennen.

Ich muss bei mir also explizit alle Einzelserver nennen, damit ich sie einzeln mit einem 'qualify' versehen kann. Auf diese Weise sind bei mir in den '/proc/net/ip_conntrack' Eintraegen alle Server mit einem Timeout von minimal 120s enthalten. Klappt jetzt ohne Probleme hier.

Das adressiert natuerlich nicht die Situaton, wenn dus.net mal wieder Aenderungen an der Proxykonfiguration vornimmt

Meine sip.conf:

[general]
context=sip-in
bindport=5060
bindaddr=0.0.0.0
qualify=no
disallow=all
allow=alaw
allow=ulaw
allow=g729
allow=gsm
allow=slinear
srvlookup=yes

register => 00038xxxxxxx:[email protected]/00038xxxxxxx

[dusnet-out]
type=peer
defaultuser=00038xxxxxxx
fromuser=00038xxxxxxx
fromdomain=dus.net
secret=12345678
host=proxy.dus.net
canreinvite=no
dtmfmode=auto
relaxdtmf=yes

[dus.net_in_server1] 
type=peer
fromdomain=talos.dus.net
host=talos.dus.net
insecure=port,invite
qualify=yes
qualifyfreq=25

[dus.net_in_server2] 
type=peer
fromdomain=zelos.dus.net
host=zelos.dus.net
insecure=port,invite
qualify=yes
qualifyfreq=25

[dus.net_in_server3] 
type=peer
fromdomain=helios.dus.net
host=helios.dus.net
insecure=port,invite
qualify=yes
qualifyfreq=25

[dus.net_in_server4] 
type=peer
fromdomain=taris.dus.net
host=taris.dus.net
insecure=port,invite
qualify=yes
qualifyfreq=25

Anmerkung:
da der Timeout von 'nf_conntrack_udp_timeout' bei mir auf dem Router derzeit auf 30s steht habe ich die 'qualifyfreq' auf 25s gestellt, um die Verbindung sicher zu halten. Vielleicht unschoen, aber man gewoehnt sich ja an allem, um diese etwas abstruse dus.net Cluster Konfiguration zum Funktionieren zu bringen :mrgreen:

- sparkie