[Gelöst] Telekom PJSIP kein Rufzeichen

[Tom-VoIP]

Hallo Zusammen,

da die Telekom beim mir kein Legacy SIP mehr unterstützt, musst ich auf PJSIP umstellen.

Nun habe ich das Problem, dass meine Anrufer kein Freizeichen erhalten. Ich habe ein Workaround gefunden: Inbound Route\Advanced > Signal-Ringing & Force Answer = Yes



Allerdings wird das Freizeichnung jetzt via RTP Stream von der Asterisk abgespielt. Einmal hört sich das vom Handy wie ein Ferngespräch in den Dschungel an und zweites läuft das Gespräch sofort, sprich das Handy zeigt sofort an Gesprächszeit = xx Sekunden.

Daher möchte ich diesen Workaround nicht.

Kammann schreibt, dass man in der Ring Group als auch Inbound Route "Send Progress" auf yes stellen soll. Leider funktioniert das bei mir nicht. Egal ob Ringgroup oder Nebenstelle.

pjsip kein Rufzeichen beim Anrufer

Hallo, ich habe seit einiger Zeit das Problem, dass Anrufer aus den Netzen von Telekom und QSC kein Rufzeichen hören, wenn sie eine meiner mittels FreePBX am Telekom-Anschluss registrierten Rufnummern anrufen. Wenn ich abhebe kommt das Gespräch normal zustande - leider irritiert das fehlende...

www.ip-phone-forum.de

Hier ein sngrep:


Danke für eure Hilfe !

Software: FreePBX 16, Asterisk 19.3 auch mit Asterisk 16.27 getestet.


Bild(er) gemäß Boardregeln als Vorschaubild(er) eingebunden by stoney

 

[Tom-VoIP]

Nachtrag, ich habe es geschafft ein gewohntes Freizeichen einzurichten Freepbx Advanced Setting > Country Indication Tones:



https://en.wikipedia.org/wiki/Ringing_tone

Jezt bleibt "nur" das Problem, dass das Gesprch sofort startet, ob es noch klingelt:



Welches dadurch erzeigt wird, dass ich in der Inbound Route "Force Answer" gesetzt habe. Aber ohne "Force Answer" gibt es keinen Klingelton.

 

[gehtdoch]

Hallo @Tom-VoIP ,
ich bin erstaunt, wie man das schaffen kann, was Du geschafft hast .

Das Problem, das Du beobachtest, ist, dass von außen eingehende Anrufer kein ring back (Klingelton) erhalten. Du hast zu Analysezwecken einen SIP-Trace ("sngrep") zur Verfügung gestellt - aber leider fehlt der inbound leg (also der eingehende Call von Telekom zu asterisk). Dummerweise ist genau der der entscheidende, weil man ausschließlich in diesem leg sieht, was das Problem ist (natürlich abhängig vom outbound leg, den Du gezeigt hast - oder in anderen Worten, es werden beide legs benötigt!).

Deine ganzen Ansätze bisher sind nicht der richtige Weg. Zeige erstmal beide Legs, dann sieht man weiter. So wie hier: Der Call geht ein (Invite), wird an ein internes Device weitergegeben (das 2. Invite), welches dann u.a. ein 180 Ringing zu Asterisk sendet, welches der dann weiterschiebt zum Provider. Das 180 Ringing ist dafür verantwortlich, dass der Anrufer ein Ringback "bekommt" - was aber nichts anderes ist, als dass dem Telefon des Anrufers mitgeteilt wird, dass es nun selbst ein ring back erzeugen soll.

 

[Tom-VoIP]

Hallo @gehtdoch,
danke für dein Nachricht ! Ja das Erstaunen liegt ganz auf meiner Seite

sngrep zeigt keine TLS Sessions, daher musste ich zunächst auf tcp umstellen. Hier der hoffentlich richtige Trace:

Von Telekom=>Asterisk und Asterisk=>PhonerLite


Asterisk ist übrigens 192.168.66.4 und 192.168.66.11 mein PC.

Wenn ich das richtig analysiere fehlt ein 180 im Telekom leg.

Danke vorab !!!

