Telefonie bricht nach spätestens 15 Sekunden ab

[schnurgly]

Wird unter (Bild) Fritzboxeinstellung der Port 5060 eingetragen?

 

[essex_man]

So, das mit dem Upload waere geklaert

Oeffne die Datei und suche nach dem String
"SIP log"
ab da wird es interessant.
Dann suche nach
"INVITE sip:"
Da sollte dann etwa sowas stehen (also die gewaehlte Nummer etc.):

INVITE sip:[email protected] SIP/2.0

Irgendwann kommt dann "##### END SECTION sip"
Dazwischen koennte es Hinweise auf den Gespraechsabbruch geben.

 

[phl06]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Nein, der Port 49*** steht unter URL.
Unter Fritzboxeinstellung steht das DECT mit der entsprechenden Nummer, die ich dann auswählen kann.

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Ja, da steht einiges. Danke erstmal. DAs kann ich hier vermutlich ja ebenfalls nicht posten.. Für mich sind das nur lauter Zahlen und Buchstaben.

Ich kann allerdings folgendes sehen...: Reason: Q.850; cause=16

 

[KunterBunter]

Q.850 Cause Code 16 defines normal clearing. Call disconnection usually refers to Codec mismatch problem.
Was steht denn in der Fritzbox unter Eigene Rufnummern -> Sprachübertragung welcher Codec für das Gespräch genutzt wurde?
Beispiel:

 

[phl06]

Hier kommts:

 

[stsoft]

Um herauszufinden, ob der Abbau von Deiner Seite oder vom Netz initiiert wird wäre ein BYE aus dem SIP-Log zu betrachten.
Dafür ist die Zeile direkt davor interessant
Vom Netz:
IN: my=192.168.128.250%14:5060 peer=192.168.128.254 port=5060 UDP, sipiface=none:
BYE sip:[email protected];uniq=EF09A89CF5FF59479E5FE1BFE74E5B5 2.0

von Deiner Seite
OUT: my=192.168.128.250%14:5060 peer=192.168.128.254 port=5060 UDP, sipiface=none:
BYE sip:[email protected];uniq=EF09A89CF5FF59479E5FE1BFE74E5B5 2.0

 

[PeterPawn]

Es geht um eine BYE-Message, aber BEIDE gezeigten Einträge sind keine und treten so immer wieder im Rahmen eines SIP-Dialogs auf. Da mußt Du schon nach der richtigen Nachricht suchen.

 

[essex_man]

Hier mal als Beispiel ein SIP Telefonat:


Es geht also mit INVITE los und dann zum Ende BYE und OK. Das Beispiel ist mit Wireshark erstellt, aber ein Ausschnitt aus der Support Datei sollte es auch tun. Von INVITE bis BYE und OK bitte alles kopieren und als Text Datei hier posten (vorher sensitive Informationen entfernen, z.B. gewaehlte Nummer, eigene IP Adresse mit xxx ersetzen). Die Datei die meinem Beispiel entspricht ist ca. 9kB gross (ca. 240 Zeilen), das sollte hoffentlich noch passen.

 

[essex_man]

Das ist schon mal hilfreich.

Das BYE wird um 20:17:25.285 von der FB versendet, anscheinend wurde das Gespraech um 20:17:09.997 angenommen (OK von FB). Also 7 Sekunden Dauer.
@phl06 hast du aufgelegt oder brach die Verbindung von selber ab?

Interessant ist die Codec Aushandlung zwischen der FB und Sipgate. Die FB bietet (wie zu erwarten) etliche Codecs an. im Session Progress von Sipgate werden ebenfalls diverse Codecs angeboten und auch im OK von der FB sind noch diverse Codecs gelistet. IMHO sollte Sipgate sich entscheiden und eines der angebotenen Codecs auswaehlen. Ich habe bisher noch nichts anderes gesehen aber vielleicht kann sich der eine oder andere Experte hier im Forum nochmal genauer hinsehen.

Ein Problem bei der Codec Aushandlung wuerde auch das "kurze Knarzen oder Rascheln" erklaeren.

In der BYE message steht dann in X-RTP-Stat in den Feldern EN und DE "PCMA".

Eine Beschreibung von X-RTP-Stat gibt es uebrigens von AVM hier https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/xrtpv32.pdf

 

