Smartphone VOIP unzuverlässig

HeadyCS

Neuer User
Mitglied seit
15 Apr 2021
Beiträge
3
Punkte für Reaktionen
0
Punkte
1
Hallo,

Vorhandene Hardware / Software / Provider:
Fritzbox 7490
Smartphone Moto G7, Android 10, Andorid SIP Client
Festnetz Provider: Telekom Privatkunde, Festnetznummer A, Festnetznummer B
Mobil: Telekom, Mobilfunknummer A, kein Internet
Linux Server im LAN

zu meinem Vorhaben / Wunschfunktion: Ich möchte das Smartphone als Telefoniegerät neben der Mobilfunknummer auch eine oder zwei Festnetznummern verwenden. Ist die Festnetznummer nicht erreichbar (Smartphone nicht im WLAN) soll automatisch auf die Mobilfunknummer umgeleitet werden. Im Haus ist das Smartphone per Wlan mit einer Fritzbox verbunden und kann darüber ins Internet. Als SIP Client gefällt mir der Android SIP Client am besten, wegen dem Handling mit Kontakten und ausgehender Rufnummerauswahl.

Jetzt habe ich schon viele Konstellationen probiert:

1. Fritzbox holt sich über den Anschluss die Festnetznummer von der Telekom mit den Standardeinstellungen:

Es wird ein IP-Telefoniegerät mit Account angelegt. Folgende Einstellung / Konto im Android SIP Client:
Nutzername: Fritzbox IP-Telefoniegerät Account Username
Passwort: Fritzbox IP-Telefoniegerät Account Passwort
Server: fritz.box

Die SIP Verbindung bricht nach 300 Sekunden ab und der SIP Client kann sich nicht mehr verbinden (Fehler bei Registrierung). Man muss das Konto im Smartphone löschen und erneut anlegen damit die Verbindung wieder funktioniert, inakzeptabel.
Auch mit der Fritzbox Fon App ist die Verbindung nicht zuverlässig. Die Einstellung "Anmeldung aus dem Internet erlauben" bringt auch keine Verbesserung.


2. Asterix auf Linux Debian:
Nach installation, Konfiguration und Test inkl. Dialplan mit Rufweiterleitung auf Mobilfunknummer wenn SIP Verbindung zu Smartphone nicht vorhanden:
Asterix bekommt nicht mit, dass das Smartphone das WLAN verlässt und die SIP Verbindung nicht mehr existiert. Selbst nach Stunden ohne Verbindung denkt Asterix dass sie noch steht. :mad:


3. Android SIP Client Konto direkt zur Telekom:

Folgende Einstellung / Konto im Android SIP Client:
Nutzername: Festnetznummer A
Passwort: Telekom Passwort
Server: tel.t-online.de
Zuletzt auch Keep-alive immer senden.

Im Kundencenter ist eine Rufumleitung zur Mobilfunknummer unter "Offline-Rufannahme" eingerichtet.
Diese Konstellation funktioniert aktuell am zuverlässigsten, aber noch nicht zuverlässig genug. Teilweise ist es so, wenn ich versuche die Festnetznummer anzurufen, dann kommt kein Wählton und bricht nach einigen Sekunden ab.
Einen weiteren Schwachpunkt gibt es noch. Wenn das Smartphone ausgeschaltet ist bekomme ich nicht mit, dass jemand anrufen wollte, es gibt keine Anrufliste oder Oberfläche wo man nachsehen könnte.

Vielleicht gibt es eine Hardware oder eine Lösung. Anforderungen:
- Zuverlässige Verbindung mit Android SIP Client
- Automatische Rufumleitung wenn Smartphone nicht im WLAN
- Oberfläche oder Anzeige der Anrufliste / -protokoll
 
Alternative Apps haben wir hier … aber bleiben wir mal bei der Android eigenen App:
1. […] Server: fritz.box
Wenn Du diesen Server nimmst, kannst Du es nicht von unterwegs nutzen. Wenn Du Dich (auch) unterwegs einbuchen willst, müsstest Du entweder ein VPN darunter legen oder eine Dynamic-DNS in der FRITZ!Box hinterlegen … aber unterwegs willst Du gar nicht auch weil Du gar kein mobiles Internet hast, richtig?
SIP Verbindung bricht nach 300 Sekunden ab und der SIP Client kann sich nicht mehr verbinden (Fehler bei Registrierung)
Das klingt so, als hätte sich der SIP-Client durch sein „send keep-alive“ ausgesperrt … hast Du bereits den Datenverkehr mitgeschnitten, um mit der Computer-App Wireshark zu schauen, was genau passiert? Ganz andere Frage aus reiner Neugierde: Warum nicht das native WLAN-Calling der Telekom?
 
