11.07.2007 UPDATE: Wengophone 2.1.1 funktioniert jetzt mit anderen Providern (Weiterlesen!)

Ihr müsst allerdings darauf achten, dass Eure Asterisk einen funktionierenden Reverse-Eintrag im DNS hat!
Andernfalls bekommt man missvertändliche Fehler wie wiederholende "407 Proxy Authentication Required". Dies liegt daran, dass es durch den fehlgeschlagenen reverse lookup zu Verzögerungen kommt, die sogenannte "challenge" (nonce) des Servers abläuft und die "response" dann natürlich verkehrt ist.
Falls Ihr keinen DNS habt, könnt Ihr auch einen Eintrag in die "hosts" Datei der Client Rechner machen. Unter OSX - welches ja auf einem BSD basiert - tritt dieses Problem übrigens nicht auf, sondern nur unter Linux und Windows. Scheinbar ist der Timeout bei BSD kürzer.
Dies ist übrigens auch für SSH wichtig, da es ohne Reverse-Eintrag einige Sekunden dauert, bis die Passwort Prompt kommt.

Folgende Nachricht in der Konsole von Asterisk ist übrigens völlig harmlos, es ist lediglich ein "SIP Ping", mit dem versucht wird herauszufinden ob ein Tunnel benötigt wird, oder nicht:

Jul 11 19:51:41 NOTICE[4258]: chan_sip.c:11384 handle_request_register: Registration from
'' failed for '12.34.56.78' - Username/auth name mismatch

Softphone "WengoPhone" mit alternativem SIP-Provider (Alte Versionen)

WengoPhone ist ein OpenSource Softphone mit Unterstützung von Audio und Video für diverse Plattformen. Die Lizenz ist GPL, das bedeutet - umgangssprachlich - dass jeder den Quellcode kopieren, verändern und ebenfalls wieder unter der GPL weitergeben darf. WengoPhone verwendet den offenen SIP Standard und sollte daher zu allen SIP Providern kompatibel sein.
Soweit die Theorie. Das Projekt wird von dem französischen Provider Wengo gesponsort. Obwohl die Entwickler-Community "OpenWengo" immer wieder beteuern in der jeweils nächsten Release auch alternative Provider - z.B. eine eigene Asterisk - konfigurierbar zu machen, kam es dazu bisher nicht. Dieses Tutorial zeigt einen Ansatz wie man dennoch mit anderen Providern VoIPen kann.

SIP Zugangsdaten

Beim Starten von WengoPhone wird man aufgefordert seine E-Mail Adresse und sein Passwort einzugeben. Das sind jedoch nicht die eigentlichen SIP Zugangsdaten, sondern nur der Wengo Account. Daraufhin wird man zu einem fest eingestellten Webhost namens ws.wengo.fr verbunden.
Der Request hat folgenden Aufbau:

/softphone-sso/sso2.php?lang=c&wl=wengo&login=HIER.DIE.EMAIL&password=HIERDASPASSWORD

Alternative Provider

Da der Sourcecode offen ist und unter der GPL steht kann man entweder einfach ws.wengo.fr durch einen eigenen Webhost austauschen oder ohne Compilierung in der Datei "/etc/hosts" einen entsprechenden Host Eintrag auf seine IP Adresse zu machen.
Als Zugangsdaten konfiguriert man in WengoPhone dann direkt seine SIP Zugangsdaten anstatt der von Wengo, unser Host funktioniert dann sozusagen als Reflektor, der uns einfach das zurückliefert, was wir ihm hinschicken.
Auf dem eigenen Webhost muss man dann im Verzeichnis "softphone-sso/" folgende Datei erstellen:
(Wenn Ihr keinen Webserver mit PHP habt/wollt, könnt Ihr mir eine E-Mail schreiben und meinen Reflektor mitbenutzen)

/softphone-sso/sso2.php

