Hallo,

wir nutzen PhonerLite an unserer Asterisk 1.8 und starten ausgebende Anrufe auf passive Art und Weise über das AMI.
Dort wird die so genannte Action: ORIGINATE ausgeführt und die Asterisk Anlage baut den ausgehend Anruf auf.
Dabei wird erst die Nebenstelle und das PhonerLite des Mitarbeiters angerufen. PhonerLite nimmt automatisch an und erst dann wählt die Asterisk Anlage die externe Nummer (über QSC SIP) und bridged beide Kanäle. Im Normalfall hört der Mitarbeiter dann unmittelbar das Freizeichen bis der Angerufene angenommen hat. Die IN und OUT Codecs werden dabei ca. 2 Sekunden nachdem PhonerLite automatisch angenommen hat angezeigt.

Das Problem entsteht, wenn die Anwahl der externen Nummer länger dauert und beispielsweise Mobilrufnummern angewählt werden.

Ein Sip Trace auf der Anlage und Debug-Log vom PhonerLite sagen mir, dass das PhonerLine, obwohl es den Anruf von der Anlage automatisch angenommen hat (200 OK und ACK), nach genau 5s noch mal ein INVITE an seine eigene Nebenstelle an die Asterisk Anlage sendet.

Der Mitarbeiter kann die beiden Fälle nicht/nur schwer unterscheiden und der ausgehende Anruf wird im Fehlerfall auch erstmal aufgebaut. JEDOCH hört der Mitarbeiter dann den Angerufenen nicht (auch kein Ausschlag bei Statistik->Empfang) und das Gespräch wird nach genau 30 Sekunden vom PhonerLite beendet.
Außerdem ist im Asterisk SIP Trace auffällig, dass ab dem ACK  auf das 200-OK für das vom PhonerLite generierte INVITE bis zum BYE nur noch unleserliche Nachrichten (als wären Sie verschlüsselt) im Logfile ankommen. Die Nachrichten gehen dabei an die Anlagen Ports 5060 und 19228. Unsere Anlage lauscht SIP-technisch allerdings auf einem andern Port.

Zur Gegenprüfung habe ich das Ganze auch mal mit SNOM Hardhpones und NinjaLite durchgespielt. Dort kommt es nicht zu den besagten Problemen.

Hat Jemand ein ähnliches Problem oder weiß jemand Abhilfe?

Hallo,

es lag tatsächlich am ausbleibenden/verpäteten RTP Empfang. RTP kommt beim besagten Szenario bei Mobilrufnummern erst nach ca. 7 Sekunden.  Nach dem Abschalten des re-INVITE in der sipper.ini funktioniert es nun wie gewünscht.

Vielen Dank für die schnelle Hilfe. Top!

Nein, scheint leider nicht der Fall zu sein.
Im Sip Trace im INVITE ist kein Alert-Info-Header zu finden.
Sieht für mich aus wie jeder andere eingehende Anruf.
Beim AMI-Kommando ORIGINATE kann ich imho auch nichts derartiges als Parameter übergeben.

Ist aber nicht so schlimm, uns ist erstmal mit RTPoverSIPFallback=0 geholfen.