Die SIP Telefonie möchte ich unterwegs nicht nutzen. Es soll sich nur im heimischen WLAN einbuchen.

Auch wenn keep-alive auf automatisch (standard) steht, besteht das 300 Sekunden Problem mit der Fritzbox. Es gibt auch mehrere Themen von anderen Usern dazu. War für mich bis jetzt keine Lösung dabei.
Der Datenverkehr wurde noch nicht mitgeschnitten und geprüft.

WLAN-Calling kannte ich vorher noch nicht. Das habe ich ausprobiert und das ist eine interessante Funktion. Was mir hier fehlt wäre eine Anrufprotokoll. Obs an Prepaid liegt und dort keine Verfügbar ist, kann ich nicht sagen.


Ich habe die letzten Tage eine 3CX Instanz aufgesetzt. Ich muss das noch ein wenig testen, aber der Weg könnte der richtige sein.
 
Der Datenverkehr wurde noch nicht mitgeschnitten und geprüft.
Das solltest Du zuerst machen (auch bevor Du versuchst andere User-Posts zu interpretieren). Wir helfen Dir gerne den Wireshark-Mitschnitt zusammen auszuwerten. Ich kann Dein Szenario hier auch vergleichsweise schnell nachstellen und bestätigen bzw. mitbasteln. Alles sinnvoller, als einen eigenen, weiteren SIP-B2BUA aufzusetzen. Denn Du könntest auch einen Software-Bug gefunden haben. Der muss gemeldet werden, sonst bleibt der für vielleicht immer drin.
WLAN-Calling kannte ich vorher noch nicht. Das habe ich ausprobiert und das ist eine interessante Funktion. Was mir hier fehlt wäre eine Anrufprotokoll.
VoWiFi geht ebenfalls über die Android-Hersteller eigene Phone-App. Die App unterscheidet nicht einmal, wie der Anruf rein/raus ging. Daher bin ich leicht irritiert. Was hattest Du genau gemacht, damit WLAN-Calling überhaupt ging?
 
WLAN-Calling geht ja über bzw. mit der Mobilfunknummer und hat mit der Festnetznummer und dem SIP Thema nichts zu tun. Hier bei dem Smartphone gibts eine Einstellung unter Mobilfunknetz --> WLAN Call
"Wenn die Option WLAN Call aktiviert ist, kann Ihr Smartphone abhängig von Ihrer Einstellung und von der Signalstärke Anrufe über WLAN-Netzwerke oder über das Netz Ihres Mobilfunkanbieters übertragen. Erkundigen Sie sich bei Ihrem Mobilfunkanbieter über die hierfür erhobenen Gebühren und andere Informationen, bevor Sie diese Funktion aktivieren."


Einen Mitschnitt werde ich versuchen die nächsten Tage zu machen wenn nicht so viel los ist im WLAN.
 
beim Galaxy S6 soll zwar VoWifi/VoIP können jedoch "roamet" es zwischen VoWiFi und "Handynetz" und dann "kakkt's" ab.

Daher "WLAN-Call" im S6 deaktiviert, solange keine Abbrüche da sind, lebe ich mit der teils schlechten Verbindung beim umherlaufen im 5 Zimmer Domizil auf 120m².