PS: Registiere ich die Telekom Nummer in PhoneLite. Ist alles ok. Daher muss es wohl eine FreePBX Baustelle sein ?!

 

[gehtdoch]

Hallo @Tom-VoIP ,
ja, Asterisk macht da inband ringing (183 Session Progress mit SDP) - das funktioniert üblicherweise bei keinem Provider der Welt, bei dem Du bezahlen musst, weil ja zu dem Zeitpunkt das Gespräch noch nicht zustande gekommen ist (-> der Gebührenzähler läuft noch nicht - damit ist auch der RTP-Strom geblockt - sonst könntest Du ja Informationen zum Nulltarif übermitteln).

Ergo geht es darum, Asterisk das Inband ringing im trunk abzugewöhnen. In Connectivity -> Hauptleitungen -> [Deine Hauptleitung] -> pjsip-Einstellungen -> erweitert gibt es die Einstellung "inband progress" -> die muss auf nein gesetzt werden.

[Ergänzung]
Falls obige Einstellung nicht zieht, gibt es noch die Möglichkeit, in der Inbound Route unter erweitert "Signal ringing" zu aktivieren. Ist aber zumindest bei mir nicht nötig - wobei das auch immer davon abhängt, wie der eingehende Call in FreePBX weiterverarbeitet wird. Ich meine mich noch dunkel daran erinnern zu können, dass ich das Thema viel früher mal in einem spezifischen Szenario hatte.
[/Ergänzung]

Die komplette bebilderte Konfig via FreePBX findest Du hier (Achtung: die Einstellungen dort sind noch nicht für Verschlüsselung vorgesehen - tut aber in diesem Fall hier nichts zur Sache - verschlüsselungsrelevante Einstellungen dürfen also nicht einfach so übernommen werden).

Zum Thema (SIP-)Traceerfassung. Asterisk bietet die Möglichkeit, das intern zu machen. Dann bekommst Du das so, wie es auch in meinem Screenshot zu sehen ist (beide Calllegs in einem File):

asterisk -x "pjsip set logger on"
asterisk -x "pjsip set logger verbose off"
asterisk -x "pjsip set logger pcap trace.pcap"

In /var/log/asterisk (oder geneuer: im Workingdirectory) findest Du dann die trace.pcap.

Falls Asterisk mit systemd gestartet wurde kannst Du das explizit definieren unter [Service] mit WorkingDirectory=/var/lib/asterisk
z.B.

Der Vorteil dieser Einstellung: das funktioniert auch mit TLS im SIP, weil asterisk ja natürlich vorher entschlüsselt . Dann musst Du zum Tracen nicht extra umstellen.
Es ist aber zu beachten, dass bei jedem Restart oder auch nur reload von Asterisk, diese Einstellung verloren geht. Beim Neuanlegen wird eine evtl. vorhandene Tracedatei überschrieben.

 

[Tom-VoIP]

Hallo @gehtdoch,

du bist mein HELD !!! SUPER ✔

VIELEN VIELEN VIELEN VIELEN VIELEN DANK FÜR DEINEN SUPPORT. Da habe ich jetzt euch Tage dran gesessen.

Wohin darf ich den Präsentkorb senden ?!?

Nochmal Danke für die tolle Erklärung

 

[Meester Proper]

Hallo @Tom-VoIP ,
ja, Asterisk macht da inband ringing (183 Session Progress mit SDP) - das funktioniert üblicherweise bei keinem Provider der Welt, bei dem Du bezahlen musst, weil ja zu dem Zeitpunkt das Gespräch noch nicht zustande gekommen ist (-> der Gebührenzähler läuft noch nicht - damit ist auch der RTP-Strom geblockt - sonst könntest Du ja Informationen zum Nulltarif übermitteln).

Also bei den Durchwahlanschlüssen auf Basis DeutschlandLAN SIP-Trunk oder CompanyFlex SIP-Trunk ist dies möglich, da kann die TK-Anlage als Anrufziel einen eigenen Progress-Ton ins Netz senden, ohne dass das Gespräch final angenommen wurde.
Es wird hier allerdings auf Basis der Early-Media Policy (Siehe P-Early-Media Header) das RTP vom Anrufer zum Anrufziel geblockt - es könnte also noch kein Gespräch geführt werden.

 

