‎Hometalk App / SIP-Client stört IP-Telefonie über Speedport 921V

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Hometalk App / SIP-Client stört IP-Telefonie über Speedport 921V

vor 11 Jahren

Hallo,

Ich habe folgenden Aufbau:
- DSL nach Annex J mit VoIP-Telefonie
- Router Speedport W 921V mit ISDN-Telefon an internem S0
- Galaxy i9300 mit HomeTalk App
- Sony Xperia Tipo mit Standard SIP-Client ohne extra App (siehe http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/FAQ/theme-45859561/Telefonie/theme-45859560/Anschluss-und-Tarife/theme-45859549/Telefonieren-und-Surfen/theme-82239611/IP-basierter-Anschluss/faq-350884716)

Das Fehlerbild:
Ich telefoniere mit einem ISDN-Telefon über den Speedport. Wenn sich nun währenddessen ein SIP-Client von einem Smartphone registriert, sodass es auch eingehende Anrufe annehmen kann, bricht das Telefongespräch ab. Wenn nun der Gesprächsteilnehmer am anderen Ende innerhalb von ein paar Minuten zurückruft, klingelt nur das soeben registrierte SIP-Client-Smartphone jedoch kein ISDN-Telefon am Speedport. Einige Zeit später klingeln die ISDN-Telefone allerdings wieder.

Das genannten Problem habe ich als Störung gemeldet, allerdings meinte die Dame von der Hotline heute, dass die gleichzeitige Verwendung von IP-Telefonie über den Speedport und einen SIP-Clients (wie die HomeTalk App) nicht unterstützt würde. Meinem Wissen nach wird aber die Mehrfachanmeldung verschiedener SIP-Clients an einer Telefonnummer unterstützt. (Ansonsten würde die offizielle App wohl auch kaum Mehrwert bringen.)

Daher zwei Fragen:
1. Wird dieser Anwendungsfall (Telefonie über Speedport und weitere SIP-Clients parallel) seitens Telekom unterstützt?
2. Kennt jemand eine Lösung für das Problem?

Hinweis:

Dieser Beitrag wurde geschlossen.

Hinweis:

Dieser Beitrag ist nicht mehr für Antworten oder Kommentare geöffnet und ist nicht mehr für die Mitglieder der Community sichtbar.

2289

vor 11 Jahren
Es ist ein bekanntes Problem, dass offenbar die derzeitige HomeTalk App die Telefonie stört. Es gibt dazu auch einen Thread.

Bisher war es aber nicht so, dass hereinkommende Gespräche gestört wurden.

Zudem: Ist es bei Dir aber wirklich so, dass auch wenn die HomeTalk App lahmgelegt wurde ein "normaler" SIP-Client ausreicht, dieses Fehlerverhalten an den am Speedport angeschlossenen Telefonen zu produzieren?

https://forum.telekom.de/foren/read/service/mobile-nutzung/apps/sporadischer-gespraechsabbruch-o-abgehende-telefonie-geht-nicht,896,11240152.html
0
vor 11 Jahren
Ja, der Basis-SIP-Client von Android reicht aus, um die Gespräche über den Speedport zu stören. Auf einem Smartphone ist die HomeTalk App gar nicht installiert und ich kann damit die Gespräche in praktisch 100% der Fälle abschießen.

Das Spielchen funktioniert auch zwischen den Smartphones. Wenn ich mit einem SIP-Client eines Handys ein VoIP-Gespräch führe und der andere sich währenddessen registriert, bricht es auch ab.

So gesehen kann das Problem eigentlich nicht an der HomeTalk App liegen.
0
vor 11 Jahren
Tritt das Problem auch mit non-Android SIP Clients auf? Zum Beispiel mit PhonerLite?

Mir ist nämlich heute auch aufgefallen, dass sich der in Android integrierte SIP Client meines HTC One M8 auffällig aggressiv verhält und ständig SIP Requests ins Netz schickt (und zwar im Millisekunden Takt). Das könnte der SIP Server ggf. als Angriff interpretieren und macht dann kurzerhand die Leitung dicht. Das ganze ähnelt der Problematik, die es aktuell mit der Hometalk App gibt, ist aber anders gelagert.