(ggf. hing es mit den F!B OS Versonen zusammen, welche unterschiedlich waren zwischen der 7590 und er 7580 - jetzt sind beide auf 7.25 - um mal zu schauen (vorher 7.12)... da stehen Tests in dieser Richtung -evtl- noch aus.. mal schauen wie ich dazu komme.
 
Wenn das Smartphone ausgeschaltet ist bekomme ich nicht mit, dass jemand anrufen wollte, es gibt keine Anrufliste oder Oberfläche wo man nachsehen könnte.
Meintest Du das mit Anruf-Protokoll? Mit VoWiFi schlägt der Anruf auf Deiner Mobilfunknummer auf. Bin mir nicht sicher, ob der Anruf dann auf der Festnetznummer irgendwo im Kundencenter angezeigt wird. Was auf jeden Fall ginge, wäre der Dienst „Entgangene Anruf per SMS“. Das konntest Du früher über das Portal buchen, geht aber aktuell nur (?) noch über die telefonische Produktunterstützung. Dann bekommst Du nach dem Einschalten des Telefons eine SMS wer wann angerufen hatte. Haken: Nicht alle Telekom-Sub-Marken bieten diesen Dienst.
hat mit der Festnetznummer und dem SIP Thema nichts zu tun
Das weiß ich. Aber man kann bei Telekom Deutschland seine Festnetznummer dauerhaft auf mobil umleiten. Daher dachte ich, dass VoWiFi eine (komplett andere) Herangehensweise an das gewünschte Ziel ist. Sah auch erst so aus, weil Du (lediglich) ein fehlendes Anruf-Protokoll ansprachst. Was ich mir immer noch nicht erklären kann … aber was scheinbar nicht mehr der Haupt-Kritikpunkt ist … den ich jetzt auch nicht kenne. Zurück zum Mitschnitt: Wenn Probleme auftreten oder sonst was dabei hakt, einfach melden.
 
Hallo,
mein Ziel ist es den Android SIP-Client als Telefoniegerät mit der Fritzbox zu verbinden. Wie oben beschrieben scheitert das Vorhaben bisher an der keep-alive beziehungsweise 300 Sekunden Problematik. Nach meinem Kenntnisstand wird der SIP-Client in der Folge von der Fritzbox auf die Blacklist gesetzt, weil er sich zu häufig meldet.

Dazu habe ich folgende Frage: Ist eine Möglichkeit bekannt dies auf der Seite der Fritzbox zu konfigurieren? Der Android Client bietet leider keine geeignete Einstellmöglichkeit um das keep-alive Intervall geeignet einzustellen.
 
Wenn der SIP-Client sich erfolgreich authentifiziert (hat), darf der sich sooft anmelden, wie er lustig ist. Problematisch wird es nur dann, wenn der SIP-Client noch andere Dinge macht (SUBSCRIBE auf einen Anrufbeantworter und so weiter …). Daher:
  1. Welchen SIP-Client nutzt Du genau? Ist das (ebenfalls) der von Google in die Telefon-App eingebaute?
  2. Hast Du schon die SIP-Nachrichten angeschaut, was er alles probiert?
Ist eine Möglichkeit bekannt dies auf der Seite der Fritzbox zu konfigurieren?
Selbst wenn – so eine Konfigurationseinstellung wäre mir neu –, weil wir nicht die Ursache kennen, ist auch unklar auf welchen Wert man das setzen müsste.
 
Ich nutze den in die Telefon-App eingebauten SIP-Client (Android 7.1.2; Resurrection Remix OS).

Hier ein Wireshark-Mitschnitt:

Code:
574031    288.563746    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
563761    284.583186    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
553266    280.547575    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
550276    279.464960    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
544817    277.466323    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
542285    276.461818    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
540921    275.955446    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
532008    272.552722    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
521776    268.537421    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
511321    264.546245    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
500381    260.511223    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
495350    258.510134    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
492564    257.507254    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
491242    257.002456    192.168.178.21    192.168.178.1    SIP    493    Request: REGISTER sip:fritz.box  (1 binding) |
487206    255.478556    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
482687    253.617805    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
473181    249.351198    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
472435    248.847858    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
453058    238.881295    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
453005    238.856255    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
429638    228.871115    192.168.178.1    192.168.178.21    SIP    538    Status: 401 Unauthorized |
429596    228.850394    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
403259    218.855503    192.168.178.1    192.168.178.21    SIP    538    Status: 401 Unauthorized |
403211    218.835610    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
376813    208.926714    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
376735    208.879292    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
376690    208.861737    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
350438    198.863058    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
350408    198.845115    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
324640    188.843055    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
324604    188.827183    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
271912    168.882924    192.168.178.1    192.168.178.21    SIP    538    Status: 401 Unauthorized |
271854    168.849930    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
247890    159.060581    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
247889    159.056597    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
221812    148.891828    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
221684    148.849893    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
195478    138.900527    192.168.178.1    192.168.178.21    SIP    537    Status: 401 Unauthorized |
195343    138.855120    192.168.178.21    192.168.178.1    SIP    413    Request: OPTIONS sip:fritz.box |
169237    128.891594    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
169113    128.847817    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
143271    118.897815    192.168.178.1    192.168.178.21    SIP    538    Status: 401 Unauthorized |
143201    118.871605    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
121559    108.868912    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
121549    108.855381    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
116098    89.225288    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
116096    89.041834    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
104748    79.018164    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
92268    68.895585    192.168.178.1    192.168.178.21    SIP    538    Status: 401 Unauthorized |
92211    68.863984    192.168.178.21    192.168.178.1    SIP    414    Request: OPTIONS sip:fritz.box |
92185    68.814871    192.168.178.1    192.168.178.21    SIP    539    Status: 401 Unauthorized |
92145    68.794990    192.168.178.21    192.168.178.1    SIP    415    Request: OPTIONS sip:fritz.box |
92033    68.742674    192.168.178.1    192.168.178.21    SIP    762    Status: 200 OK  (1 binding) |
92020    68.736763    192.168.178.21    192.168.178.1    SIP    647    Request: REGISTER sip:fritz.box:5060  (1 binding) |
91993    68.645683    192.168.178.1    192.168.178.21    SIP    690    Status: 200 OK  (0 bindings) |
91984    68.640711    192.168.178.21    192.168.178.1    SIP    596    Request: REGISTER sip:fritz.box:5060  (remove all bindings) |
91918    68.596145    192.168.178.1    192.168.178.21    SIP    484    Status: 401 Unauthorized |
91909    68.589910    192.168.178.21    192.168.178.1    SIP    441    Request: REGISTER sip:fritz.box  (remove all bindings) |

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Hier noch der Mitschnitt der vom Client angefragten Options:

Code:
Frame 92145: 415 bytes on wire (3320 bits), 415 bytes captured (3320 bits)
    Encapsulation type: IEEE 802.11 Wireless LAN (20)
    Arrival Time: Sep 11, 2021 11:22:54.156764000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1631352174.156764000 seconds
    [Time delta from previous captured frame: 0.003681000 seconds]
    [Time delta from previous displayed frame: 0.003681000 seconds]
    [Time since reference or first frame: 68.794990000 seconds]
    Frame Number: 92145
    Frame Length: 415 bytes (3320 bits)
    Capture Length: 415 bytes (3320 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wlan:llc:ip:udp:sip]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
IEEE 802.11 QoS Data, Flags: .......T
    Type/Subtype: QoS Data (0x0028)
    Frame Control Field: 0x8801
        .... ..00 = Version: 0
        .... 10.. = Type: Data frame (2)
        1000 .... = Subtype: 8
        Flags: 0x01
            .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = +HTC/Order flag: Not strictly ordered
    .000 0001 0011 1010 = Duration: 314 microseconds
    Receiver address: AVM_86:24:06 (c0:25:06:86:24:06)
    Transmitter address: 10:66:75:0f:77:60 (10:66:75:0f:77:60)
    Destination address: AVM_86:24:04 (c0:25:06:86:24:04)
    Source address: 10:66:75:0f:77:60 (10:66:75:0f:77:60)
    BSS Id: AVM_86:24:06 (c0:25:06:86:24:06)
    STA address: 10:66:75:0f:77:60 (10:66:75:0f:77:60)
    .... .... .... 0000 = Fragment number: 0
    0001 0100 0010 .... = Sequence number: 322
    Qos Control: 0x0000
        .... .... .... 0000 = TID: 0
        [.... .... .... .000 = Priority: Best Effort (Best Effort) (0)]
        .... .... ...0 .... = QoS bit 4: Bits 8-15 of QoS Control field are TXOP Duration Requested
        .... .... .00. .... = Ack Policy: Normal Ack (0x0)
        .... .... 0... .... = Payload Type: MSDU
        0000 0000 .... .... = TXOP Duration Requested: 0 (no TXOP requested)
Logical-Link Control
    DSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = IG Bit: Individual
    SSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x3)
    Organization Code: 00:00:00 (Officially Xerox, but
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.178.21, Dst: 192.168.178.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 381
    Identification: 0xf70f (63247)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x5cf8 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.178.21
    Destination Address: 192.168.178.1
User Datagram Protocol, Src Port: 49151, Dst Port: 5060
    Source Port: 49151
    Destination Port: 5060
    Length: 361
    Checksum: 0x56b5 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 8]
    [Timestamps]
        [Time since first frame: 0.205080000 seconds]
        [Time since previous frame: 0.052316000 seconds]
    UDP payload (353 bytes)
