[Gelöst] Mitel 104, externe Anrufe intern Weitervermitteln, Stille

[chrsto]

Hallo,

bei einer Mitel 104 12.1 SP3 (Telekom SIP, Einzelrufnummern) kommt bei beim internen Weitervermitteln externer Gesprächspartner hin und wieder dazu, dass das Gespräch nach Übergabe für einige Sekunden stumm ist. Dabei ist es egal, welches Endgerät verwendet wird (DECT 622er oder 68xx).

Ich habe bereits PRACK (RFC3262) in den SIP Provider Einstellungen deaktiviert. Damit wurde das Problem bei vielen Gesprächspartnern behoben, aber nicht bei allen.

Im Mitel Forum wird von einem generellen Problem der Telekom berichtet, aber ohne irgendetwas handfestes.

Weiß jemand etwas dazu, evtl. mit einer Problemlösung?

 

[mschoenb]

Von generellen Problemen ist mit nichts bekannt.

Welches Template nimmst du für Dt. Telekom SIP, mit oder ohne STUN?

Hast du schon mal ein pcap File gezogen und dort angehört ob die Stille auch vorhanden ist?

Die DECT Handsets werden über Upn oder IP DECT Sender verbunden?

Warum PRACK einen Einfluss haben soll, ist mir unklar. Welches VoIP Profil nutzt du denn, sprich welche Codecs lässt du zu?
PRACK spielt ja nur einen Rolle beim Call Aufbau, noch bevor INVITE kommt.
Schlau werde ich da noch nicht, warum es einen Einfluss haben soll...

 

[chrsto]

Template ist ohne STUN.

Der Mitschnitt wird schwierig, da ich nicht vorhersagen kann, wann der Fehler auftritt.

DECT ist IP DECT. Der Fehler tritt aber auch beim Vermitteln von einem 68er zum einem anderen 68er auf.

Den Hinweis zu PRACK habe ich vom Support. Danach trat auch eine deutliche Besserung ein. Die VoIP Profile hatte ich zeitweise schon von HQ Audio auf Standard (also G722 ausgeschlossen) gewechselt, aber ohne Ergebnis. Ich selbst kann da auch wenig zu sagen, da der Effekt für mich zum ersten Mal auftritt.

 

[mschoenb]

Mein Verdacht ist, dass das an deinem internen Netzwerk liegt.

Da mal zum suchen beginnen. Läuft dort VoIP mit eigenem VLAN?
Managed Switch mit Prio für VoIP Traffic?

Ggf. den/die User dir häufig das Problem haben, anders Netzwerktechnisch anbinden, und sei es mit einem dummen, unmanaged Switch.

Testweise mal eine Upn Systel verwenden, oder gar Upn DECT Sender sofern verfügbar.
Alternativ ein analoges Telefon [emoji3], was aber wohl nicht praktikabel sein wird.

Hast du kontrolliert ob alle 68xx Systels sich auch die aktuelle FW gezogen haben? Sollte so sein, aber wer weiß.

PS: Wo stellt du das mit PRACK ein?

 

[chrsto]

Das Netzwerk ist unmanged, kein VLAN oder Prio. Aber ich werde mal gucken, ob es einen User gibt, der das auffällig oft hat.

UPN Geräte sind leider keine zum Testen da, und ein analoges Telefon wäre wohl keine Lösung. Ich könnte mit der Tür Testen

Die Firmware ist aktuell. Die Systels haben alle die aktuelle Version.

PRACK wird unter Konfigurator - Telefonie - Leitungen - Sip Provider - <TEMPLATE>
Die letzte Option über Parameter. Noch vor outgoing.

 

[mschoenb]

Aber wie soll PRACK dann einen Einfluss haben, wenn der erste Anruf funktioniert, und erst nach dem Verbinden zu einem internen Teilnehmer scheitert?
Identisch bei Problemen zwischen internen Teilnehmern.

