VoIP mit Android 2.3

[DroidLeo]

Jetzt wart ich mal auf meine ersten Anruf-Tests, wie die Sprachquali ist und ob es auch einwandfrei in anderen WLAN-Netzen funktioniert

Komisch, unter +4912312345 geht keiner dran

 

[BlueMonkey]

Komisch, unter +4912312345 geht keiner dran

Hab mich leider zu früh gefreut... es kommt zwar eine Verbindung zu Stande, aber leider gibt's keinen Ton Morgen mal weiter probieren, ob ich das irgendwie hinbekomm :/

 

[BlueMonkey]

Hab es zur Abwechslung mal mit CSipSimple probiert - anfangs mit dem selben Ergebnis.

Hab dann mal ein wenig weiterrecherchiert. Für den Desktop-SIP-Client legt 1&1 die Ports von 5060 auf 5070. Dort heißt es auch:

Information:
Der SIP-Standardport 5060 ist für die 1&1 Surf & PhoneBox vorbehalten und kann nicht freigegeben werden.

Also hab ich mal alles auf Port 5070 umgestellt und die entsprechenden Ports in der Fritzbox freigegeben: "Request Timeouts"... Immer noch nix

Um auszuschließen, dass die Firewall der Fritzbox Schuld ist, habe ich dann mal bei der Portfreigabe mein Nexus S als "Exposed Host" eingetragen, sprich die Firewall für das Smartphone deaktiviert. Und siehe da: Über CSipSimple habe ich über Port 5060 sofort eine SIP-Anmeldung bekommen und auch erfolgreich telefoniert (Ohne "Exposed Host" habe ich wieder das Problem, dass er sich zwar anmeldet, beim Telefonieren allerdings kein Ton übermittelt wird).

Also müsste es ja dann auch über das interne Android-SIP gehen - und das hat es dann auch (Port 5060). Allerdings kam bei meinem Gegenüber nichts an und bei mir war die Sprachqualität auch eher schlecht

Ich weiß nicht warum die Umleitung über Port 5070 nicht funktioniert - entweder ich mach da was falsch im Fritzbox-Menü oder das mag einfach nich

Ende der Geschichte: Ich nutze jetzt erst einmal bis auf weiteres CSipSimple

 

[bemymonkey]

Mal was Anderes: Habt Ihr auch gerade Probleme mit 1&1 SIP? 1&1 SoftPhone sagt ab und zu, er koennte den STUN Server nicht erreichen, und PBXes meint, meine 1&1 Leitungen wuerden nicht existieren...

 

[BlueMonkey]

Im Nexus-S-Forum (Thread VoIP/SIP support ) hat ahcsas eine kleine Anleitung geschrieben, bei der die fritz.box dem Smartphone als SIP-Server dient (geht dann also nur im heimischen WLAN):

Ist eigentlich ganz einfach...

zunächst in der Box unter Telefonie -> Telefoniegeräte ein neues Telefon hinzufügen. Als Anschluss LAN/WLAN auswählen und den Assistenten durchklicken. Das Telefon bekommt eine Nummer ab 620 aufsteigend zugewiesen.

Am Nexus S dann unter Einstellungen -> Anrufeinstellungen -> Konten ein neues Konto anlegen. Als Nutzername die 620 (bzw. was halt zugewiesen wurde) eintragen. Passwort was ihr in der FritzBox vergeben habt und als Server fritz.box

Das sollte eigentlich schon reichen. Würde mich freuen wenn ihr mal testen könntet, ob ihr dann auch die Störungen beim Empfang habt.

Mit der FritzApp funktionierts übrigens einwandfrei. Es liegt also nicht an der WLAN-Verbindung.

Hat bei mir sofort funktioniert, aber ich verstehe auf diese Weise mein Gegenüber nicht wirklich gut. Bei meinem Gegenüber scheint die Sprachqualität dagegen zu passen - sprich auch bei mir kommt es zu den von ahcsas angemerkten Empfangsstörungen.

 

[devzero]

Gibts mit der CSipSimple Software eine Möglichkeit den Registrierungsverlauf mitloggen zu lassen? Weil "not found" kann viel sein, was der nicht findet, obs der Server, der User, die Domain etc ist steht ja nicht....

 

[xdowner]

weis einer wie man eine telefon nummer als internet anruf deklarieren kann? mit #* oder irgend welche sonderzeichen? habe die einstellung gewählt "nur für internet anrufe" nun will ich aber eine festnetz nummer über sip anrufen. kann ich jetzt irgend wie die festnetz nummer als internet anruf deklarieren damit er das telefonat über die datenleitung schickt ohne das ich in den einstellungen ändern muss "für alle anrufe" ?

 

[bemymonkey]

Soweit ich weiss gilt als Internetanruf nur einer, der über einen vorhandenen Kontakt gewählt wird, und zwar muss der Kontakt eine explizite "internet calling" Nummer eingetragen haben.

 

[d666]

Bei mir saugt es den Akku mit aktiviertem VOIP (mit eingehende Anrufe annehmen) innerhalb von 5 Stunden leer, ohne dass ich irgendwas mit dem Telefon mache...