Gesprächsabbrüche im laufenden Gespräch habe ich zwar dadurch noch nicht gehabt, aber spätestens nach Gesprächsabbau war kein Verbindungsaufbau mehr möglich (SIP Response 403). Schalte ich WLAN an meinem Androiden aus, läuft nach einigen Minuten wieder alles wie gehabt.
0
vor 11 Jahren
Hallo Incognitus1,

So gesehen kann das Problem eigentlich nicht an der HomeTalk App liegen.

So gesehen kann das Problem eigentlich nicht an der HomeTalk App liegen.

So gesehen kann das Problem eigentlich nicht an der HomeTalk App liegen.

Doch, genau da liegt der Hund begraben. Der Fehler ist bereits gemeldet, die Entwickler wissen bescheid.

Viele Grüße
Ina
0
vor 11 Jahren
Dann wäre es vielleicht sinnvoll, die neueste Version der Hometalk-App wieder vom Markt zu nehmen - der Vorgänger hat ja einwandfrei funktioniert !
0

vor 11 Jahren

Es ist ein bekanntes Problem, dass offenbar die derzeitige HomeTalk App die Telefonie stört. Es gibt dazu auch einen Thread. Bisher war es aber nicht so, dass hereinkommende Gespräche gestört wurden. Zudem: Ist es bei Dir aber wirklich so, dass auch wenn die HomeTalk App lahmgelegt wurde ein "normaler" SIP-Client ausreicht, dieses Fehlerverhalten an den am Speedport angeschlossenen Telefonen zu produzieren?

Wenn zuviel falscher IP Verkehr an den SIP Proxy gesendet wird (z.B. STUN Anfragen), dann macht der einfach kurz dicht. Wenn dann REGISTER Anfragen nicht beantwortet werden, ist die Nr. natürlich nicht mehr registriert und deshalb auch nicht mehr ankommend erreichbar.
Ausserdem kann auch der Router dann von sich aus noch laufende Gespräche beenden.

Die HomeTalk App ist sicherlich nicht die einzigste Software die die Störung erzeugt. Aber auf diese hat die Telekom wenigsten Einfluss und kann den Fehler beheben.

vor 11 Jahren
Klar, wenn der wirklich beleidigt reagiert, dann geht weder rein noch rausgehend etwas.

Wichtiger war mir, dass offenbar auch andere VoIP-Clients als HomeTalk Probleme bereiten.
Was läuft denn da mit dem Telekom-Server schief, dass sich die Kommunikation so hochschaukelt? Vielleicht ist es ja nur zum Teil das Problem der jeweiligen App. Vielleicht triggert der Telekomserver irgendwie solch ein Verhalten.

Denn wenn die Server anderer VoIP-Provider im Zusammenspiel mit den VoIP Apps solche Probleme produzieren würden, dann wären die VoIP Apps garantiert schon fehlerbereinigt.

Deshalb meine aktuelle Vermutung:
Der Telekom Server hat auch ein Problem - nicht nur die HomeTalk App und andere VoIP Apps.
0
vor 11 Jahren
Mein Ticket wurde anscheinend heute Morgen einfach so ohne Nachfrage geschlossen.