Die Einstellung hat nur eine Auswirkung für den ein- oder ausgehenden Anruf WAN seitig.

Ich kenne die Unternehmensgrösse nicht mit den Anzahl VoIP und PC Clients und ob du das ganze Netzwerk unter dir hast, oder dich mit den Kollegen der PC Fraktion „arrangieren“ musst.

Gibt es eine separate IP Adressenraum für VoIP und PC/AD Controller?

 

[Kostenlos]

Hallo!

Ich würde mal versuchen, reine Interne Gespräche zu verbinden, macht man zwar selten, geht aber normal ebenso.

Wenn der sporadische Fehler dabei ebenfalls auftritt, wird es klarer zum Fehler eingrenzen, Anlage generell oder nur in Verbindung mit Externgesprächen.

 

[chrsto]

@mschoenb: Wieso PRACK einen Einfluss hat, kann ich selbst nicht sagen. Ich habe beim Support (Komsa) ein Ticket aufgemacht, das Problem geschildert und kurz mit denen telefoniert. Das Problem war dort bekannt und es kam direkt der Hinweis zu PRACK.

Evtl. habe ich mich eben etwas missverständlich ausgedrückt. Der Effekt tritt nur auf, wenn externe Verbindungen intern weitervermittelt werden und dann auch relativ selten. Reine Interngespräche sind fehlerfrei.
Das Verbinden scheitert ja auch nicht wirklich. Nach ca. 6-10 Sekunden, wenn beide Gespächspartner so lange durchgehalten haben, kann telefoniert werden, als wäre nichts gewesen.

Ich muss mich mit dem IT'ler arrangieren. Ich "darf" in seinem Netzwerk teilnehmen ;-). Es gibt 5 68er, 5x 622, 1x 650 und 2x RFP35. Dazu noch TAPI und eine analoge Tür und Fax. Das alles ist in einem Netzwerk mit dem gleichen IP Adressraum.

Ich habe grade erfahren, dass es noch ein offenes Ticket bei der Telekom zur Sprachqualität gibt. Das warte ich jetzt erstmal ab. Danach versuche ich mal einzugrenzen, ob der Effelt bei bestimmten externen Rufnummern ständig oder gehäuft vorkommt. Da könnte dann evtl. ein Trace weiterhelfen.

 

[mschoenb]

Weiterer möglicher Workaround:
Du bindest das SIP Konto über LAN2 ein, und betreibst die interne IP Telefonie über LAN1 an der Mitel100.

Ich musste mich genauso „arrangieren“ mit dem Computerjungs [emoji23].
Aber hatte irgendwann die Nase voll und baute mein eigenes IP-Netz auf.

„Gnädigerweise“ integrierte ich dann deren Netzt mit VLAN , nachdem bei mir alles funktionierte und denen zeigte das unmanaged Switches zum kotzen sind.
Aber ich generell immer VoIP und Internettraffic trennen.

So habe ich es bei mir am laufen und wir verbinden viele Gespräche nach intern, was tadellos funktioniert (mit SIP Trunk Dt. Telekom).
Jedoch zu 90% zu UPN Systels oder UPN DECT, über zwei im GW Modus betriebene OC510.

IP Endgeräte und 3 IP DECT Sender sind in der deutlichen Unterzahl [emoji51].

Beim Verbinden, bekommt der gehaltene A-Tln Wartemusik?

Hast du mal ein PCAP File aufgezeichnet was für SIP Nachrichten kommen, beim Halten und re-invite?
Wenn da tatsächlich mit dem SIP Server der Dt. Telekom Protokollelemente getauscht werden, dann würde ich PRACK wieder verstehen.
Rein gedanklich hätte ich gedacht, dass die Mitel das intern mit ihrem internen SIP Server macht und WAN seitig den RTP Stream nicht unterbricht, oder mit einem er-invite „umzieht“.
Zumindest sieht der A-Tln nicht die eigentlich Rufnummer (bei mir Durchwahl), nach dem Verbinden, aka COLP.

 