Session Initiation Protocol (OPTIONS)
    Request-Line: OPTIONS sip:fritz.box SIP/2.0
        Method: OPTIONS
        Request-URI: sip:fritz.box
            Request-URI Host Part: fritz.box
        [Resent Packet: False]
    Message Header
        Call-ID: [email protected]
        [Generated Call-ID: [email protected]]
        CSeq: 1120 OPTIONS
            Sequence Number: 1120
            Method: OPTIONS
        From: "620" <sip:[email protected]>;tag=1786640663
            SIP from display info: "620"
            SIP from address: sip:[email protected]
                SIP from address User Part: 620
                SIP from address Host Part: fritz.box
            SIP from tag: 1786640663
        To: "620" <sip:[email protected]>
            SIP to display info: "620"
            SIP to address: sip:[email protected]
                SIP to address User Part: 620
                SIP to address Host Part: fritz.box
        Via: SIP/2.0/UDP 192.168.178.21:49151;branch=z9hG4bK9a34e7a964c538a9f446e19799229182383637;rport
            Transport: UDP
            Sent-by Address: 192.168.178.21
            Sent-by port: 49151
            Branch: z9hG4bK9a34e7a964c538a9f446e19799229182383637
            RPort: rport
        Max-Forwards: 70
        User-Agent: SIPAUA/0.1.001
        Content-Length: 0
 
