(das soll es mal werden – also fleissig editieren :) )

Asterisk gibt es hier: http://www.asterisk.org. Informationen finden sich

• im Mailinglisten-Archiv
• auf VoIP-Info.org (englisch)
• im IRC auf irc.freenode.net in #asterisk
• in diesem oder diesem oder diesem deutschprachigen pdf.
• im IP-Phone-Forum
• natürlich auch hier :)

Einen PC, für einen einfachen Hausanschluss genügt schon ein altgedienter P1 mit 166MHz (der auch nebenher gerne andere Dinge wie DSL-Router, Firewall, Fileserver, … betreiben darf – vernünftig administriert passt das). Mehr Leistung ist natürlich nie verkehrt. Für eigenbau TK-Anlagen bieten sich stromsparende Boards mit ggf. lüfterloser CPU (VIA Epia etc.) an.
Als Betriebssystem kommt Linux (Distribution ist ziemlich egal) hinzu. Auch eine FreeBSD/MacOS X unterstützung wird entwickelt. Für Windows gibt es inzwischen auch eine „astwind“ genannte Version, auf Unterstützung von Telefonie-Hardware muss hier aber verzichtet werden.
Weiterhin sind natürlich eine ausreichend dimensionierte Internetverbindung empfehlenswert (wie für VoIP üblich) und wenn man zur bisherigen ISDN-Welt Verbindung aufnehmen will, eine ISDN-Karte. Welche Karte geeignet ist, hängt vom Verwendungszweck ab, siehe unten.

Zuerst wird ein SIP-Benutzer benötigt, mit dem sich das Endgerät am Asterisk-Server anmelden kann. Dies wird in der sip.conf erledigt:

 [1234] 
 type=friend 
 username=1234
 secret=meinpasswort 
 host=dynamic 
 disallow=all 
 allow=ulaw 
 allow=alaw 
 dtmfmode=rfc2833
 context=sipgate

 exten => 1234,1,Dial(SIP/1234,60)
 exten => 1234,2,Congestion
 exten => 1234,102,Busy

 [1235] 
 type=friend 
 username=1235
 secret=meinpasswort 
 host=dynamic 
 disallow=all 
 allow=ulaw 
 allow=alaw 
 dtmfmode=rfc2833
 context=sipgate

 exten => 1234,1,Dial(SIP/1234,60)
 exten => 1234,2,Congestion
 exten => 1234,102,Busy
 exten => 1235,1,Dial(SIP/1235,60)
 exten => 1235,2,Congestion
 exten => 1235,102,Busy

 exten => 123[4-5],1,Dial(SIP/${EXTEN},60)
 exten => 123[4-5],2,Congestion
 exten => 123[4-5],102,Busy

Will man nun über seinen Asterisk-Server Gespräche zu einem Provider (z.B. Sipgate) führen, sind folgende Einträge in der sip.conf nötig:

 [general] 
 port = 5060 
 bindaddr = 0.0.0.0 
 context = default 
 disallow=all 
 allow=gsm
 allow=ulaw 
 allow=alaw 
 register => <SipgateAccount>:<SipgatePasswort>@sipgate.de/1234
 
 [sipgate] 
 type=friend 
 username=<SipgateAccount>;
 host=sipgate.de 
 fromuser=<SipgateAccount>;
 fromdomain=sipgate.de
 nat=no
 context=default
 canreinvite=no

 [default] 
 exten => 1234,1,Dial(SIP/${EXTEN},60)
 exten => 1234,2,Congestion
 exten => 1234,102,Busy
 
 [sipgate] 
 include => default
 exten => _9.,1,Dial(SIP/${EXTEN:1}@sipgate,60)
 exten => _9.,2,Congestion
 exten => _9.,102,Busy

Ja. :) Die etwas ausführlichere Antwort: Es geht mit allen von Linux unterstützten ISDN-Karten und sowohl mit ISDN4Linux als auch mit CAPI. Wobei CAPI vorzuziehen ist, da es mit ISDN4Linux Probleme mit DTMF-Tönen und Echo gibt. ISDN4Linux-Unterstützung ist bei Asterisk gleich mit dabei. Für CAPI wird zum einen CAPI-Unterstützung im Kernel für die ISDN-Karte benötigt (siehe z.B. AVM und CAPI-Anleitung für Debian) als auch ein Asterisk-Modul (chan_capi), das unter www.junghanns.net heruntergeladen werden kann.
Als dritte Möglichkeit gibt es noch für die Benutzer von ISDN-Karten mit HFC-Chipsatz den Zaptel-BRI-Treiber (ebenfalls von www.junghanns.net) mit dem es möglich ist, die Karte auch im NT-Mode zu betreiben.
In der Entwicklung befinden sich weitere ISDN Treiber: mISDN, der Nachfolger von ISDN4Linux für alle ISDN Karten und vISDN, ein Treiber für HFC Karten.