[PeterPawn]

ich habe alles relevante gelöscht

Eher nicht, wie Dir vielleicht bei der Suche nach einer Mobilfunknummer und/oder Deinem Benutzernamen für den sipgate-Account auffällt - da solltest Du noch etwas nacharbeiten.

Das Ende im SIP-Dialog wird jedenfalls von Deiner 7590 ausgelöst - nur ist auch da eben der Cause-Code die 16, was für "normal call clearing" steht.

Ein Codec-Mismatch ist hier auch nicht zu erkennen, verwendet wird aLaw-PCM (Payload-Type 8) und die Verbindung dauerte 15 Sekunden vom ACK bis zum BYE. Übertragen wurden 128 kB in Senderichtung und 165 kB in Empfangsrichtung in jeweils ca. 1050 (erwarteten) Paketen, was bei einer Packet-Length von 20 ms zur Zeitdifferenz von 21 Sekunden zwischen der Progress-Message und dem Gesprächsende (BYE-Message) paßt. In Senderichtung ist es etwas weniger, weil da erst nach erfolgtem Aufbau der Verbindung (OK für die INVITE-Message) auch wirklich gesendet wird.

Da ich nicht verstanden habe, ob hier nicht nur die Box, sondern auch die Handsets bereit neu gestartet wurden, würde ich (auch wenn's alle drei betrifft) hier auch die Handsets neu starten und wenn sich damit auch nichts ändert, braucht es wohl einen dtrace-Mitschnitt (kann man auch auf der Supportseite machen) parallel zum nächsten SIP-Dialog, denn irgendwer muß in der Box ja das Gesprächsende einleiten und die DECT-Kommunikation erfolgt bei AVM über eine ISDN-Emulation.

EDIT: Etwas zu langsam, aber dennoch (hoffentlich) nicht überflüssig. Denn von Sekunde 9 bis Sekunde 25 sind es ja nicht 7 Sekunden (selbst wenn man das "Laternenmastproblem" berücksichtigt), sondern 16 (bzw. 17) und ich hoffe mal, die Ausführungen zu den übetragenen und "erwarteten" Paketen sind ebenso hilfreich, wie der Verweis auf dtrace. Die Tatsache, daß die FRITZ!Box für PCMA keinen rtpmap-Eintrag in der SDP-Beschreibung hat bei ihrer INVITE-Message, spielt keine Rolle, denn im media-Eintrag ist ja Payload-Type 8 durchaus enthalten.

 

[essex_man]

Die Tatsache, daß die FRITZ!Box für PCMA keinen rtpmap-Eintrag in der SDP-Beschreibung hat bei ihrer INVITE-Message, spielt keine Rolle, denn im media-Eintrag ist ja Payload-Type 8 durchaus enthalten.

Da stimme ich durchaus zu. Was mir allerdings nicht klar ist: bei der Codec Aushandlung bietet die FB in der INVITE message:

m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 101 18

also etliche Codecs. Dann kommt von Sipgate in der Session Progress message:

m=audio 22552 RTP/AVP 8 0 97 18 2 101

das sind zwar ein paar weniger als von der FB angeboten, aber immer noch keine Auswahl.

Wenn ich z.B. ueber Freevoipdeal telefoniere, bekomme ich in der Session Progress message:

m=audio 30136 RTP/AVP 9 101

also 9 fuer G722 und 101 fuer DTMF (ggf. statt G722 auch G711 je nachdem).

Und im OK (fuer INVITE) von Sipgate ebenfalls

m=audio 22552 RTP/AVP 8 0 97 18 2 101

also immer noch keine wirkliche Entscheidung fuer ein bestimmtes Codec. Es steht zwar im RTP Header
der Payload Type drin, man muesste ggf. mal einen vollen Paketmitschnitt machen und nachsehen was fuer ein Codec nun wirklich verwendet wurde (auch wenn X-RTP-Stat PCMA vermeldet).

Das C6 läuft über die Telekom und die zwei C5 über Sipgate.
Problem besteht bei allen.

Die SIP messages sind ja von einem Anruf ueber Sipgate, vielleicht waere es mal interessant auch mal das gleiche fuer ein Gespraech ueber Telekom anzusehen.

 

[phl06]

Nabend liebe Leute. Erst mal vielen Dank.
Das ist sehr viel Spanisch für mich. Wenn ihr mir sagt was ich noch genau wie und wo auslesen soll, werde ich das machen.
Die FB hatte ich nochmal neu gestartet. Danach ging es für einen Anruf gut, danach wieder selbes Problem mit allen Telefonen.

Sipgate hat eine Störung seinerseits ausgeschlossen. Auch die Telekom hat keine vorliegende Störung.

Ich werde jetzt gleich nochmal die Telefone alle neu hinzufügen und nachschauen was sich ändert.

@essex_man : Nein, ich habe nicht aufgelegt, die Verbindung kappt sich immer wieder einfach von selbst. Meistens nach genau 15 Sekunden ab Gesprächsbeginn...

Das BYE wird um 20:17:25.285 von der FB versendet, anscheinend wurde das Gespraech um 20:17:09.997 angenommen (OK von FB). Also 7 Sekunden Dauer.
hast du aufgelegt oder brach die Verbindung von selber ab?

Edit: Also Telefone eingebunden. Erst mal nur über den Telekom Anschluss. Selbes Problem besteht weiterhin. Nach ca. 15 Sekunden wird die Verbindung getrennt. (So steht es auch im Display).
Im übrigen blinkt auch dauerhaft die LED an der 7590 bei Fon/DECT. Wäre mir neu das es immer blinkt?.

Die SIP messages sind ja von einem Anruf ueber Sipgate, vielleicht waere es mal interessant auch mal das gleiche fuer ein Gespraech ueber Telekom anzusehen.

Das kann ich gerne nachholen

 

[essex_man]

Ich kann leider nichts zu den C5/C6 Telefonen von AVM sagen, an meiner 7590 sind Gigaset A510 angemeldet.

Um einen Anhaltspunkt zu bekommen ob es vielleicht "nur" an den C5/C6 Telefonen liegt, koenntest du folgendes probieren:

1) HD-Telefonie bei den DECT Phones ausschalten
2) ein Analog Telefon in die Fritzbox einstoepseln
3) ein anderes DECT Phone verwenden (z.B. Gigaset)
4) FritzApp Phone auf dein Mobiltelefon und dann als Telefon auf der FB anmelden,