Hier man schnell die Historie:
- Ticket am 28.5 . erstellt
- Anruf der Hotline am 3.6. mit der Aussage: "...ist kein Fehler. Telefonie mit Speedport und SIP-Client zugleich wird nicht unterstützt." Veto meinerseits
- 5.6. Techniker ruft morgens auf Festnetz an, obwohl extra Rückruf auf Handynummer gewünscht wurde. Aussage: Techniker ruft abends um 18:00 Uhr zurück
- 5.6. 18:00 Uhr kein Anruf eines Technikers
- 5.6. 20:00 Uhr Ich rufe wieder bei Hotline an - 20 min in Warteschlange. Durchstellen zu Techniker nicht möglich - angeblich alle beschäftigt. Zusage: Rückruf am 6.6. 18:00 Uhr auf Handy.
- 6.6. 11:45 Uhr Ticket wird ohne Rückfrage und Behebung des Problems geschlossen
- 6.6. 18:00 Uhr: Kein Rückruf von der Telekom. Ich versuche mit ISDN-Telefon zu telefonieren, aber Gespräch kann nicht aufgebaut werden. (Speedport meldet SIP-Fehler 404) Ich probier die HomeTalk App, die sich seit 30min nicht registrieren kann...

Wenn das kein Negativbeispiel ist...

Ganz zu schweigen davon, dass es das dritte Ticket in drei Wochen war und wohl gleich das nächste werde anlegen müssen.
0
vor 11 Jahren
@Incognitus1

Das Telekom Team hat doch geschrieben, daß der Fehler bekannt ist und zur Zeit daran gearbeitet wird. Es ist also kein Fehler der nur dich betrifft. Bis zur Behebung hilft nur die App nicht dauerhaft zu benutzen. Wieder ein Ticket zu erstellen wird zu dem selben Ergebnis führen.

@MUC
Wenn du einem Server Unsinn schickt muss er diesen trotzdem verarbeiten um zu erkennen das es eben Unsinn ist. Um sich vor Angriffen zu schützen, muss er eben die Verarbeitung einstellen um nicht überlastet zu werden. Wie will er sich sonst schützen?
Der Unsinn sollte normalerweise nicht von gut programmierter Software kommen. Sollte dann also auch eher die Ausnahme sein.

Andere professionelle VOIP Server haben bestimmt ähnliche Funktionen aktiv, sonst wären diese ja sofort tot bei einem Angriff.
0

vor 11 Jahren

@muc Wenn du einem Server Unsinn schickt muss er diesen trotzdem verarbeiten um zu erkennen das es eben Unsinn ist. Um sich vor Angriffen zu schützen, muss er eben die Verarbeitung einstellen um nicht überlastet zu werden. Wie will er sich sonst schützen? Der Unsinn sollte normalerweise nicht von gut programmierter Software kommen. Sollte dann also auch eher die Ausnahme sein. Andere professionelle VOIP Server haben bestimmt ähnliche Funktionen aktiv, sonst wären diese ja sofort tot bei einem Angriff.

Wir wissen bisher nur, dass es ein Fehlverhalten gibt. Zuerst sah es so aus, als ob die HomeTalk App einen Fehler hat. Jetzt stellen wir fest, dass auch andere VoIP Clients das Problem mit dem Telekomserver produzieren. Das bedeutet zunächst, dass man das Zusammenspiel analysieren muss. Du greifst der Lösung vor, indem Du von vorneherein den Fehler den Clients zuschiebst. Das muss aber nicht sein. Ich stecke da technisch in den Protokollen allerdings nicht drin. Vielleicht erwartet der Client ja irgendwie eine Response, die aber vom Telekomserver nicht kommt, weshalb er dann ganz verzweifelt immer wieder anfragt.

Bei Interworking/Interoperabilityproblemen muss man immer beide Implementierungen anschauen.

vor 11 Jahren
@ voiper08:
Mir ging es nicht nur um den Fehler, sondern darum, dass der Service mehrmalig Zusagen nicht eingehalten hat. Außerdem sollte ein Ticket doch erst geschlossen werden, wenn das Problem behoben ist und nicht schon, wenn ein Fehler nur an eine Fachabteilung gemeldet wurde.
0

vor 11 Jahren

Tritt das Problem auch mit non-Android SIP Clients auf? Zum Beispiel mit PhonerLite?