Benutze CyanogenMod7 -05092011 Nightly auf dem ZTE Balde.
Mit anderem ROM und Fring als VOIP App hielt es mindestens doppelt so lange!

Hat noch wer das Problem, wird daran gearbeitet?

Viele Grüße D666

Kann ja auch sein, dass das einfach nur an den CyanogenMod7 Nightlies liegt... ich bin auch scheinbar der Einzige, der das bis jetzt bemerkt hat. Vlt. geht's mit anderen ROMs besser...

Aber Sipdroid läuft auch auf Gingerbread immer noch fantastisch

 

[bemymonkey]

Ich hatte direkt bei Einführung von CyanogenMod7 einen Issue auf dem Bugtracker eröffnet, und seitdem wurden erst ~5 "Sterne" hinzugefügt, weil's wohl keinen interessiert. Dementsprechend wird auch nichts mehr dran gemacht...

Bei den auf der Seite liegenden Pfeiltasten beim Anschluss einer Bluetoothtastatur ist's genau das Selbe. Die, die in der Lage wären, es zu reparieren, interessiert es leider einfach nicht, und die Leute, die's interessiert, schaffen's nicht das mal in den Bugtracker zu schreiben.

 

[cyorps]

Das doofe ist ja, dass scheinbar außer Sipdroid, niemand per TCP mit pbxes.org kommunizieren kann. Ich habe es jedenfalls weder mit cSipSimple, noch mit dem in Gingerbread enthaltenen SIP hinbekommen.

Ja, das ist vollkommen korrekt. Denn bislang ist mir kein Provider bekannt, der das TCP-Protokoll zulässt. Pbxes als middle-carrier ist der Einzige der dieses Protokoll unterstützt. Ich finde das nicht weiter schlimm, da der TCP/UDP-Glaubenskrieg zu hoch gekocht wird und letztendlich in Sachen Akkuleistung kaum ein Unterschied zu merken ist. Diese Option ist aber beim nativen VOIP-Client prinzipiell dabei. Denn da ich jetzt auf GB gewechselt bin, habe ich etliche Roms wie den über Samfirmwares + Nativen VOIP-Client aus dem XDA-Forum; Cyanogen; DocsKitchen und jetzt Darky ausprobiert. Alle haben in den erweiterten Optionen diese Einstellmöglichkeit an Bord.

Insgesamt bin ich vom nativen Client angetan. Er ist gut ins System intergriert, man sieht und hört nichts von ihm, bis er gebraucht wird und saugt nicht übermäßig am Akku. Allerdings dauert mir der Reconnect noch zu lange. Daher meine Frage: Hat schon jemand von euch mit den erweiterten Optionen handtiert? Vor allem interessiert mich, ob eine Umstellung bei "Send keep-alive" von "automatisch" auf "immer senden" Abhilfe brachte und wie sehr dies am Akku saugt?

 

[bemymonkey]

Ich finde das nicht weiter schlimm, da der TCP/UDP-Glaubenskrieg zu hoch gekocht wird und letztendlich in Sachen Akkuleistung kaum ein Unterschied zu merken ist.

Hast Du mal gemessen? Bei mir ist's im normalen Betrieb das 8-Fache an Verbrauch... UDP (egal welcher Client) ca. 40mA, TCP ca. 5mA. Also schon ein RIESEN Unterschied - im reinen Standby mit nem 1200mAh Akku 240h vs. 30h...

Diese Option ist aber beim nativen VOIP-Client prinzipiell dabei.

Man kann zwar auf TCP umstellen, aber mit PBXes.org richtig zusammen spielen tut's trotzdem nicht

 

[cyorps]

Hast Du mal gemessen?

Nein, denn ich kenne nur zwei Apps (Currentwidget und äh...glaube...Powertutor) mit denen man die Leistungsaufnahme messen kann. Beide zeigen beim SGS keine Werte an. Daher vermute ich, dass diese Messfunktion vom Kernel nicht unterstützt wird. Mit was misst du denn die Leistungsaufnahme?

Ich kann es eben nur gefühlt sagen. Denn ich hatte das mit sipdroid mehrmals getestet. Das sah so aus: Eine, später als es möglich war, zwei Leitungen die ständig am Netz hingen und geschaut, wie sich der Leistungshunger zwischen den Protokollen bemerkbar macht. Ich spürte da einen Unterschied von 5% der Akkuleistung. Und ja! Ich habe darüber auch telefoniert.

Man kann zwar auf TCP umstellen, aber mit PBXes.org richtig zusammen spielen tut's trotzdem nicht

Heul! Wieso konnten wir das Gespräch nicht vor dem Wochenende, bevor ich in pbxes die komplette Konfiguration gelöscht hatte, führen! Nein, das kann ich nicht bestätigen. Bei mir funktioniert es Ein-/Ausgehend ~ WLAN/mobiles Datennetz mit folgender Konfiguration:

Username: Nebenstellenuser bei pbxes
Passwort: Passwort Nebenstellenuser
Server: pbxes.org

 