[chrsto]

Deinen letzten Punkt kann ich spontan beantworten.

Mir fiel grade das Template Update von 2016 ein. Damals wurde beim Halten nicht mehr die Wartemusik abgespielt, sondern mit "Ihre Verbindung wird gehalten" vom Provider überlagert.
Ich hab mir die TI nochmal rausgesucht und als letzter Punkt wird aufgeführt, dass bei Rückfragen ein Reinvite an den Provider geschickt wird. Damit sollte PRACK auch wieder sinn machen.

 

[mschoenb]

Warum stellst du das nicht um, dass du das Gespräch in der Anlage hältst?

 

[chrsto]

Das Gespräch wird ja in der Anlage gehalten. Immerhin höre ich die Wartemusik der Anlage. Trotzdem wird lt. dem Mitel Dokument auch dann ein Reinvite an den Provider geschickt.
Davon abgesehen kenne ich nur die Einstellung für Rufumleitung intern/extern. Wo, oder ob man auch "Halten" umstellen kann, wüsste ich grade nicht.

Allerdings hat sich auch schon die Telekom zurück gemeldet. Es gibt Paketverluste auf dem Anschluss. Also erstmal weiter abwarten.

 

[chrsto]

Kleines Update:

Zwischenzeitlich hat die Telekom Paketverluste an dem Anschluss bestätigt und auf ADSL2+ GbE umschalten lassen. Damit sind nun fast alle Probleme weg.

Da nun die Leitung sauber ist, konnte ich den Fehler beim Vermitteln auf bestimmte Rufnummern eingrenzen und entsprechende Mitschnitte erstellen.

Es scheint wohl Probleme mit dem Codec zu geben.

Anruf kommt rein und wird signalisiert -> g711
Anruf wird von NSt. 10 entgegen genommen und gesprochen -> g722
NSt. 10 drückt Besetzttaste (NSt. 30) zum Vermitteln, Anrufer hört Wartemelodie -> g711
NSt. 10 legt auf und übergibt so Anruf, Anruf wird NSt. 30 signalisiert, Anrufer hört tuten -> g711
Anruf wird von NSt. 30 entgegen genommen -> g722 (Gesprächspartner verstehen sich nicht mehr, externer Anrufer ist aber im Mitschnitt zu hören)

Beim Wechsel von HQ Audio auf Standard in den Leitungseinstellungen mit durchgehendem g711 gibt es keine Probleme.

Edit:

Ergänzung: NSt. 30 funktioniert grundsätzlich. Werden von hier aus Gespräche geführt oder externe direkt entgegen genommen, ist eine Verwendung von g722 kein Problem.

 

[chrsto]

Rückmeldung von Mitel: Problem ist bekannt, wird mit nächster Telefonfirmware (5.1, geplant letztes Quartal) behoben.

 

[mschoenb]

Dann wird aber das Endgerät upgegraded, und nicht die FW der Mitel100, korrekt?


Gesendet von iPhone mit Tapatalk

 

[avm_7170]

Dieses Fehlerbild habe ich wenn bei DECT Telefonie das HD aktiviert ist, dann bleibt bei internen Telefonaten das Gespräch in ersten 28 Sekunden stumm ...bis das HD Zeichen am Telefon erscheint ...wird das HD deaktiviert .... kommt es nicht zu dieser Zeit das das Gespräch stumm ist ....
Mein Provider ist VODAFONE ....

 

[chrsto]

Korrekt.

(Ups, da war avm_7170 schneller, die Antwort bezieht sich auf #15 von mschoenb)


@avm_7170 sprichst du von reinen internen Telefonaten oder auch von vermittelten Gesprächen? Bei letzterem kannst du mal testweise PRACK (s.o.) ein- bzw. ausschalten.