Mir ist nämlich heute auch aufgefallen, dass sich der in Android integrierte SIP Client meines HTC One M8 auffällig aggressiv verhält und ständig SIP Requests ins Netz schickt (und zwar im Millisekunden Takt). Das könnte der SIP Server ggf. als Angriff interpretieren und macht dann kurzerhand die Leitung dicht. Das ganze ähnelt der Problematik, die es aktuell mit der Hometalk App gibt, ist aber anders gelagert.

Gesprächsabbrüche im laufenden Gespräch habe ich zwar dadurch noch nicht gehabt, aber spätestens nach Gesprächsabbau war kein Verbindungsaufbau mehr möglich (SIP Response 403). Schalte ich WLAN an meinem Androiden aus, läuft nach einigen Minuten wieder alles wie gehabt.

Ich habe inzwischen auch den Client PhonerLite ausprobiert. Oft kann er sich nicht registrieren, ab und zu vorübergehend aber seltsamerweise doch. (Ich ändere zwischendurch natürlich nichts an den Einstellungen.)
Ein Telefoniegespräch aufbauen konnte ich damit bisher allerdings noch nie. Es kommt jeweils zu einem der folgenden SIP-Fehlercodes:
404 Not Found
408 Request Timeout
486 Busy Here
Die Fehlercodes 404 und 486 deuten daraufhin, dass der Anschluss belegt ist oder die gewählte Nummer nicht existiert, was aber definitiv nicht stimmt.

Auf jeden Fall ist der Standard-Android-Client der einzige, mit dem ich bisher immer eine Verbindung aufbauen konnte.
Wenn Android-Client sich besonders "aggressiv" verhielte, würde man doch im Gegenteil erwarten, dass der Server genau diesen Client blockt. Es spräche ja nicht für die Firewall des Servers, wenn sie die "friedlichen" Clients wie Speedport, PhonerLite usw. mitunter abwiese und ausgerechnet den "bösen" Android-Client anstandslos bediente.

vor 11 Jahren

Ich habe inzwischen auch den Client PhonerLite ausprobiert. Oft kann er sich nicht registrieren, ab und zu vorübergehend aber seltsamerweise doch.

Mit diesen Einstellungen sollte eine Registrierung und dann auch die Telefonie erfolgreich funktionieren:

https://forum.telekom.de/foren/read/service/internet-festnetz/telefonie/keine-verbindung-von-softphone-clients,439,11223968,11223970.html?#msg-11223970

Wenn Android-Client sich besonders "aggressiv" verhielte, würde man doch im Gegenteil erwarten, dass der Server genau diesen Client blockt. Es spräche ja nicht für die Firewall des Servers, wenn sie die "friedlichen" Clients wie Speedport, PhonerLite usw. mitunter abwiese und ausgerechnet den "bösen" Android-Client anstandslos bediente.

Der Server blockt nicht einen Client, sondern den Verkehr den eine IP Adresse erzeugt. Den Fehler den die HomeTalk App hat, haben die Speedport Clients nicht. In der PhonerLite Software kann man den Fehler auch reinkonfigurieren. Dann ist der Fehler genauso vorhanden. Leider sind die fehlerhaften Einstellungen in der HomeTalk App nicht veränderbar. Das wäre ja zu einfach.

Dem Server bzw. der Logik des Blockierens ist es egal welcher und wieviel Clients hinter einer IP Adresse stecken. Wenn er blockt, blockt er alles von dieser einen IP Adresse (sonst wäre das Blockieren ja nicht effektiv). Deshalb sind dann auch friedliche Clients mitbetroffen, wie z.B. der Speedport selber.

vor 11 Jahren

Mit diesen Einstellungen sollte eine Registrierung und dann auch die Telefonie erfolgreich funktionieren:

https://forum.telekom.de/foren/read/service/internet-festnetz/telefonie/keine-verbindung-von-softphone-clients,439,11223968,11223970.html?#msg-11223970

Ich hatte die Einstellungen von PhoneLite schon so gesetzt, aber damit tritt wie beschrieben der SIP-Fehler 404 bei ausgehenden Gesprächen auf. (andere Clients bis auf Speedport deaktiviert)