Es wird hierzu eine ISDN-Karte mit HFC-Chipsatz und dem Zaptel-BRI-Treiber (aka „bristuff“) benötigt. Weiterhin noch, wenn das Telefon über keine eigene Stromspeisung verfügt, einen NTBA zur Stromeinspeisung. Eine gute Anleitung hierzu kann unter Mit ISDN-Telefon und Sipgate kostenlos übers Internet telefonieren gefunden werden.

Wenn diese über einen internen S₀-Bus verfügt kann jede beliebige vom System unterstützte ISDN-Karte verwendet werden, z.B. eine Fritz!Card mit CAPI-Treibern. Angenommen, am internen S₀ ist die ISDN-Karte unter der MSN 42 zu erreichen, so wird folgender Eintrag in der capi.conf benötigt:

 [interfaces]
 msn=42
 incomingmsn=42
 controller=1
 softdtmf=0
 context=default
 echocancel=no
 devices=2

 [default]
 ; Wir verwenden in der ISDN-TK-Anlage zweistellige MSNs
 ; Dies sind Gespräche die z.B. per 
 ; VoIP eingehen und per CAPI weitervermittelt werden zum ISDN
 ; X ist ein Platzhalter für alle Ziffern von 0 bis 9
 ; [1-9] bezeichnet alle Ziffern von 1 bis 9
 ; muss ggf. noch an die lokale TK-Anlage angepasst werden.
 
 exten => _[1-9]X,1,Dial(CAPI/@42:${EXTEN})
 exten => _[1-9]X,2,Congestion
 
 ; Hier wird die ISDN-Karte von der 
 ; ISDN-TK-Anlage aus angerufen und in den 
 ; Kontext "sipgateohneneun" gesprungen:
 
 exten => 42,1,DISA,no-password|sipgateohneneun
 
 [sipgateohneneun]
 exten => _.,1,Goto(sipgate,9${EXTEN})

Dem entsprechenden Teilnehmer wird einfach eine Voicemailbox zugeordnet:

 [1234]
 ...
 mailbox=1234 ; Damit der MWI (MessageWaitingIndicator - das kleine Lämpchen o.ä.) 
              ; bei neuen Nachrichten aufleuchtet
 ...

die in der voicemail.conf angelegt worden ist:

 [default]
 1234 => 4242,Mein Name,meine@e-mail.de

Zuletzt muss noch ein Eintrag in die extensions.conf, damit Voicemail auch überhaupt ausgeführt wird, wenn der angerufene Teilnehmer den Anruf nicht beantwortet:

 exten => 1234,1,Dial(SIP/${EXTEN},60)
 exten => 1234,2,Voicemail2(u1234)
 exten => 1234,3,Hangup

 exten => 9999/_[1-9].,1,Answer
 exten => 9999/_[1-9].,2,Wait(1)
 exten => 9999/_[1-9].,3,VoicemailMain2(s${CALLERIDNUM})
 exten => 9999/_[1-9].,4,Hangup

Dies weist VoicemailMain2 an, direkt ohne Abfrage des Passworts zur Mailbox des Teilnehmers zu springen, der die Mailbox angerufen hat. Diese extensions sollten im übrigen auch nicht im default-kontext oder sonst einem von ausserhalb erreichbaren Kontext stehen. Deutsche Voicemail-Sounds gibt es hier. Oder von der Stadt Pforzheim (auch für die Asterisk 1.2.x).

Gleich eines vorweg, der folgende Text ist lediglich eine freie deutsche Übersetzung einer schönen Abhandlung zu diesem Thema von Olle E. Johannson, die im englischen Original hier zu finden ist.

Jeden Tag gibt es eine Frage zu SIP und NAT auf der asterisk-users Mailingliste. Dies ist auch nicht weiter verwunderlich, denn SIP und NAT ist kompliziert. Und Asterisk, SIP und NAT können viele verschiedene Konfigurationen haben die zu Problemen führen können.

An einem SIP-Gepräch sind sowohl SIP Signalisierungs- und RTP Audioströme mit dem RTCP Kontrollprotokoll dazu beteiligt. Dies sieht wie folgt aus:

 SIP CLIENT                  SIP SERVER
 (phone)                     (phone)
      ---------------------> SIP
 SIP  <--------------------- 
      ---------------------> RTP
 RTP  <--------------------- 
      ---------------------> RTCP
 RTCP <---------------------

Wie man sieht haben wir sechs verschiedene UDP Ströme für einen Anruf. Jeder hat eine Adresse des Senders (IP) und einen Port des Senders (UDP), sowie Adresse und Port des Empfängers. In den meisten Fällen werden die RTP-Ports dynamisch zugewiesen, um mehrere Anrufe gleichzeitig zu erlauben. Bringt man eine Firewall vor das Telefon, kann man sich vorstellen dass es eine Vielzahl an Ports gibt, die geöffnet und geschlossen werden müssen.