<?php
$xmlstr='<?xml version="1.0"?>
<sso mib="1">
<status code="200">OK</status>
<d k="sip.auth.userid" v="'.$_GET['login'].'"/>
<d k="sip.auth.password" v="'.$_GET['password'].'"/>
<d k="sip.auth.realm" v="HIER.EUER.REALM"/>
<d k="sip.address.name" v="'.$_GET['login'].'"/>
<d k="sip.address.displayname" v="'.$_GET['login'].'"/>
<d k="sip.address.server.host" v="HIER.DIE.IP.ADRESSE"/>
<d k="sip.address.server.port" v="5060"/>
<d k="sip.outbound" v="1"/>
<d k="sip.outbound.proxy.host" v="HIER.DIE.IP.ADRESSE"/>
<d k="sip.outbound.proxy.port" v="5060"/>
<d k="netlib.stun.host" v="HIER.EIN.STUN.SERVER.FUER.NAT"/>
<d k="netlib.tunnel.http">
<l v="HIER.DIE.IP.ADRESSE"/>
</d>
<d k="netlib.tunnel.https">
<l v="HIER.DIE.IP.ADRESSE"/>
</d>
</sso>';
echo $xmlstr;
?>


SSL

Der Client versucht sich via SSL zu dem eingetragenen Webhost zu verbinden. Solltet Ihr kein SSL haben oder wollen, könnt Ihr mit der iptables rule iptables -A OUTPUT -p tcp -m tcp --dport 443 -j DROP SSL blocken, woraufhin der Client auf unverschlüsselte Kommunikation auf Port 80 zurückfällt. Natürlich ist das nur ein Beispiel, und Ihr solltet Port 443 nur für Euren Host blocken. Aber Vorsicht, die Zugangsdaten sind dann ungesichert.

Self Signed Cert

Falls Ihr nicht auf SSL verzichten wollt, könnt Ihr Euch auch ein eigenes, selbst signiertes SSL Zertifikat erstellen.
Damit wir das Zertifikat, das wir später erzeugen, auch signieren können, müssen wir erstmal zur "Certificate Authority" (CA) werden. Dafür brauchen wir das Tool openssl. Unter Debian kann man das einfach mit "apt-get update; apt-get install openssl" installieren.

openssl genrsa -des3 -out my-ca.key 4096
openssl req -new -x509 -days 365 -key my-ca.key -out my-ca.crt

Wenn Ihr den Befehl ausführt, werdet Ihr aufgefordert ein paar Daten einzugeben. Achtet bitte jetzt schon darauf, dass sich die Daten für das CA Cert von den Daten die Ihr später für das Server Cert eingeben werdet unterscheiden, beispielsweise durch anhängen von " CA" ("FooBar CA" statt "FooBar").

Jetzt erstellen wir das SSL Zertifikat für den Webserver:
openssl genrsa -des3 -out my-server.key 4096
openssl req -new -key my-server.key -out my-server.csr

Dieses Zertifikat müssen wir noch dem CA Key signieren:
openssl x509 -req -days 365 -in my-server.csr -CA my-ca.crt -CAkey my-ca.key -set_serial 01 -out my-server.crt

Den mit der Passphrase geschützten my-server.key und die Signatur my-server.crt können wir dann im Apache einbauen.
Das ganze ist für private Zwecke ausreichend, gibt aber Warnungen, dass die Signatur von keiner bekannten vertrauenswürdigen Stelle kommt.

Wenn Ihr ein vertrauenswürdig signiertes Zertifikat wollt, könnt Ihr hier eines erwerben:

Probleme

Raus telefonieren funktioniert bei mir prima, allerdings stürzt der Client bei eingehenden Anrufen ab, da muss ich wohl noch ein wenig tiefer im Quellcode graben, bin für jeden Hinweis dankbar.

17.10.2006 UPDATE: Fehler gefunden

Der Grund für den Crash bei eingehenden Gesprächen war die fehlende Unterstützung für den Video Codec h261. Ihr müsst also gegebenenfalls in der Asterisk die Zeile "allow = h261" auskommentieren bis Wengophone diesen Codec unterstützt. Bis dahin könnt Ihr den Codec h263 verwenden ("allow = h263").