Der Server blockt nicht einen Client, sondern den Verkehr den eine IP Adresse erzeugt. Den Fehler den die HomeTalk App hat, haben die Speedport Clients nicht. In der PhonerLite Software kann man den Fehler auch reinkonfigurieren. Dann ist der Fehler genauso vorhanden. Leider sind die fehlerhaften Einstellungen in der HomeTalk App nicht veränderbar. Das wäre ja zu einfach.

Dem Server bzw. der Logik des Blockierens ist es egal welcher und wieviel Clients hinter einer IP Adresse stecken. Wenn er blockt, blockt er alles von dieser einen IP Adresse (sonst wäre das Blockieren ja nicht effektiv). Deshalb sind dann auch friedliche Clients mitbetroffen, wie z.B. der Speedport selber.

Ich würde der These mit der Firewall zustimmen, wenn sie erklären würde, warum ich dann trotzdem jedesmal mit dem Standard-Android-Client ausgehend wie eingehend telefonieren konnte. Im Falle einer vorübergehenden Blockierung der IP-Adresse könnte auch dieser Client nichts mehr ausrichten.

vor 11 Jahren

Ich hatte die Einstellungen von PhoneLite schon so gesetzt, aber damit tritt wie beschrieben der SIP-Fehler 404 bei ausgehenden Gesprächen auf. (andere Clients bis auf Speedport deaktiviert)

Wenn nur PhonerLite als einziger Client aktiv ist, stört natürlich auch nichts.
Ich habe den Fehler 404 auch bekommen. Bei war dann im Reiter "Server" der Haken bei Registrierung nicht aktiv. In der Statuszeile ganz unten war angeblich die Nummer erfolgreich registriert. Dort steht "sip:012345667@11.22.33.44(meine IP Adresse) registriert".

Wenn ich den Haken aktiviere steht in der Statuszeile aber: "sip:012345667@tel.t-online.de registriert".
Dann klappt es bei mir wieder auch mit dem Telefonieren.

Ansonsten kannst du mal in den Debug-Modus (Hilfe/Debug) schauen, ob deine Register erfolgreich sind und welche Meldung genau bei den abgehenden Telefonaten zurückkommt.

Im Falle einer vorübergehenden Blockierung der IP-Adresse könnte auch dieser Client nichts mehr ausrichten.

So sollte es sein. Warum dem wohl so nicht ist, kann ich in meiner Glaskugel nicht sehen.

vor 11 Jahren
Ich habe die Einstellungen in PhonerLite wie beschrieben vorgenommen. Ich sehe im Wireshark-Trace folgendes: Zuerst schickt PhonerLite lange REGISTER-Requests, die der Server mit SIP-Code 401 abweist. Irgendwann kommt ein OK vom Server zurück. Status ist dann "sip:XXXXXXXXX@tel.t-online.de registriert"

Die Sequenz des Rufaufbaus:
-> INVITE-Request (1169 Byte)
<- Status 401 Unauthorized
-> ACK-Request
-> INVITE-Request (1427 Byte)
<- Status 100 Rufaufbau
<- Status 407 Login notwendig
-> ACK-Request
-> INVITE-Request (1514 Byte, fragmentiert)
<- Status 100 Rufaufbau
<- Status 404 Rufnummer nicht bekannt/unterstützt
-> ACK-Request
0
vor 11 Jahren
Das sieht alles normal aus, wie es auch sein soll.
Kommt denn der Fehler bei allen Telefonnummern die du wählst ?

Also es ist schon merkwürdig, daß es nur mit der PhonerLite Software nicht geht.

Du kannst ja mal die komplette SIP 404 Meldung posten, evtl. kommt dann etwas Licht ins dunkel.

Manchmal habe ich auch das Gefühl die Software spinnt, da ich eigentlich alles richtig gemacht habe, und trotzdem kommen ominöse Fehler. Mit anderer Software, Geräten oder Tage zuvor klappt(e) es dann mit den gleichen Einstellungen...