[gehtdoch]

Danke für Deine Ergänzung @Meester Proper . Ich hätte besser formulieren sollen: man kann nicht davon ausgehen, dass ein Provider Early Media unterstützt. Die beiden von Dir genannten Produkte ordne ich im Business Bereich ein - da dürfte dieses Feature eher üblich sein. Oder ist das ein Telekom-Thema, um die Produkte besser voneinander abzugrenzen auf Feature-Ebene?

Mit 180 Ringing fährt man auf jeden Fall sicherer und v.a. richtig (solange man nicht wirklich Early Media nutzen möchte).

 

[Meester Proper]

Vollzitat gemäß Boardregeln entfernt by stoney

Richtig, nur bei den Business SIP-Trunking Produkten DeutschlandLAN / Corporate SIP-Trunk sowie CompanyFlex SIP-Trunk ist die Early Media Durchleitung garantiert, also das Einspielen bspw. eines eigenen Ringtones...

Aber du hast recht, mit nur einer 180 Response ist man deutlich sicherer, da auch nicht alle Provider immer Early Media durchstellen...

 

[gehtdoch]

@Meester Proper Was ich seit längerem auch immer wieder sehe, ist folgende Vorgehensweise (allerdings bei ausgehenden Calls) vom Callee kommend als Reaktion auf den Invite:

100 Trying
183 Session Progress (ohne SDP)
180 Ringing (mit SDP - knapp eine Sekunde nach dem 183 ohne SDP)

Daraus mache ich im Asterisk zum Caller (zunächst):
180 Ringing (als Reaktion auf das 183 ohne SDP) -> Damit generiert mein Telefon erstmal das Ringback

Das folgende 180 Ringing (mit SDP) wird als 183 mit SDP weitergegeben.
Nun hört man (in diesem Fall) das inband Ringback (das unterscheidet sich hörbar vom eigen generierten Ringback)

Das 180 Ringing mit SDP kommt mit dem Header:

P-Early-Media: sendonly, gated

aber im SDP:

a=sendrecv

Ist ja zumindest leicht widersprüchlich.

 

[Meester Proper]

Vollzitat gemäß Boardregeln entfernt by stoney

Das ist nicht widersprüchlich.
Der PEM-Header beschreibt die Early-Media Policy (bis zum 200 OK), während das Richtungsattribut in der SDP Answer für die gesamte Session gilt.

Der Inhalt des PEM-Headers ist mit der 200 OK irrelevant, in diesem Moment muss das Endgerät das Mikrofon für die beidseitige Kommunikation dann öffnen.

 

[gehtdoch]

Verstehe. Asterisk kümmert sich nicht darum - der kennt kein RFC 5009 bzw. PEM-Header.

Ist aber auch nicht nötigt, weil das Ganze ja abwärtskompatibel ist - wird ja dann (in diesem Fall) von der Telekom entsprechend gesteuert. Asterisk behandelt den SDP-Stream wie einen bidirektionalen Stream. Das schadet ja niemandem und stellt sicher, dass man was hört - falls denn was kommen sollte.

 

[Meester Proper]

Gut, es gibt aber gerade in Kombination mit VoLTE-Endgeräten Situationen da wird schon eine SDP Answer übertragen, aber es soll dennoch ein Local Ringtone generiert werden, dort wird dann PEM: inactive übertragen.
Bei Endgeräten mit PEM-Unterstützung führt das dann dazu, dass ein Local Ringtone angelegt wird, trotz vorliegender SDP Answer, ohne RTP-Übertragung. Bei Endgeräten ohne PEM-Unterstützung würde das dann zu Stille führen, obwohl es eigentlich "klingeln" sollte.

 

[gehtdoch]

es gibt aber gerade in Kombination mit VoLTE-Endgeräten Situationen da wird schon eine SDP Answer übertragen, aber es soll dennoch ein Local Ringtone generiert werden, dort wird dann PEM: inactive übertragen.