Wenn sich sowohl der Server als auch der Client im gleichen Netzwerk befinden, wie es von den Erfindern von SIP angenommen wurde, so ist dies recht einfach. Es wird dann kompliziert, wenn sich beide in zwei verschiedenen Netzwerken mit NAT (Network Addrss Translator) dazwischen befinden. Hier eine Erklärung:

SIP PHONE (A)------------NAT--------------SIP PHONE (B)
Local network                             INTERNET

Hier beginnen die Probleme.
Teilnehmer A kann Audio zu Teilnehmer B senden. Aber die Nachricht von A nach B enthielt eine interne, nicht öffentlich existierende IP-Adresse (Internal RFC1918 IP address). Daher gibt es keine Möglichkeit für B Audiodaten zu A zu senden. Dies ist die Ursache für eine Vielzahl von „Ich bekomme bloss Audio in eine Richtung“-Nachrichten. Es gibt keine Möglichkeit für B Audio zu A zu senden. Punkt. Wir müssen das Verhalten von A und B so ändern dass Anrufe funktionieren

Angenommen, Teilnehmer B sei der Asterisk-Server. Im SIP-Channel von Asterisk gibt es eine Option „nat=yes“. Dies modifiziert das Verhalten von Teilnehmer B, in diesem Fall Asterisk.

Wenn Teilnehmer A einen Anruf aufbauen möchte enthält die Invite-Nachricht die IP-Adresse und den Port unter dem es auf Audiodaten von Teilnehmer B, dem Asterisk-Server, wartet. Wenn „nat=yes“ gesetzt ist, so ignoriert Asterisk diese Daten vollkommen. Vielmehr wird die IP-Adresse überprüft, von der aus die Nachricht gesendet wurde, d.h. dem NAT-Gateway. Diese IP-Adresse wird nun an Stelle der lokalen, privaten Adresse (RFC 1918) verwendet und Audio wird an diese Adresse versandt. Bei den meisten NAT-Gateways werden die Audiodaten nun zum Client weitergereicht und wir haben Ton in beide Richtungen.

Wenn Asterisk unter einer öffentlichen Adresse (im Internet) erreichbar ist und sich das Endgerät hinter NAT befindet (aus der Sicht des Servers), so behebt „nat=yes“ das Audioproblem.

Das NAT-Gateway ist wie alte Verwandschaft, es ist sehr vergesslich. Nach einiger Zeit ist so die Beziehung zwischen Teilnehmer A und Teilnehmer B vergessen. Dadurch, wenn Teilnehmer B Teilnehmer A anrufen möchte, sucht das NAT-Gateway nach der IP-Adresse des Senders und kann diese zu keinem Gerät im eigenen Netz zuordnen. Es verwirft das Paket und vergisst, dass es jemals zu ihm gesandt wurde.

So funktionieren NAT-Gateways. Wenn die Kommunikation von innen nach aussen aufgebaut wurde, werden Antworten wieder zurück nach innen weitergereicht. Wenn aber jemand von aussen zu jemandem innerhalb Verbindung aufnehmen möchte, so wird dies nicht funktionieren.

Ein SIP-Endgerät registriert sich üblicherweise an einem SIP proxy. Diese Nachricht kommt von innerhalb des NATs zu einem Server ausserhalb. Somit gibt es eine offene Verbindung im NAT-Gateway. Sobald keine weiteren Pakete mehr über diese Verbindung versendet werden, schliesst das NAT-Gateway die Verbindung und vergisst alles darüber. Der Trick ist die Pakete in Bewegung zu halten und so das NAT-Gateway dazu zu zwingen, die Verbindung offen zu halten.

Einige Endgeräte senden NAT-„keep-alive“-Pakete von selbst. X-Lite und Sipura besitzen dieses Feature. Wenn das Endgerät dazu nicht in der Lage ist, kann man Asterisk dazu bringen, dies zu tun. Mittels „qualify=yes“ im Eintrag für dieses Endgerät beginnt Asterisk Pakete zu diesem Teilnehmer zu senden und hält so die Verbindung offen. Man kann sogar das Timing für Pakete zwischen Asterisk und dem Teilnehmer sehen, wenn man „sip show peers“ im CLI eingibt.

Wenn Asterisk nun diesen Teilneher anrufen möchte, empfängt das NAT-Gateway die Pakte und leitet sie zum Endgerät weiter.

Wenn Asterisk eine öffentliche IP-Adresse besitzt und sich das Endgerät hinter einem NAT-Gateway befindet, muss die NAT-Verbindung durch regelmässiges Senden von Dummy-Paketen zwischen den beiden Teilnehmern offen gehalten werden. So ist die Verbindung offen für eingehende Gespräche.