Zuletzt bearbeitet von einem Moderator:
Google Android → App „Telefon“ (getestet ) → Hamburger-Menü → Einstellungen → Anrufe → Anrufkonten → Eingehende Anrufe annehmen

Ist das aktiviert, sendet Google alle 10 Sekunden ein OPTIONS, damit eine Firewall auf dem Weg zum VoIP/SIP-Server nicht zu macht. Bei einer lokalen IP-Adresse macht dies keinen Sinn. Trotzdem macht es Google. Diese OPTIONS challenged FRITZ!OS. Aber darauf reagiert Google nicht. Folglich steht eine nicht authentifizierte SIP-Anfrage im Raum, die FRITZ!OS auf die Hammer-Protection anzählt. In Android kann man innerhalb eines Kontos zwar unter „Optionale Einstellungen“ das „Keep-Alive senden“ ändern, aber nicht ausschalten. Auch die „Transportart“ von UDP auf TCP zu ändern, hilft nicht. Am Ende schlägt das nächste REGISTER ebenfalls fehl und man ist nicht mehr erreichbar.

Das ist jetzt echt arg. Das Fehlverhalten liegt zweimal bei Google, weil
  • bei einer IP-Adresse im selben Subnetz kein Keep-Alive nötig ist und
  • das Challenge der FRITZ!Box nicht beantwortet wird
Leider hat Google an seinem VoIP/SIP-Client seit Jahren, vielleicht sogar seit über einem Jahrzehnt nichts mehr gemacht. Folglich müsste man AVM davon überzeugen, dass irgendwie in den Griff zu bekommen. @HeadyCS und @thorsee habt Ihr das schon an AVM gemeldet, welche Ticket-ID habt Ihr erhalten?
Kann ich die [Hammer-Protection] in FRITZ!OS konfigurieren?
AVM müsste SIP-Anfragen ohne den Header Authorization dürfen nicht auf die Hammer-Protection zählen. Man müsste ermitteln, wann genau diese Hammer-Protection eingeführt wurde: FRITZ!OS 7.1x, FRITZ!OS 7.0x oder FRITZ!OS 6.8x. Vielleicht kann man dann über den Export der Konfiguration in der Version und eine Version früher, einen Konfigurationsparameter finden. Aber mir wäre das neu. Auch das könnte man AVM fragen.

Workaround bis dahin: Anderen SIP-Client auf Android nehmen. Was spricht gegen die AVM eigene App?
 
Herzlichen Dank an sonyKatze für die präzise Analyse. Ich habe das Problem nicht an AVM gemeldet da ich fürchte, dass ich aufgrund meiner betagten Box (7360 V1), die auch noch "gefreetzt" ist, nicht mit Support rechnen darf :(

Als workaround verwende ich aktuell Linphone. Abgesehen von der Tatsache, dass Linphone die Deaktivierung des Outbound proxy nach jedem Neustart vergisst, funktioniert es ganz gut. Schöner wäre es allerdings den nativen Android SIP-Client verwenden zu können.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,690
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.