[Gelöst] Telekom PJSIP kein Rufzeichen

Tom-VoIP

Neuer User
Mitglied seit
14 Mai 2018
Beiträge
23
Punkte für Reaktionen
0
Punkte
1
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

2022-08-01 20_34_41-FreePBX Administration.jpg

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.

2022-08-01 20_35_33-FreePBX Administration.jpg

Hier ein sngrep:
2022-08-01 20_33_06-root@freepbx_~.jpg

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
 
Zuletzt bearbeitet:
Nachtrag, ich habe es geschafft ein gewohntes Freizeichen einzurichten :) Freepbx Advanced Setting > Country Indication Tones:

2022-08-02 12_27_23-FreePBX Administration.jpg

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

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

iphone.jpg

Welches dadurch erzeigt wird, dass ich in der Inbound Route "Force Answer" gesetzt habe. Aber ohne "Force Answer" gibt es keinen Klingelton.
 
Zuletzt bearbeitet:
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.

sip-invite.png
 
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
2022-08-04 11_52_41-root@freepbx_~.jpg 2022-08-04 11_58_26-C__Users_Thomas_Desktop_Hardcopy_2022-08-04 11_52_41-root@freepbx_~.jpg - ...jpg

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 ?!
 
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):

Code:
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.
 
Zuletzt bearbeitet:
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
 
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.
 
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).
 
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...
 
Zuletzt bearbeitet von einem Moderator:
@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:
Code:
P-Early-Media: sendonly, gated

aber im SDP:
Code:
a=sendrecv

Ist ja zumindest leicht widersprüchlich.
 
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.
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: 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.
 
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.
 
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?
 
Zuletzt bearbeitet:
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:



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...
 
  • Like
Reaktionen: 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"?
 
Hier ist übrigens ein Patch für Asterisk 18.19.0 wie ich ihn schon länger verwende.
 

Anhänge

  • ignore_183_wo_sdp-4.diff.zip
    1,020 Bytes · Aufrufe: 10

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,691
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.