Na, dann hänge ich meinen Bugreport eh Testbericht doch mal hinten dran, in der Hoffnung, dass hier kritischen Punkten und Kundenproblemen etwas offener gegenüber steht, als nebenan im UTStarcom Forum, wo man es ja leider vorzieht alles runterzuspielen oder sogar wegzuzensieren. Die Hoffnung stirbt ja bekanntlich zuletzt
Testbericht
Ich halte mein SL75 WLAN also auch seit gestern in den Händen. Mein Gerät hat die Hardware-Version 2.4 und Firmware-Version 01.999.35.00000. Leider komme ich erst heute dazu, einen Testbericht zu verfassen, da die Firmware doch leider noch ein paar Bugs enthält, wie leider mitterweile bei fast jedem neuen Gerät, Bugs, die ich versucht habe, so gut wie möglich per UDP/IP Paketsniffer zu identifizieren, was doch etwas Zeit gekostet hat.
Ich hoffe, VoIPMaster hat nichts dagegen, dass ich seinen Testbericht mal als Vorlage verwende und dabei auf verschiedene Aussagen eingehe, wenn ich ergänzende Fakten habe, anderer Meinung bin oder ein bestimmtes Feature als besonders positiv empfinde.
VoIPMaster schrieb:
Das SL75 WLAN ist äußerlich sehr schön anzusehen und liegt gut in der Hand. Das 65 k Farb-Display ist gut ausgeleuchtet und hat 6 effektive Zeilen. Die Hartkunststoff-Tasten sind alle beleuchtet und haben einen klar definierten Druckpunkt.
Ergänzend kann man noch sagen, dass das Gerät etwa 25% länger, einen Tick breiter und genauso dick wie ein GSM-Telefon von Typ C55 von Siemens ist. Insgesamt ist das Gerät also etwas größer als z.B. das UTStarcom F1000.
Das Phone kommt mit einer standsicheren Ladeschale, einer Rückschale, einem Lithium Ion Akku und einer CD auf der sich eine Software und die Bedienungsanleitungen befinden.
Zusätzlich ist auch eine gedruckte Kurzanleitung enthalten, die eigentlich alle wichtigen Punkte für die Erstinstallation abdeckt: Akku-Handling, WLAN- & SIP-Einstellungen, Erstzugang zum Web-Interface. Der Lithium Ion Akku ist übrigens 1:1 identisch mit dem Akku des GSM-Telefons C55. Auch die Anschlüsse für das Ladegerät sind bei beiden identisch. Jetzt kann ich auch mein C55 in der Tischladestation des SL75 WLAN aufladen. Ziemlich nett, ich mag diese einfachen Ladekabel, die ständig unter irgendwelchen Tischen oder Schränken verschwinden nicht wirklich
Leider hat der Akku nur eine Kapazität von 700 mAh. Bei der angegebenen Standbyzeit von maximal 2 Tagen und der Sprechzeit von 4 Stunden, hätte man eventuell vielleicht auch was größeres spendieren können. Sehr negativ ist jedoch, dass der Akkudeckel keinen Release-Mechanismus hat. Man bekommt den Deckel nur durch reine Kraftaufwendung ab. Das geht aber bestimmt nur x-mal gut, bevor mal irgendwas abbricht. Verschlimmert wird dies noch dadurch, dass während meiner ganzen Tests, das Gerät zumindest einmal beim Runterfahren "Gerät schaltet sich ab" komplett hängengeblieben ist und nur durch Abnehmen des Akkus wiederzubeleben war.
Als erstes stellt man das Handset in die Ladeschale und lässt laden
. Nach dem Einschalten drückt man auf den scan-Button und sucht nach (s)einem WLAN Netz.
Der ganze Boot-Vorgang vom Einschalten bis zum Einbuchen beim SIP-Provider dauert etwa 40-50 Sekunden. Für ein linux-basiertes Device ist das allerdings nicht ungewöhnlich.
Je nach WLAN Umgebung muss man dann wie bei jedem anderen Netzwerkgerät auch die Konfigurationsdaten eingeben. Das SL75 WLAN unterstützt dabei folgende WLAN-Einstellungen
Getestet habe ich hierbei nur die WEP128 Verschlüsselung, die funktioniert problemlos. Andere Features 802.1x, WPA und Zertifikate habe ich nicht getestet.
Als nächstes müssen dann die Daten des SIP Providers eingegeben werden. Für einige SIP Provider sind die Server Daten bereits voreingestellt.
Voreingestellt im Auslieferungszustand bei meiner Firmware waren 1und1, Freenet, Sipgate und T-Online. Somit ist das SL75 momentan noch ein durch und durch "deutsches" Produkt
Das hat allerdings wegen Firmwarebugs, aufgrund derer das SL75 derzeit nur bei ausgewählten VoIP-Providern funktioniert, gravierende Auswirkungen. Siehe auch unten bei der SIP-Provider-Kompatibilität.
Ist der gewünschte Provider nicht in der Liste vertreten, können die Server Daten im Webserver des SL75 WLAN eingegeben werden.
Dazu ist allerdings anzumerken, dass man neue VoIP-Provider wirklich ausschließlich nur über das Web-Interface definieren kann. Wer also unterwegs mal in die Verlegenheit käme, sich bei einem neuen VoIP-Provider einbuchen zu wollen, der noch nicht als Template (PVD-Datei) im SL75 gespeichert ist, braucht zwangsweise einen PC/Laptop mit Webbrowser, um ein neues Provider-Template im SL75 anzulegen.
Wenn alle Daten eingegeben sind, kommt ein kurzer Neustart und schon kann’s losgehen.
Leider nicht ganz so kurz, der Neustart dauert immerhin etwa 1 Minute. Leider erfordert auch jeder Wechsel des Profils einen solchen Neustart. Dazu kommt noch, dass es immer mal wieder gelegentlich vorkommt, dass das SL75 beim Einschalten/Reboot das WLAN nicht findet und man dann nochmal Rebooten muss. Wer also gehofft hat, mit den 16 Profilen schnell zwischen verschiedenen VoIP-Providern wechseln zu können (so wie bei Call-by-Call) wird unter Umständen teilweise enttäuscht. Natürlich ist das SL75 in dieser Beziehung immer noch unendlich viel "besser" als die Modelle von UTStarcom oder Zyxel, die die Konfiguration mehrerer SIP-Provider erst gar nicht zulassen. Allerdings darf man schon fragen, ob man den Wechsel zwischen SIP-Providern nicht doch etwas effizienter gestalten könnte. Für das bloße Versenden von ein paar UDP Paketen (SIP-Registrierung beim neuen Provider) kann es doch unmöglich erforderlich sein, gleich den ganzen Linux-Kernel zu rebooten
Das SL75 WLAN kommt mit einer Kamera nach Hause. Sie ist auf der Rückseite des Handsets angebracht und hat einen kleinen Spiegel als Unterstützung für Selbstaufnahmen.
Leider nur ein CIF-Auflösung (352x288 Pixel), was natürlich nicht mehr so ganz zeitgemäß ist. Allerdings interessiert mich persönlich die Kamera sowieso nicht, wozu hat man schliesslich am GSM-Handy schon eine, von daher ist mir auch die Auflösung egal.
Ein sehr interessantes und brauchbares Feature ist sicherlich die E-Mail Funktion. Man kann mit dem SL75 WLAN E-Mails mittels pop3 und smtp empfangen und auch senden. Das ganze funktioniert sogar mit Anhang (Kamerabilder, Klingeltöne und Hintergrundbilder). Durch die T9-Eingabe ist der E-Mail Versand auch praxistauglich. Es lässt sich auch ein automatischer E-Mail Empfang einstellen. Man kommt also von der Arbeit nach Hause und wird durch den blinkenden Notify-Key benachrichtigt, dass man eine E-Mail erhalten hat und kann sie gleich am Mobilteil lesen. Und das ganze ohne laufenden PC. Schön.
Noch nicht getestet, aber ansonsten grundsätzlich Zustimmung. Wobei mir die Funktionalität des S35 WLAN auch reicht, Hauptsache, man sieht, dass es da neue E-Mail gibt.
Messenger? Klar, gibt’s auch. Aber man hat sich hier nicht auf einen speziellen festgefahren, sondern Jabber war die Lösung. Mit Jabber kann man durch transport-server auf eine Vielzahl von Messenger zugreifen (ICQ, MSN, Jahoo,…). Im Handset sieht das dann folgendermaßen aus. Es gibt eine Buddy Liste mit Statusanzeige (Kleine Mensch-Ärgere-Dich-Nicht-Figürchen die ihre Farbe ändern). Das Chatten ist Dank T9 genauso schnell wie SMS tippen und somit brauchbar.
Noch getestet, dennoch die kleine Anmerkung, dass die Konfiguration des IM-Zugangs wieder nur vom PC aus per Web-Interface möglich ist, nicht am Handset selbst.
Wenn neue Providerdaten (SIP Server, Proxy…) erstellt werden, kann man diese in einem speziellen file abspeichern und auch wieder aufs Phone spielen. Man könnte also hier im Forum die Providerfiles verteilen, wenn jemand Probleme mit den SIP Einstellungen hat.
Das ist in der Tat ein ausserordentlich nützliches Feature, damit lässt auf schöne Art und Weise vermeiden, dass jeder Kunde einzeln stundenlang VoIP-Zugangsdaten eintippen muss. Man fragt sich, warum man im GSM-Bereich für die WAP und GPRS-Internetzugangsdaten noch nicht auf diese Idee gekommen ist
Audio: endlich ein WLAN Telefon mit angenehmen polyphonen Klingeltönen
Da bin ich leider anderer Meinung. Die Klingeltöne sind meiner Ansicht nach viel zu leise. Auch bei lautester Einstellung hat man meiner Ansicht noch kaum eine Chance, dass Klingeln des S75 WLAN wahrzunehmen, wenn sich das Mobilteil in einem anderen Raum mit 2 Türen dazwischen befindt.
Außerdem fehlen mir zumindest ein oder zwei "stinknormale" Klingeltöne, nicht nur dieser polygone Schnickschnack
und einer sehr guten Freisprecheinrichtung ... Die Sprachqualität ist hervorragend und die Lautstärke gut einstellbar.
Hier wieder vollste Zustimmung. Der "analoge" Teil der Sprachqualität ist praktisch perfekt. Kein Knarzen, keine Übersteuerung im Lautsprecher, einfach gut. Die Hörerlautstärke des SL75 ist im Auslieferungszustand auf den geringsten Wert eingestellt und selbst das ist schon ausreichend. Über zu geringe Hörerlautstärke muss sich beim SL75 zumindest niemand Gedanken machen.
Auf dem Display kann Datum und Uhrzeit dargestellt werden. Wahlweise können diese von einem timeserver aktualisiert werden.
Leider schaltet sich das Display im Standby nach einem zwischen 5 und 60s programmierbaren Timeout aber immer komplett ab. Ein schäbiges Verhalten, dass leider auch bei GSM Telefonen mehr und mehr um sich greift. Eine Option, bei der nach dem Timeout nur die Hintergrundbeleuchtung abschaltet, aber die Displayinformationen Feldstärke, Batterieladezustand, Datum&Uhrzeit sichtbar bleiben, sucht man leider vergebens. Auch in der Ladeschale hat man nur die Optionen, das Display inkl. Beleuchtung dauerhaft eingeschaltet zu haben (Nachtmodus aus) oder das Display nach dem Timeout komplett abschalten zu lassen (Nachtmodus an).
Folgende Codecs werden unterstützt: G.722, G.711A/B, G.723, G.729
Leider fehlt der G.726, welcher auf dem Sipura in der 32 kbit/s Variante immer man Lieblingscodec war bzgl. Tradeoff zwischen Sprachqualität und Bandbreite. Und beim G.729 gibt es Probleme bei den Finarea-Providern (s.u.).
NAT-Traversal per STUN und Outbound Proxy möglich. Viele von euch wird es freuen, dass man nun endlich auch URIs (SIP Adressen) mit einem WLAN Phone wählen kann (IP Adressen übrigens auch).
Und dem Zusammenhang treffen wir auf den ersten Mangel in der Firmware. Also ich nenne das mal einen Mangel, wahrscheinlich kommen gleich mehrere Antworten, die behaupten, das sei in Wirklichkeit ein Feature (manchmal liegt das ja dicht beieinander). Der Outbound Proxy, so er denn im aktuellen Profil aktiviert ist, wird auch dann verwendet, wenn man einen IP-to-IP Call startet. Nun mag es ganz abgeschottete Firmennetzwerke geben, wo das erforderlich ist, im Normalfall wird man allerdings für direkte IP-to-IP-Calls keinen Proxy benötigen. Das Problem ist, dass wenn man einen VoIP Provider hat, bei dem man zwingend einen solchen Outbound-Proxy einsetzen muss, dann funktionieren IP-to-IP Calls in der Regel nicht mehr, ohne erst das SIP-Profil zu wechseln, inkl. des oben schon erwähnten Reboots von einer Minute, weil der VoIP-Provider, dessen Outbound-Proxy man eingestellt hat in der Regel keine direkten IP-to-IP Calls routet. Sipura/Linksys SPA verwendet den eingestellten Outbound-Proxy bei IP-to-IP Calls auch nicht, ideal wäre vielleicht ein Haken, der angibt, ob der Outbound-Proxy bei direkten IP-to-IP Calls auch verwendet werden soll oder nicht.
Ansonsten, also unter der Vorraussetzung, dass ein Profil ohne Outbound-Proxy ausgewählt ist, funktionieren mit dem SL75 IP-to-IP Calls mit einem Sipura SPA als Gegenstelle problemlos.
Erfolgreich getestete Provider:
- Sipgate
Tut's.
Nicht getestet.
- Sipdiscount
- Voipbuster
- Voipdiscount
Hier muss ich energisch widersprechen. Getestet habe ich mit Voipbuster, aber ich gehe aufgrund der Ursachenforschung dieser Probleme davon aus, dass gleiches auch für die anderen Finarea Provider und für viele andere VoIP-Provider gilt.
Abgehende Gespräche über Voipbuster funktionieren in der Tat relativ problemlos, solange man nicht den G.729 Codec einstellt. Beim G.729 Codec kommt auf dem Display des SL75 eine Fehlermeldung, dass der Dienst nicht möglich sein. Dennoch klingelt es beim angerufenden Teilnehmer bis dieser abnimmt, allerdings bekommt dieser dann nur eine tote Leitung zu hören, weil das SL75 den Anrufversuch längst abgebrochen hat. G.711 und G.723 funktionieren hingegen. Bei Sipgate funktioniert auch G.729.
Der wirkliche Ärger beginnt jedoch eingehenden Gesprächen. Hier hat die Firmware des SL75 leider diverse Bugs, die eingehende Gespräche nahezu unmöglich machen. Dabei handelt es sich übrigens nicht um Konfigurationsfehler am NAT-Router, denn ich habe sämtlichen Traffic zwischen dem SL75 und dem NAT-Router auf der Ethernet-Strecke geloggt und die Probleme treten in allen Fällen am SL75 selbst auf und werden nicht durch am Router verworfene Pakete erzeugt.
- Eingehende Gespräche bei Voipbuster in Verbindung mit dem SL75 sind nur in den ersten X Minuten nach dem Einschalten möglich. Bereits nach kurzer Zeit (10-15 Minuten nach dem ersten Einbuchen) bekommt ein Anrufer zwar noch ein Klingelzeichen von Voipbuster, das SL75 rührt sich aber nicht mehr. Bei weiteren Anrufversuchen, wenn auch Voipbuster erkannt hat, dass das SL75 auf eingehende Anrufe nicht reagiert, hören Anrufer dann, dass der SL75 User zur Zeit nicht online sei. Abgehende Gespräche funktionieren hingegen immer noch, auch ohne erneutes Einbuchen bei Voipbuster. Nach einem abgehenden Gespräch ist man dann auch wieder für kurze Zeit erreichbar für eingehende Gespräche, aber eben wieder nur für kurze Zeit. Auch ein Verringern des Registrierungstimeouts bringt hier keine Änderung.
- Wenn ein eigehender Anrufer denn mal durch kommt, der Anrufer hingegen auflegt, bevor das Gespräch am SL75 angenommen wird, hört das SL75 nicht mehr auf zu klingeln bzw. erst etliche Minuten später.
Aufgrund der Ursachen dieser Fehler, die weiter am Ende des Artikels noch genauer technisch beschrieben sind, kann man davon ausgehen, dass das SL75 derzeit für den Enduser nur zu empfehlen ist, wenn er einen der von Siemens getesteten VoIP Provider verwendet. Also 1und1, Freenet, Sipgate oder T-Online.
Die Sprachqualität überzeugt auf alle Fälle. Mit dem G.722 Codec erreicht man eine bessere Sprachqualität als mit ISDN.
Analog ja. Bei G.722 frage ich mich allerdings, mit welchem Provider du das ausprobiert hast. Finarea und Sipgate können den jedenfalls lt. eigener Angaben nicht. Immerhin: Auch G.723 und G.729 (wenn er denn funktioniert) klingen noch ganz annehmbar. Das wird Menschen mit weniger Bandbreite sicher freuen.
Besonders im Grenzbereich der Reichweite hält sich die Verbindung noch besser als bei den anderen WLAN Phones.
Noch nicht ausgiebig getestet.
Ich habe nun schon einige WLAN Phones getestet (ein paar stehen in meiner Signatur) und muss ganz klar sagen, das SL75 WLAN ist mit Abstand das Beste.
Also das kann man zum derzeitigen Zeitpunkt so leider noch nicht stehen lassen. Das SL75 hat nicht zuletzt aufgrund der vielen Features IP-to-IP calls, SIP-Profile, E-Mail usw. das Potential ein Supergerät zu werden, wobei ich ein Feature noch schmerzlich vermisse, nämlich ENUM. Mit der aktuellen Firmware muss man jedoch mit dem SL75 mit Problemen rechnen, wenn man einen anderen als den von Siemens bisher vorgegebenen VoIP Providern verwenden möchte.
Firmware-Bugs
In der Hoffnung, dass evtl. ein Siemens-Entwickler des SL75 hier mitliest oder jemand meine Ausführungen weitergeben kann und von Seiten des Herstellers auch Interesse besteht, Bugs loszuwerden, poste ich hier mal genauere Details:
Geloggt habe ich den UDP/IP Traffic auf der Ethernet-Strecke zwischen meinem Internetrouter (NAT) und dem SL75 mit Hilfe von tcpdump. 192.168.100.22 ist dabei die IP-Adresse des SL75. Aus der Tatsache, dass ich die fehlerhaften Pakete auf dieser Ethernet-Strecke loggen konnte, also bereits "hinter" dem Router, sollte klar sein, dass hier keine Fehlkonfiguration am Router vorliegt, dass der Router auch keine Pakete verschluckt, sondern dass tatsächlich das SL75 sich fehlerhaft verhält. Port 5004 (der RTP-Port) habe ich rausgefiltert, so dass ich mich auf SIP und STUN konzentrieren kann. Wichtig ist übrigens, dass der STUN-Server von Finarea nicht funktioniert (icmp port unreachable kommt von UDP Port 10000 zurück), ich habe bei den Tests den STUN Server von sipgate verwendet, das läßt sich ja problemlos kombinieren, d.h. in allen SIP Paketen vom SL75 tauchte überall die externe IP Adresse des Routers auf, und nicht die 192.168.100.22 (interne IP des SL75). Hier die genauen tcpdump-Optionen:
tcpdump -n -xX -s 0 -i eth0 'host 192.168.100.22 and not udp port 5004'
1a. Eingehende Gespräche abgeblockt (Einstellung "Lokaler SIP-Port" ohne Effekt):
Das Problem liegt hier um udp source port, den das SL75 beim Registrieren am SIP Server verwendet. Das SL75 hat sogar unter "SIP erweitert" eine Einstellmöglichkeit für diesen Port "Lokaler SIP-Port". Eingetragen war 5060. Nur leider hält sich SL75 nicht daran, sondern verwendet einfach irgendwelche Ports knapp oberhalb von 1024, was genau das Verhalten von Linux/glibc ist, wenn man beim Socket Bind Aufruf keine Port-Nummer angibt. Hier ist es also versäumt worden, beim Öffnen des UDP Ports auf dem SL75 die unter "Lokaler SIP-Port" eingetragende Port-Nummer anzugeben.
Code:
17:17:58.168305 192.168.100.22.1034 > 80.239.235.200.5060: udp 437 (DF)
0x0000 4500 01d1 0cad 4000 4011 0604 c0a8 6416 E.....@[email protected].
0x0010 c2dd 3ecf 0409 13c4 01bd 185b 5245 4749 ..>........[REGI
0x0020 5354 4552 2073 6970 3a73 6970 2e76 6f69 STER.sip:sip.voi
0x0030 7062 7573 7465 722e 636f 6d3a 3530 3630 pbuster.com:5060
0x0040 2053 4950 2f32 2e30 0d0a 4d61 782d 466f .SIP/2.0..Max-Fo
0x0050 7277 6172 6473 3a20 3730 0d0a 436f 6e74 rwards:.70..Cont
...
Mein Sipura SPA macht das Hingegen korrekt und verwendet 5060 auch als Source UDP Port.
Das Problem ist nun, wenn das SIP-Invite vom SIP-Server kommt. Der Sipgateserver schickt das SIP Invite unabhängig vom UDP Sourceport, den das SL75 beim Register verwendet hat, immer über Port 5060 zum SL75.
Code:
17:14:08.721776 217.10.79.9.5060 > 192.168.100.22.5060: udp 1110 (DF) [tos 0x10]
0x0000 4510 0472 0000 4000 3911 f098 d90a 4f09 [email protected].
0x0010 c0a8 6416 13c4 13c4 045e 27bf 494e 5649 ..d......^'.INVI
0x0020 5445 2073 6970 3aXX XXXX XXXX XXXX 40XX TE.sip:XXXXXXX@X
0x0030 XX2e XXXX XX2e XXXX 2eXX XXXX 3a35 3036 X.XXX.XX.XXX:506
0x0040 3020 5349 502f 322e 300d 0a52 6563 6f72 0.SIP/2.0..Recor
...
So funktioniert das auch, über den Port 5060 nimmt das SL75 den Invite an und fängt an zu klingeln.
Der Voipbusterserver verhält sich jedoch anders:
Code:
17:27:49.228580 80.239.235.200.5060 > 192.168.100.22.1034: udp 697 (DF)
0x0000 4500 02d5 c792 4000 7811 d70e 50ef ebc8 [email protected]...
0x0010 c0a8 6416 13c4 040a 02c1 9265 494e 5649 ..d........eINVI
0x0020 5445 2073 6970 3aXX XXXX XXXX XXXX XXXX TE.sip:XXXXXXXXX
0x0030 XXXX 4073 6970 2e76 6f69 7062 7573 7465 [email protected]
0x0040 722e 636f 6d3a 3530 3630 3b65 7870 6972 r.com:5060;expir
...
Wie man sieht, schickt der Voipbuster Server den SIP Invite an den gleichen UDP Port, den das SL75 als UDP Source Port beim Registrieren verwendet hat. Das klappt noch in den ersten paar Minuten nach der Registrierung, später aber scheint das SL75 diesen Port "vergessen" zu haben, das SL75 antwortet dann nämlich mit
Code:
17:27:49.383978 192.168.100.22 > 80.239.235.200: icmp: 192.168.100.22 udp port 1034 unreachable [tos 0xc0]
Weil es auf den ersten Blick eigentlich wie ein typisches NAT-Router Problem aussieht, habe ich das extra noch mal gegengetestet, indem ich das UDP Paket einfach mal manuell von meinem Router an das SL75 geschickt habe, also einfach nur über mein internes WLAN, also ohne irgendwelches NAT dazwischen. Gleiches Ergebnis: An Port 1034 antwortet das SL75 mit "port unreachable", an Port 5060 geschickt, klingelt es. Es ist also definitiv ein Fehler am SL75.
1b. Registrierungs-Timer Einstellungen ohne Effekt
Nun sollte man ja eigentlich meinen, dass man das Problem aus 1a einfach umgehen könnte, wenn man nur den Registrierungs-Timer unter "SIP erweitert" so klein einstellt, dass sich das SL75 alle 5 Minuten neu registriert. Das habe ich auch versucht, sowohl unter Session-Timer als auch unter Registrierungs-Timer 300 Sekunden eingetragen, leider hatte diese Einstellung überhaupt gar keinen Effekt. Ich habe mindestens 20 Minuten den Datentraffic von und zum SL75 geloggt und es sind dort keine zusätzlichen Registrierungspakete verschickt worden. Dadurch bleibt natürlich auch Problem 1a bestehen.
Edit 16.06.2006: Bei sipgate scheinen die neue Registrierungen im eingestellten Intervall verschickt zu werden. Von daher hat die Timereinstellung schon eine Wirkung, nur verschickt, wie es aussieht, das SL75 an Voipbuster überhaupt keine wiederholten Registrierungen.
2. "Hört nicht auf zu klingeln"-Problem
Hier scheint es sich im eine fehlerhaft verlaufende Anrufzuordnung zu handeln. Wenn vom Voipbuster Server das SIP CANCEL Paket beim SL75 eintrifft, antwortet dieses mit
Code:
17:53:56.949236 192.168.100.22.1034 > 194.120.0.202.5060: udp 396 (DF)
0x0000 4500 01a8 0d15 4000 4011 442f c0a8 6416 E.....@[email protected]/..d.
0x0010 c278 00ca 040a 13c4 0194 4a98 5349 502f .x........J.SIP/
0x0020 322e 3020 3438 3120 4361 6c6c 2044 6f65 2.0.481.Call.Doe
0x0030 7320 4e6f 7420 4578 6973 740d 0a43 616c s.Not.Exist..Cal
...
und klingelt munter weiter. "Call Does Not Exist" würde darauf hinweisen, dass das SL75 nicht in der Lage ist, den SIP CANCEL Request dem vorherigen SIP INVITE zuzuordnen. Nun stellte sich die Frage, warum klappt das bei Sipgate, aber nicht bei Voipbuster? Bei der Durchsicht der SIP Pakete stellte sich folgendes heraus. Für die Zuordnung scheint es drei Parameter zu geben, eine Caller-ID, einen Tag hinter der From-Zeile und einen Tag hinter der To-Zeile. Dabei wird jeder Tag von jeweiligen Gerät erzeugt, der from-tag bei einem eingehenden Anruf also vom SIP-Server und der to-tag vom SL75. Dabei ergab sich folgendes Bild:
Code:
Sipgate:
Server->SL75 SIP INVITE from-tag=as29ae1ac3 to-tag=<nicht vorhanden> [email protected]
Server<-SL75 SIP Trying from-tag=as29ae1ac3 to-tag=1e5b225c0c6a5eb [email protected]
Server<-SL75 SIP Ringing from-tag=as29ae1ac3 to-tag=1e5b225c0c6a5eb [email protected]
Server->SL75 SIP CANCEL from-tag=as29ae1ac3 to-tag=<nicht vorhanden> [email protected]
Voipbuster:
Server->SL75 SIP INVITE from-tag=ca0078c2448d2f22e5df to-tag=<nicht vorhanden> Call-ID=72d852cd04a84b7594b7d20f3f938332
Server<-SL75 SIP Trying from-tag=ca0078c2448d2f22e5df to-tag=c9228be66deb556 Call-ID=72d852cd04a84b7594b7d20f3f938332
Server<-SL75 SIP Ringing from-tag=ca0078c2448d2f22e5df to-tag=c9228be66deb556 Call-ID=72d852cd04a84b7594b7d20f3f938332
Server->SL75 SIP CANCEL from-tag=ca0078c2448d2f22e5df to-tag=c9228be66deb556 Call-ID=72d852cd04a84b7594b7d20f3f938332
Man erkennt, dass der From-Tag bereits vom Server erzeugt wird und schon im Invite Paket enthalten ist. Der To-Tag hingegen wird vom SL75 erzeugt und taucht der erst im ersten Paket auf, dass vom SL75 zum Server geschickt wird (Trying).
Nun sieht man zwei Unterschiede zwischen Sipgate und Voipbuster:
a) das CANCEL Paket vom Voipbuster Server enthält im Gegensatz zum CANCEL Paket vom sipgate Server auch den To-Tag, den das SL75 zuvor in den Trying und Ringing Paketen zum Server geschickt hat. Dadurch unterscheiden sich die Identifikationsmerkmale des Anrufs zwischen den INVITE und CANCEL Paketen des Voipbuster Servers, während beim Sipgate Server die Identifikationsmerkmale in beiden Paketen gleich sind. Das SL75 vergleicht offenbar alle 3 Merkmale, inkl. des To-Tag, um die Pakete dem entsprechenden Anruf zuzuordnen. Da sich beim Voipbuster Server die To-Tags unterscheiden, schlägt zu Zuordnung im Gegensatz zu Sipgate hier fehl und es kommt zu der "Call Does Not Exist" Antwort des SL75. Da andere SIP-Hardware jedoch keine Probleme damit haben und die CANCEL Pakete vom Voipbuster Server korrekt zuordnen, schreibe ich dieses Problem dem SL75 zu. Zur Zuorndung dürften offenbar nur From-Tag und Call-ID verglichen werden. Würde das SL75 das so machen, würde es auch funktionieren.
b) Bei der Call-ID sieht man zwischen Sipgate und Voipbuster den Unterschied, dass Sipgate nach der eigentlichen Hexdezimal-CallId noch seine IP-Nummer anhängt. Bei einem direkten IP-to-IP Call des Sipura SPA konnte ich ähnliches beobachten. Voipbuster macht das nicht. Da über die Call-ID in allen Paketen gleich bleibt, dürfte das für die Zuordnung von INVITE zu CANCEL Paketen im SL75 eigentlich keine Rolle spielen. Ich wollte es dennoch erwähnen.
Feature-Requests
1. ENUM
Das ist ein Feature, dass ich schmerzlich vermisse. Denn mit ENUM lassen sich Anrufe, die normalerweise über das Gateway des VoIP-Providers gehen würden, automatisch in einen IP-to-IP Call umwandeln, wenn die gewählte Zielrufnummer über einen solchen ENUM-Eintrag verfügt. Dabei kann die gewählte Nummer sogar eine normale Festnetznummer sein und würde trotzdem auf dem VoIP-Phone des Angerufenden rauskommen als direkter IP-to-IP Call. Dafür braucht der Angerufende noch nicht einmal eine VoIP CallIn Nummer
. Dadurch würde sich die Sprachqualität erheblich verbessern, weil der Anrufe eben nicht über VoIP-Gateways und das normale Telefonnetz geroutet werden müsste, abgesehen davon, dass der Anruf kostenlos würde
. Insbesondere ist neben der offiziellen e164.arpa Domain auch Support der e164.org Domain wünschenswert, weil sich hier jeder Privatanwender gegen eine geringe und sogar freiwillige Spende einen ENUM Eintrag machen kann. Auf diese Weise kann man sich als Endbenutzer dann selbst darum kümmern, möglichst viele Ziele per VoIP erreichen zu können, und wäre nicht darauf angewiesen, dass VoIP-Provider entsprechende Gateways untereinander einrichten.
2. Umschaltung des Sprachcodecs am Mobilteil
Ich vermisse am Mobilteil die Möglichkeit, den bevorzugten Sprachcodec umzuschalten. Ich würde gern die Option haben, vor dem Gespräch auf einfache Weise zwischen G.711 und G.723 umschalten zu können, je nachdem wie "ausgelastet" mein Internetzugang gerade ist. Geht jedoch leider nur über das Webinterface.
3. DTMF Out-of-Band
Die DTMF Unterstützung beschränkt sich derzeit auf "Inband" und ist daher recht unzuverlässig. Eine pro Profil wählbare Unterstützung von Out-of-Band nach RFC2833 (AVT Tone) bzw. RFC2976 (SIP INFO) würde nicht schaden.
4. Rufnummernübermittlung abschaltbar
Ein Menüpunkt zum Ab-/Wiedereinschalten der Rufnummernübermittlung
5. "Blindschirmschoner" abschaltbar
Bitte eine Option, bei der im Standby nur die Hintergrundbeleuchtung des Display ausgeht, aber die Infos im Display sichtbar bleiben.
6. Einstellung, ob Outbound-Proxy bei IP-to-IP Calls verwendet werden soll
Wie ich oben schon sagte, es gibt viele Situationen, bei denen der verwendete VoIP-Provider die Angabe eines separaten Outbound-Proxy erfordert, aber dann keine IP-to-IP Calls weiterroutet. Wer dann mit so einem Provider gesegnet ist, der muss für IP-to-IP Calls dann extra in ein anderes Profil wechseln. Das nervt
Ein Schalter, ob IP-to-IP Calls den Proxy nehmen sollen, wäre daher sinnvoll.
SL75WLAN.jpg