Du kannst auch versuchen unter Server den Proxy fest einzustellen. Versuch mal 217.0.18.16 ob sich dann etwas ändert.
0
vor 11 Jahren
Das Problem tritt mit allen Nummern auch, die ich probiert habe. (Festnetz mit und ohne Vorwahl, Handy, Servicenummern...)
Hier die SIP-Message 404 aus PhonerLite, wenn ich tel.t-online.de als Proxy setze: (Meine Nr ist ersetzt)

17:42:25,614: R: 217.0.19.163:5060 (UDP)
SIP/2.0 404 Zielrufnummer nicht bekannt oder nicht unterstÃ¼tzt. (23)
Via: SIP/2.0/UDP 192.168.2.123:5060;rport=5074;branch=z9hG4bK8046932648f2e311a147ab85d114501f
To: <08003301000>;tag=96250832
From: 004971XXXXXX <004971244215>;tag=2330387114
Call-ID: 80469326-48F2-E311-A143-AB85D114501F@192.168.2.123
Contact:
CSeq: 14 INVITE
Content-Length: 0

Ich habe wie vorgeschlagen als Proxy nun manuell 217.0.18.16 eingetragen und damit scheint es zu funktionieren. Per DNS wird mir gerade 217.0.19.163 zugewiesen. Auch wenn ich manuell diese IP eingebe anstatt des DNS-Namens kann ich nicht telefonieren.
Ich führte daraufhin auf beide IP-Adressen ein traceroute durch mit signifikantem Unterschied:

Routenverfolgung zu 217.0.19.163 über maximal 30 Abschnitte

1 <1 ms <1 ms <1 ms speedport.ip
2 20 ms 20 ms 19 ms 217.0.117.181
3 25 ms 22 ms 21 ms 87.186.197.114
4 31 ms 30 ms 31 ms l-ea3-i.L.DE.NET. DTAG .DE
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.

Routenverfolgung zu 217.0.18.16 über maximal 30 Abschnitte

1 1 ms <1 ms <1 ms speedport.ip
2 20 ms 19 ms 20 ms 217.0.117.181
3 22 ms 23 ms 22 ms 87.186.197.118
4 28 ms 27 ms 28 ms s-ea4-i.S.DE.NET. DTAG .DE
5 30 ms 29 ms 29 ms 193.159.158.26
6 28 ms 27 ms 27 ms 217.0.18.16
0

vor 11 Jahren

Hier die SIP-Message 404 aus PhonerLite, wenn ich tel.t-online.de als Proxy setze: (Meine Nr ist ersetzt) 17:42:25,614: R: 217.0.19.163:5060 (UDP) SIP/2.0 404 Zielrufnummer nicht bekannt oder nicht unterstÃ¼tzt. (23) To: <08003301000>;tag=96250832 From: 004971XXXXXX <004971xxxx>;tag=2330387114

Also ich habe es bei mir genauso eingestellt, und bei mir tut es mit der selben Proxy IP Adresse und auch im Format der 004971... Telefonnr. beim register.
Evtl. liegt es an dem Format. Versuch mal 071... oder +4971...
die Funktion MWI würde ich auch noch abschalten. Hat aber eher mit der verzögerung zu tun als mit dem SIP 404 Fehler.

Ich habe wie vorgeschlagen als Proxy nun manuell 217.0.18.16 eingetragen und damit scheint es zu funktionieren. Ich führte daraufhin auf beide IP-Adressen ein traceroute durch mit signifikantem Unterschied:

Anderer Proxy, andere Arbeitsweise. Auch beim Traceroute. Einer erlaubts, einer nicht.

vor 11 Jahren

Evtl. liegt es an dem Format. Versuch mal 071... oder +4971... die Funktion MWI würde ich auch noch abschalten.

Evtl. liegt es an dem Format. Versuch mal 071... oder +4971...
die Funktion MWI würde ich auch noch abschalten.