und dann jeweils nochmal telefonieren.

Im übrigen blinkt auch dauerhaft die LED an der 7590 bei Fon/DECT. Wäre mir neu das es immer blinkt?.

Neue Message im Anrufbeantworter?

 

[phl06]

Neue Message im Anrufbeantworter?

Der Telekom Anschluss hat keinen Anrufbeantworter.

1) ist generell aus, da wir vorher irgendwann mal Gigasets hatten und es das zu Problemen kam.
2) Leider keins da
3) Leider gerade auch nicht. Die Fritzphones sind aber alle recht neu.
4) Über die App ging es ca. 2 Minuten gut und dann das selbe Problem.

 

[stoney]

Installier doch mal FRITZ.Box_7590-07.57-108562-LabPLUS

Index of /downloads/LaborPlus/fritzbox-7590

Verbesserungen in FRITZ!OS 07.57-108562

- Telefonie - Behoben: Abbrüche abgehender Gespräche zu Mobilfunk-Gegenstellen nach 2 Minuten

 

[phl06]

Was mach ich damit?

 

[PeterPawn]

Es steht zwar im RTP Header der Payload Type drin

Exakt - und man muß auch keine "Entscheidung" treffen, denn es ist ja durchaus auch möglich, daß ein RTP-Stream mehr als einen Codec (manchmal auch nur "Pseudo") verwendet - siehe Dein Beispiel, denn auch G722 und "telephone-event" (das ist ja 101) sind ja ZWEI Codecs. Der Sender trägt bei jedem Paket im RTP-Header den korrekten Payload-Type ein und sendet das Paket an die in der SDP-Description angegebene IPv4-Adresse (und den dort spezifizierten Port 22552) - was der Empfänger daraus dann macht, tangiert den Sender nicht mehr wirklich.