STUN, Simple Traversal of UDP over NAT devices, ist ein sog. discovery-Protokoll. Mittels STUN kann das Endgerät hinter dem NAT-Gateway spezielle Pakete zu einem STUN-Server schicken, um so herauszufinden, wie das NAT-Gateway arbeitet. NAT-Gateways können auf verschiedenste Art arbeiten und es gibt ziemlich üble die gar keine Telefongespräche durchlassen, ganz gleich was man tut. STUN-fähige Endgeräte finden diese heraus.

STUN sagt dem Endgerät, neben vielen anderen Dingen, welche IP-Adresse das NAT-Gateway auf der Aussenseite verwendet. Nimmt dann das Endgerät Verbindung zum SIP proxy/server auf, so sendet es die korrekte IP-Adresse und nicht die interne, private IP-Adresse. Korrekt implementiert wird kein „nat=yes“ für STUN-fähige Endgeräte benötigt.

UPNP, Universal Plug'n'play, ist eine weitere Lösung. Mit diesem Protokoll kann das Endgerät sich mit dem NAT-Gateway unterhalten, Ports reservieren und eine korrekte Konfiguration erhalten. Mit UPnP-fähigen Endgeräten und NAT-Gateway wird kein „nat=yes“ für Asterisk benötigt.

Befindet sich Asterisk hinter einem NAT-Gateway und will Verbindung zu einem SIP-Proxy (wie Free World Dialup oder SIPgate) oder zu Endgeräten Ausserhalb aufnehmen, so befinden wir uns in einer anderen Liga.

Wirf einen Blick in die sip.conf.sample im Asterisk configs-Verzeichnis und schaue nach „externalip“ und „localnet settings“, die Asterisk mitteilen, was die öffentliche IP-Adresse ist. Und ja, wir könnten einen STUN client in Asterisk verwenden, so dass Asterisk selbst herausfindet was zu tun ist. Irgendwelche Programmierer? Du bist gesucht. Wenn sich Endgeräte im öffentlichen Netz befinden, hilft Port-Forwarding. Wie man sich leicht vorstellen kann, ist dies keine leichte Aufgabe. Das Wiki hilft hier.

Ein outbound SIP proxy ist ein SIP proxy im gleichen Sinne wie man einen Web proxy im LAN konfigurieren kann, der den ganzen Web-Traffic zwischen dem LAN und der restlichen Welt abwickelt.Ein outbound SIP proxy würde sich um alle SIP-NAchrichten zwischen dem LAN und der restlichen Welt, dem Internet, kümmern. Dieser Proxy könnte auch die Umwandlung der IP-Adressen handhaben und der Firewall behilflich sein die RTP/RTCP-Ports zu öffnen und zu schliessen, damit Anrufe durchgehen.

Die Intertex IX66 arbeitet so, und es gibt Möglichkeiten den SIP Express Router so zu konfigurieren, dass er Teil der DMZ der Firewall ist und die SIP-Nachrichten abarbeitet und einen RTP-Proxy zu verwenden, der das Audio abarbeitet.

Derzeit gibt es keine Unterstützung in Asterisk für einen Outbound SIP Proxy. Ich arbeite daran, aber benötige einige Hilfe. Siehe chan_sip2 im Bugtracker.

SIP und NAT ist kein einfaches Thema, da es so viele verschiedene NAT-Gateways gibt. Es wird einfacher Dank SIP-Endgeräten die den NAT-Typ mittels STUN herausfinden und so korrekte und nützliche Informationen zum SIP-Proxy senden.

Es gibt eine Vielzahl von Themen die ich nicht in diesem kurzen Essay behandelt habe, wie die Handhabung des Medienstromes (canreinvite=no für Endgeräte hinter dem NAT), RTP Proxies und Session Border Controller. Dies wird später behandelt, wahrscheinlich wenn dies alles im Asterisk-Handbuch dokumentiert wird.

Weitere Informationen:

• Voip-info.org: NAT and VOIP
• Voip-info.org: Asterisk, SIP and NAT
• Voip-info.org: Asterisk NAT=yes documentation (sip.conf)

/Olle

Wenn man es richtig macht, sogar Kaffee kochen ;) Asterisk kann: SIP, H.323, IAX2, MGCP, SCCP, Analog, ISDN (von BRI bis PRI) und auch zwischen den verschiedenen Protokollen vermitteln; es kann G.711, GSM, G.729, G.726, iLBC, Speex und auch zwischen den verschiedenen Codecs umkodieren. Weiterhin geht Fax, Text2Speech, AGI (Ausführen externer Skripte/Programme) uvm. Wobei anzumerken ist, dass es sich bei G.729 um einen patentierten Codec handelt, der kostenpflichtig ist. Die Lizenz beträgt ca. 10$/Kanal und kann von www.digium.com bezogen werden.