Evtl. liegt es an dem Format. Versuch mal 071... oder +4971...
die Funktion MWI würde ich auch noch abschalten.

Das Ergebnis wie ist zuvor.

Anderer Proxy, andere Arbeitsweise. Auch beim Traceroute. Einer erlaubts, einer nicht.

Anderer Proxy, andere Arbeitsweise. Auch beim Traceroute. Einer erlaubts, einer nicht.

Anderer Proxy, andere Arbeitsweise. Auch beim Traceroute. Einer erlaubts, einer nicht.

Welchen Grund hat die Telekom absichtlich eine solch inhomogene Infrastruktur zu betreiben? Das erhöht doch nur den Wartungsaufwand.

@voiper08:
Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?
0
vor 11 Jahren
Hallo Incognitus1,

ich bin zwar nicht voiper08, habe aber etwas beizusteuern...

Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

Von hier aus lässt sich der Proxy 217.0.19.163 auch nicht anpingen, ein Traceroute geht dann natürlich auch nicht. Ein weiterer Server aus dem Bereich -217.0.19.166- zeigt das selbe Verhalten.

Ich konnte aber beide Server mit Ihrer IP direkt in der aktuellen Version von PhonerLite einbinden. Klappte ohne Probleme.

Gruß
Matthias
0
vor 11 Jahren

@voiper08: Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

@voiper08:
Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

@voiper08:
Könntest du mal prüfen, ob die beiden Proxies bei dir auf ein Traceroute auch unterschiedlich reagieren?

Ja, habe ich auch festgestellt. Der Traceroute oder Ping haben aber keinen Einfluss auf die Funktionalität der Telefonie, weil diese über den Port 5060 läuft. Du bekommst ja die Antwort vom Proxy SIP 404. Also läuft ja die Kommunikation.

Der SIP Fehler 404 ist ja auch kein Netzwerkfehler, da er ja vom Proxy kommt.

Irgendetwas muss noch anders sein wie bei mir. Sonst würde ich ja den gleichen Fehler bekommen, wenn es grundsätzlich fehlerhaft wäre.

Der Fehler tritt ja auch nur bei der PhoneLite Software auf, und beim Speedport z.b. nicht. Also muss es im Zusammenhang der PhoneLite Software und Deiner Konfiguration und/oder Profildaten zusammenhängen.

Evtl. stört auch die HomeTalk App noch. Deinstalliere diese mal und versuche es dann nochmal mit der PhoneLite Software. ggf. kannst du diese auch auf einen anderen PC installieren, und dort versuchen.
0

vor 11 Jahren

Evtl. stört auch die HomeTalk App noch. Deinstalliere diese mal und versuche es dann nochmal mit der PhoneLite Software. ggf. kannst du diese auch auf einen anderen PC installieren, und dort versuchen.

Die App kann nicht stören. Jedesmal, wenn ich wieder einen Versuch mit PhonerLite mache, schalte ich einige Minuten vorher das Handy ganz aus. Gleiches Resultat auf anderem Rechner.

Der Fehler tritt ja auch nur bei der PhoneLite Software auf, und beim Speedport z.b. nicht. Also muss es im Zusammenhang der PhoneLite Software und Deiner Konfiguration und/oder Profildaten zusammenhängen.

Baut der Speedport die Verbindung sicher auf die genau gleiche Weise auf wie andere SIP-Clients im Heimnetz? Schließlich ist er als Router nicht hinter einer NAT.

Ich habe ein paar Server ausprobiert.
Mit folgenden klappt die Verbindung:
217.0.18.16
217.0.18.17

mit diesen leider nicht:
217.0.17.39
217.0.17.42
217.0.19.163
217.0.19.166
Dummerweise wird bei mir tel.t-online.de nur eben immer auf die Server aus der letzten Gruppe aufgelöst.

vor 11 Jahren

Baut der Speedport die Verbindung sicher auf die genau gleiche Weise auf wie andere SIP-Clients im Heimnetz? Schließlich ist er als Router nicht hinter einer NAT.