@phl06:
Hast Du die DECT-Handsets tatsächlich nur neu angemeldet oder auch mal neu GESTARTET (richtig ausschalten, u.U. sogar den Akku raus und dann wieder einschalten - natürlich nachdem der ggf. entfernte Akku wieder eingesetzt wurde), wie ich es empfohlen habe?

Wenn das tatsächlich nichts hilft und es weiterhin zu diesen Abwürfen kommt (ggf. auch mal in beide Richtungen testen) und auch die LabPLUS-Version nichts ändert, dann bliebe noch das bereits erwähnte dtrace-Protokoll.

Wobei ich immer noch nicht richtig begriffen habe, ob GAR KEINE Audio-Daten übertragen werden (zwischen Box und Handset, denn die Box empfängt die RTP-Daten ja offenbar korrekt) oder ob es nur am Beginn "knarzt" und danach dann - zumindest für die Zeit, wo die Verbindung vermeintlich noch steht - doch Audio übertragen wird.

 

[stoney]

Du entpackst das .zip-Archiv und installierst die darin enthaltene .image-Datei.

Falls Du nicht genau weißt, wie Du vorgehen musst, liegt dem Archiv neben dem von mir zitierten Changelog auch noch eine "Info" bei.

 

[essex_man]

es ist ja durchaus auch möglich, daß ein RTP-Stream mehr als einen Codec (manchmal auch nur "Pseudo") verwendet - siehe Dein Beispiel, denn auch G722 und "telephone-event" (das ist ja 101) sind ja ZWEI Codecs.

Dass es fuer telephone event einen separaten Media Type gibt ist klar, DTMF durch Codecs zu schieben ist ja keine gute Idee.

Habe inzwischen mal etwas RFCs gelesen, mehrere Codecs in SDP answer anzubieten ist anscheinend nicht explizit ausgeschlossen, es fragt sich nur warum der UAS sich nicht festlegen will, klar kann man im RTP header den Payload Type sehen, aber viel Sinn ergibt das meines Erachtens nicht.

Interessant waere vielleicht auch was bei eingehenden Gespraechen von Sipgate bzw. Telekom in deren INVITE an Codecs angeboten wird und was letztendlich die Fritzbox auswaehlt. Wenn ich @phl06 richtig verstanden habe, dann tritt das Problem sowohl be abgehenden wie auch bei ankommenden Gespraechen auf.

4) Über die App ging es ca. 2 Minuten gut und dann das selbe Problem.

und wie war waehrend der 2 Minuten die Sprachqualitaet?

Tritt das Problem beim Telefonieren ueber die App bei Sipgate und/oder Telekom auf?

Nur bei abgehenden Gespraechen oder auch ankommende?

 

[phl06]

So, ich habe jetzt mal die gesamte Box, auf Werksteinstellung gesetzt und dann händisch wieder eingestellt. Also ohne eine Sicherung auf zu spielen.
Das Problem mit dem Abbruch ist momentan erst mal weg. Mal sehen wie es morgen im Tagesgeschäft ist.

Allerdings bleibt weiterhin das Problem, dass ich am Anfang eines Gespräch den Gegenüber erst nach ca. 1. Sec höre und auch ein ganz leises knarzen ganz am Anfang zu hören ist. Das und auch Telefonie Abbrüche hatten wir im vergangen Jahr auch schon mal. Da kam eine neue Box und das Problem war bis jetzt verschwunden.
HD ist deaktiviert und auch Cat iq 2.0 ist nicht aktiv.

und wie war waehrend der 2 Minuten die Sprachqualitaet?

Tritt das Problem beim Telefonieren ueber die App bei Sipgate und/oder Telekom auf?

Nur bei abgehenden Gespraechen oder auch ankommende?

die Sprachqualität war nicht besonders gut.
Was ich dir sagen kann ist, dass wir Sipgate auch auf den Handys haben (selbe Rufnummern) und es dort keinerlei Probleme gibt. Zur Telekom-App kann ich keine Auskunft geben.

Es war bei allen Gesprächen, egal ob eingehenden oder abgehenden. Problem bleibt genau gleich.

Ich beobachte wie es sich morgen verhält und dann werden ich die restlichen Sachen für euch bereit stellen.


Edit:
Also heute hat sich alles normal verhalten. Keinerlei Probleme. Kann es sein, das die Box irgendwie ein Problem durch den Stromausfall bekommen hat?