[bemymonkey]

Nein, denn ich kenne nur zwei Apps (Currentwidget und äh...glaube...Powertutor) mit denen man die Leistungsaufnahme messen kann. Beide zeigen beim SGS keine Werte an. Daher vermute ich, dass diese Messfunktion vom Kernel nicht unterstützt wird. Mit was misst du denn die Leistungsaufnahme?

Ich nehme dazu BatteryMonitorWidget, aber der liest soweit ich weiss genau die gleichen Dateien aus wie CurrentWidget... diese sind halt beim SGS scheinbar leider nicht vorhanden.

Ich kann es eben nur gefühlt sagen. Denn ich hatte das mit sipdroid mehrmals getestet. Das sah so aus: Eine, später als es möglich war, zwei Leitungen die ständig am Netz hingen und geschaut, wie sich der Leistungshunger zwischen den Protokollen bemerkbar macht. Ich spürte da einen Unterschied von 5% der Akkuleistung. Und ja! Ich habe darüber auch telefoniert.

Der Unterschied zw. UDP und TCP ist gerade beim *nicht* telefonieren markant. Leg das Gerät mal 12 Std. auf die Fensterbank mit UDP (egal welcher Client) und 12 Std. mit TCP (mit Sipdroid & PBXes) - bei UDP ist der Akku zur Hälfte leer, und bei TCP noch 90-95% drin .

Heul! Wieso konnten wir das Gespräch nicht vor dem Wochenende, bevor ich in pbxes die komplette Konfiguration gelöscht hatte, führen! Nein, das kann ich nicht bestätigen. Bei mir funktioniert es Ein-/Ausgehend ~ WLAN/mobiles Datennetz mit folgender Konfiguration:

Username: Nebenstellenuser bei pbxes
Passwort: Passwort Nebenstellenuser
Server: pbxes.org

Hi, Anrufe gehen, ja, aber mit "richtig funktionieren" meinte ich auch eine brauchbar niedrige Stromaufnahme, d.h. für mich vernachlässigbar wenig im Vergleich zu komplett ohne SIP-Client... denn ein SIP-Client, der im Laufe des Tages 20-40% des Akkus alleine wegsaugt, funktioniert meines Erachtens nicht so wirklich

 

[cyorps]

Ok! Und der Unterschied zwischen TCP und UDP sowie Native und Sipdroid schlägt sich so deutlich im Messergebnis wieder?

 

[bemymonkey]

Ja, wirklich mehr als deutlich. Wie gesagt, 5mA vs. 40mA bei TDP vs. UDP...

Native ist allerdings so ne Sache - bei CM7 (ich nutze nichts Anderes) aufm Desire hat der Native Client eine Macke, und saugt im Standby mal schnell 200mA (das entspricht in etwa dem Stromverbrauch beim aktiven Surfen mit eingeschaltetem Display)... müsste die Tage nochmal testen, ob sich das geändert hat.

 

[cyorps]

Schade, dass das SGS die Leistungsaufnahme nicht misst. Denn prinzipiell schenke ich dir VOIP-Guru immer Glauben. Doch meine eigene Erfahrung verweigert es mir diese Tatsache zu akzeptieren. Denn jetzt mit den nativen Klienten habe ich alle meine vier VOIP-Nummern gleichzeitig via UDP Online und wundere mich über den trotzdem erträglichen Akkuverbrauch.

Obwohl ich sagen muss, dass ich wegen den unklärlich hohen Akkuverbrauch von CM7 auf dem SGS zu einem anderen CustomRom gewechselt bin. Und da hatte ich den VOIP-Client noch nicht einmal konfiguriert und gestartet.

 

[bemymonkey]

Mit dem nativen Client kann ich wegen dem oben erwähnten Bug schlecht gegentesten, aber sobald ich jetzt Sipdroid auf UDP umschalte, steigt der Akkuverbrauch enorm.

Ich muss auch natürlich sagen, dass es vlt. auch sehr hardwareabhängig ist. Bei UDP wird halt die CPU wach gehalten... kann sein dass die Samsung CPU im SGS da im Low-Power-State effizienter ist, und man es deswegen da nicht so sehr merkt.

Ich kann halt auch nur von meinen Erfahrungen reden, und die beziehen sich dummerweise auch nur auf 2 Geräte... d.h. es muss keineswegs für alle gelten

 

[cyorps]

Ich überlege schon wirklich, ob ich in den nächsten Tagen mal zu unseren "Strippenziehern" gehe, das SGS an einem Voltmeter hängen lassen und die Geschichte mal teste. Denn du hast mich jetzt absolut neugierig auf die Werte gemacht.

By the Way. Zum Komplettbackup vom System (wird ja bei HTC auch funktionieren) und zur testweisen Installation eines anderen ROMs ohne VOIP-Bug, werde ich dich wohl nicht bewegen können!?!

 

[bemymonkey]

Vlt. in ein paar Wochen... aktuell zu viel um die Ohren, komme kaum dazu neue Nightlies draufzuklatschen