Es gab schon Probleme mit Speedport Routern und Voip Software dahinter. Der Router hat sich in die SIP Kommunikation eingeklinkt und diese beeinflußt. Beim W921 ist dies aber mit der aktuellen Firmware nicht bekannt.

Ganz ausschließen kannst du es nur indem du die Software und/oder den Router auswechselst. Oder es an einem anderen IP Anschluss versucht. Da müssen dann aber Usernamen und Passwort zwingend stimmen (Bei Dir zuhause nicht unbedingt)

vor 11 Jahren

Ganz ausschließen kannst du es nur indem du die Software und/oder den Router auswechselst. Oder es an einem anderen IP Anschluss versucht. Da müssen dann aber Usernamen und Passwort zwingend stimmen (Bei Dir zuhause nicht unbedingt)

Ich tauschte den Speedport temporär gegen eine Fritzbox 7270 als Router aus. Damit konnte ich mittels PhonerLite telefonieren, was mit dem Speedport nicht funktionierte. Die Hometalk-App konnte sich aber immer noch nicht registrieren.

Antwort

von

vor 10 Jahren

So langsam aber sicher kriege ich die Krise.

Am 21.11.2014 habe ich die Störung mit der SIP Registrierung von der Home Talk App gemeldet.

Am 24.11.2014 wurde das Ticket ohne Rückfrage oder Benachrichtigung geschlossen.

Am 26.11.2014 habe ich ein neues Ticket aufgemacht.

Am 02.12.2014 wurde das Ticket ohne Rückfrage oder Benachrichtigung storniert, obwohl die Störung immer noch besteht.

Am 03.12.2014 habe ich wieder ein erneutes Ticket aufgemacht. Ich habe der Hotline sogar gesagt, zu welcher Gruppe das Ticket innerhalb der Telekom zur Bearbeitung geben muss.

Am 12.12.2014, also heute, wurde das Ticket "abgeschlossen". Der Fehler ist aber immer noch da.

Kein Rückruf, kein Anruf, einfach nichts. Das kann ja wohl nicht wahr sein.

Das ist wirkliche sehr sehr traurig, dass die Telekom nicht in der Lage solch eine Störung zu beseitigen und keinerlei persönlichen Kontakt zum Kunden herstellt. Hier wird jedesmal das Ticket einfach zu gemacht. Informiert wird man nur über eine einfache SMS.

Jetzt warte ich mal wieder seit 20 Minuten in dieser sch... Warteschleife.

Es ist unglaublich, aber leider wahr.

Antwort

von

vor 10 Jahren

Hallo BastelWastl,

dass Sie sich als Kunde unzureichend informiert fühlen, ist eigentlich immer schlecht. Manchmal gibt es allerdings auch besondere Umstände, die eine persönliche Kommunikation zwischen Ihnen und uns behindern oder gar verhindern. Für die lange Wartezeit an unserer Hotline kann ich mich nur entschuldigen.
Ich möchte mir den Sachverhalt persönlich ansehen. Bitte senden Sie mir Ihre Kundendaten zu. Das Kontaktformular finden Sie hier:
http://bit.ly/1qDEoEJ

Viele Grüße
Johannes

Antwort

von

vor 10 Jahren

Ich habe eine gute Nachricht.

An meinen Anschluss funktioniert die Home Talk App wieder, außerdem funktionieren mein Grandstream IP Telefon per VoIP UDP und mein Linphone Client per UDP wieder!

An der Home Talk App hat es nicht gelegen. Entweder an meinen Router Speedport W724V Typ Huawei, den ich heute morgen erneut gebootet habe, oder an der Ticketbearbeitung durch die Telekom (SIP Registrar). Die Telekom habe ich informiert, dass das Ticket geschlossen werden kann und um Rückmeldung gebeten, was denn hier gemacht wurde.

Fazit:

Home Talk App, Grandstream IP und Linphone SIP Client funktionieren an einem Speedport W724V Typ Huawei! :smileyhappy: