Hometalk App / SIP-Client stört IP-Telefonie über Speedport 921V
vor 12 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?
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
0
0
Das könnte Ihnen auch weiterhelfen
in
62484
8
5
vor 7 Jahren
in
13565
8
2
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 12 Jahren
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
0
vor 12 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.
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.
0
0
vor 12 Jahren
Ich habe inzwischen auch den Client PhonerLite ausprobiert. Oft kann er sich nicht registrieren, ab und zu vorübergehend aber seltsamerweise doch.
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.
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.
0
0
vor 12 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
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.
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.
0
0
vor 12 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)
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.
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.
0
0
vor 12 Jahren
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
0
vor 12 Jahren
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
0
vor 12 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)
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
0
vor 12 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
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:
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.
0
0
vor 12 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.
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.
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
0