Meinst Du das so, dass im 183 oder 180 ein SDP enthalten ist - aber gleichzeitig PEM inactive gesetzt ist? Habe ich das so richtig verstanden? Dann müsste man an dieser Stelle noch zusätzlich auf den PEM Header prüfen und entsprechend ein 180 ohne SDP weiterreichen zum Caller, so dass sichergestellt ist, dass der Caller das Ringback selbst erzeugt.
Kann man davon ausgehen, dass man ihn nutzen kann, wenn sendonly oder sendrecv enthalten ist - oder muss man auch dann noch davon ausgehen, dass man in der Stille landet (von Bugs abgesehen)?

Ich frage mich: was ist der use case dieses Szenarios? Schonmal im Vorfeld sämtliche Ports über sämtliche Firewalls oder andere Funktionen / Devices "vorbereiten", damit beim eigentlichen Gesprächsbeginn keine Pakete verloren gehen?

 

[Meester Proper]

Meinst Du das so, dass im 183 oder 180 ein SDP enthalten ist - aber gleichzeitig PEM inactive gesetzt ist? Habe ich das so richtig verstanden? Dann müsste man an dieser Stelle noch zusätzlich auf den PEM Header prüfen und entsprechend ein 180 ohne SDP weiterreichen zum Callee, so dass sichergestellt ist, dass der Callee das Ringback selbst erzeugt.
Kann man davon ausgehen, dass man ihn nutzen kann, wenn sendonly oder sendrecv enthalten ist - oder muss man auch dann noch davon ausgehen, dass man in der Stille landet (von Bugs abgesehen)?

Ja, dort wird ein 183 mit SDP und danach 180 gesendet, während PEM: inactive ist.
Bei PEM: sendonly und PEM: sendrecv kann man davon ausgehen, dass auch RTP fließt.

Ich frage mich: was ist der use case dieses Szenarios? Schonmal im Vorfeld sämtliche Ports über sämtliche Firewalls oder andere Funktionen / Devices "vorbereiten", damit beim eigentlichen Gesprächsbeginn keine Pakete verloren gehen?

Nein, das passiert, weil das VoLTE Geräte damit den (Voice) Bearer aufbaut:

https://static.wixstatic.com/media/b5b4ea_8c99997458964d2581b89e64d73c03e4~mv2.png/v1/fill/w_897,h_491,al_c,q_90,enc_auto/b5b4ea_8c99997458964d2581b89e64d73c03e4~mv2.png

04. VoLTE SIP Call Flow – Mobile Originating (MO) & Terminating (MT)

SIP Call Flow - Mobile Originating (MO) & Terminating (MT) - INVITE - 100 Trying - 183 Progress SDP - PRACK - 200 OK - UPDATE - 180 Ringing

www.telecomtutorial.info

Aktuell kommt diese Signalisierung noch nicht im Festnetz an, weil noch Intermediäre dazwischen geschaltet sind, die diese Signalisierung verändern. Aber sobald VoLTE Direct Routing umgesetzt ist, kann diese Signalisierung ins Festnetz herüberschwappen...

 

[gehtdoch]

Danke für die super Infos!

Ja, dort wird ein 183 mit SDP und danach 180 gesendet, während PEM: inactive ist.

Sehr gut, dann genügt eine einfache Prüfung auf das Vorhandensein eines SDP definitiv nicht mehr, sondern es muss explizit der PEM Header ausgewertet werden, um zu entscheiden, was man konkret an den Caller weitergibt. Das nachgeschobene 180 ohne SDP, um lokales ring back zu erzeugen, soll ja dem Vernehmen nach nicht bei allen Devices funktionieren, wenn man vorher schon einen 183 mit SDP übermittelt hat. Dann werde ich mal einen Patch für Asterisk vorbereiten, der dieses Szenario abdeckt - nicht dass am Ende das ring back ausfällt beim Caller ...

Noch eine Frage zum PEM-Header: da steht ja vermutlich nicht nur "inactive", sondern sowas wie "inactive, gated"?

 

[Meester Proper]

Noch eine Frage zum PEM-Header: da steht ja vermutlich nicht nur "inactive", sondern sowas wie "inactive, gated"?

Ja, das "gated" kann enthalten sein, muss aber nicht. Es ist optional.

 

[gehtdoch]

Hier ist übrigens ein Patch für Asterisk 18.19.0 wie ich ihn schon länger verwende.