[Problem] Asterisk ankommend --> ausgehend kein Ton

[Ossie]

Hallo Forumsmitglieder,
ich bin neu in diesem klasse Forum - herzliche Grüße an alle!
Ich bin alter IT- und Netzwerkhase und habe auch bei meinen Kunden in den vergangenen Jahren mittlere bis größere ISDN-Anlagen installiert und betreut.
Da im Moment ja die große Zwangsumstellungs-Welle ISDN auf VoIP immer noch rollt, beschäftige ich mich seit einem Jahr immer mal wieder mit Asterisk.
Mittlerweile habe ich bei zwei Kunden (die mit der Fritzbox nicht auskommen ...) einen Linux-Pc mit Asterisk 15.4.1 und entsprechenden SIP-Telefonen aufgestellt.

Alles funktioniert prima, ankommend als auch ausgehend. Aber ein Problem habe ich bisher nicht lösen können.

Der Kunde hat einen Notdienst. Abends nach Feierabend wird eine Weiterleitung auf das Telefon des Mitarbeiters, der Notdienst hat, eingeschaltet.
Kommt ein Anruf, wird der sofort weitergeleitet. Das Telefon des Mitarbeiters klingelt, aber nach dem Abheben ist Stille - kein Ton.
Nach langem Recherchieren habe ich in den PJSIP-Endpoint des Providers den Parameter "inband_progress=yes" eingefügt. Ab da war der Ton da, die Teilnehmer konnten sich unterhalten.
Aber: nun hört der Anrufer keinen Rufton mehr. Es herrscht Stille, bis der Notdienst-Mitarbeiter abnimmt.

Seitdem recherchiere und probiere ich herum. Obwohl "normale" Telefonate (rein und raus) funktionieren, ohne Ports am Router weiterzuleiten, habe ich diverse Ports (5060 und 10000-20000) im Router geöffnet, ohne Verbesserung. SIP-ALG ist ausgeschaltet.

Nochmal: es betrifft nur Telefonate, die reinkommen und gleich wieder (per Dial-Funktion) wieder rausgehen.

Ich bin ratlos. Hat jemand mit mehr Erfahrung einen heißen Tipp für mich?

Gruß Ossie

 

[koyaanisqatsi]

Moinsen


Progress() wird auch gerne für "Early Media" genutzt.
Versuchs doch mal ohne Progress aber mit einem Flag im Dial() ...
Dial(PJSIP/whatever,120,m(default))
...hört der Anrufer "Early Media" anstatt "Tuuuut .... Tuuuut" ?

PS: Kenn mich mit der PJSIP Syntax ( noch nicht ) so gut aus
PPS: Welcome aboard

 

[Ossie]

Hallo koyaanisqatsi,
>> PPS: Welcome aboard
Danke - und danke für Deine schnelle Antwort.
Ich habe deinen Tipp gleich mal ausprobiert.
"inband_progress" wieder rausgenommen, "m(default)" ans Dial-Kommando gehängt.
Jetzt ist auch ohne "inband_progress" erstaunlicherweise Ton da, man kann miteinander reden.
Aber: Jetzt ist auch ohne "inband_progress" kein Rufton zu hören.
Arghhh!!!

 

[koyaanisqatsi]

Das ist korrekt
Das Flag m() sollte statt "Tuuut Tuuut" nämlich "Music on hold" abspielen.
...macht aber, genau wie Progress(), die Audiokanäle ( RTP ) vor einem Abnehmen auf.
Hast du keine moh konfiguriert/aktiviert (musiconhold.conf) ?
Denn dort liesse sich eine Klasse für "Early Media Ansage"/MoH in der Form hinterlegen...
"Bitte warten - Ein Mitarbeiter ist gleich für sie da"

 

[sonyKatze]

Kommt ein Anruf, wird der sofort weitergeleitet. Das Telefon des Mitarbeiters klingelt, aber nach dem Abheben ist Stille […] inband_progress=yes […] nun hört der Anrufer keinen Rufton mehr

Bei solchen Feinheiten bist Du erstmal auf Dich allein gestellt. Du bist gezwungen genau zu analysieren, was überhaupt auf den beiden Leitungen passiert. Eine Möglichkeit ist Wireshark mitlaufen zu lassen.

1. Welche Statūs erhältst Du vom Provider: Trying (100) und dann Ringing (180) oder Progress (183)?
2. Welche Statūs gibst Du weiter?
3. Falls Du 183 erhältst, ist darin SDP enthalten; kommt bereits RTP?
4. Falls Du RTP erhältst, wohin (IP-Adresse : Port) gibst Du dieses RTP weiter?
5. Falls Du SDP erhältst, wie ist die Direction? a=sendonly

Daher bitte nicht Recherchieren, sondern erstmal analysieren und berichten. Für den Start würde ich ein Dial() ganz ohne irgendwelche Optionen nutzen.

 

[Ossie]

Hallo koyaanisqatsi:
Du hast mich auf den richtigen Weg geschubst.
Ich habe mit MOH herumgespielt und diverse Variationen ausprobiert. Wie Du schon schriebst: MOH öffnet die Audiokanäle.
Weiteres Lesen in der Asterisk-Bibel (O'Reilly: "Asterisk - The Definitive Guide") brachte mich zur "Answer()"-Funktion. "Progress()" hatte ich vorher schon mal ohne Erfolg ausprobiert, aber "Answer()" hat's dann gebracht!

Bei dem Kunden läuft das so: Der Chef drückt bei Feierabend eine "forward"-Taste an seinem Telefon. Kommt ein Anruf (im Kontext "ankommend"), meldet Asterisk
"302 moved temporarily"
"Now forwarding PJSIP/49xxxxxx-00000039 to 'Local/0xxxxxxxx@intern' (thanks to PJSIP/jens20-0000003a)"
Der Anruf geht in den Kontext "ausgehend". Dort frage ich den Channeltype ab. Ist er "Local", mache ich "Answer()" und anschließend den "Dial()". Ist der Channeltype nicht "Local", wird der "Answer()" übergangen.
Nun klappt alles - ohne "inband_progress" (welches ja den Rufton killte) und sogar ohne "m" im Dial-Kommando - man hört das (Asterisk-generierte) Rufzeichen.

Danke für Deinen Anschubser!

sonyKatze:
Du hast natürlich völlig recht: Bei Problemen geht nichts über systematisches Sammeln von Informationen, um dann analysieren zu können. Als jemand, der in der Vor-PC-Zeit Mainframes installiert und repariert hat, habe ich (manchmal schmerzhaft ...) gelernt, wie wichtig das ist.

Ich habe natürlich mit "PJSIP set logger on" Daten gesammelt und z.B. dabei gesehen, daß ein "Ringing (180)" rausging. Aber Du weißt ja auch, daß das alles sehr aufwendig (und vor allem zeitaufwendig) ist - und mir saß die Zeit (sprich: der Kunde) im Nacken - und so habe ich eben herumprobiert - sorry.

An beide:
Seitdem ich mich mit Asterisk beschäftige, habe ich Stunden über Stunden recherchiert, viele, viele Internetseiten (auch die originalen von Digium, asterisk.org usw.) gelesen und viele Foren besucht. Dabei hat man viel über Detail-Lösungen von speziellen Problemen gelernt.

Aber irgendwie sind das alles immer nur Bruchstücke. Was ich vermisse, ist eine umfassende Übersicht über die gesamten Zusammenhänge - die Logik, die dahinter steckt - was an einzelnen Schritten passiert (oder passieren muß), damit ein Anruf erfolgreich ist. Wer sendet welche Nachrichten wohin, welche Pakete verschiedensten Inhalts von wem wohin geschickt werden und wie beantwortet werden müssen. Im Groben weiß man das eigentlich, aber wenn man ein Problem lösen muß, kommt es ja auf das Detail an. Siehe mein geschildertes Problem - jetzt scheint es zu klappen, aber warum genau es jetzt funktioniert, kann man nur vermuten.

Ich habe natürlich viel in der Asterisk-Bibel gelesen (ich hatte eine ältere Version als PDF). Mit deren Hilfe kann man sich sehr schnell einen kleinen funktionierenden Dialplan zusammenbauen - aber das große umfassende Hintergrundwissen finde ich da nicht.

Ich habe mir sogar kurzfristig die neueste (5.) Ausgabe beschafft, die schon Asterisk 16 abdeckt. Ich war etwas schockiert: Die wichtige "pjsip.conf" und deren Inhalt wird gar nicht erwähnt, sondern beschrieben, wie man mit händisch einzugebenden SQL-Befehlen die Daten in die Asterisk-Datenbank einspeist.

Geht's noch? Ein Asterisk-Anfänger (und das sind ja die, die in dieser Bibel lesen) muß jetzt auch noch SQL-Befehle können? Eine Textdatei ist doch viel schneller und einfacher geändert, wenn man erstmalig herumprobiert, als wenn man die Daten in der Datenbank umständlich mit "Insert-", "Delete-" und "Update"-Befehlen bearbeiten muß. Und "Music on Hold" finde ich in dieser Ausgabe nicht mal im Stichwortverzeichnis ....

Tja - genug gejammert. Trotzdem halte ich Asterisk für eine tolle Software und werde mich weiter damit beschäftigen.

Ich danke Euch beiden für Mühe, Zeit und Hilfe und kämpfe weiter.

Wie sagt dieser Naturmensch im Fernsehen immer am Ende seiner Sendung? "Bleiben Sie fasziniert" ....

 

[sonyKatze]

Didaktik in der Informatik … Problem bei SIP ist, dass es so flexibel ist, dass es kaum eine Antwort gibt. Teilweise findest Du in Hochschul-Vorlesungen Diagramme, wie einige Fälle normalerweise ablaufen, siehe Universität Ulm. Teilweise in SIP-Schulungen. Teilweise in RFCs, siehe 3665 und 5589. Aber solche Dinge katalogisiert eine Internet-Suchmaschine falsch. Wenn ich eine SIP-Fibel finde, in der einfach nur Abläufe dokumentiert sind, poste ich das hier. Übrigens mein Tipp: Wenn Du beim Kunden schon reine VoIP/SIP-Infrastrukturen hast, würde ich statt Asterisk mal FreeSWITCH anschauen. Dessen Kern ist nicht wie bei Asterisk SS7 sondern schon rein SIP. Das macht einiges einfacher.

 

[sonyKatze]

Hat meine Link-Liste geholfen?

Answer() hat’s dann gebracht

Bin mir alles andere sicher, ob das der richtige Weg ist. In meiner kleinen Welt wäre der richtige Weg nicht den Audio-Kanal aufzumachen sondern die richtigen SIP-Statūs zu senden.

 

[Ossie]

Hallo sonyKatze,
ich bin (angenehm ...) überrascht, daß Du dich nach so langer Zeit noch zu diesem Thread meldest.
Ich schrieb weiter oben:
--------------------------
Bei dem Kunden läuft das so: Der Chef drückt bei Feierabend eine "forward"-Taste an seinem Telefon. Kommt ein Anruf (im Kontext "ankommend"), meldet Asterisk
"302 moved temporarily"
"Now forwarding PJSIP/49xxxxxx-00000039 to 'Local/0xxxxxxxx@intern' (thanks to PJSIP/jens20-0000003a)"
Der Anruf geht in den Kontext "ausgehend". Dort frage ich den Channeltype ab. Ist er "Local", mache ich "Answer()" und anschließend den "Dial()". Ist der Channeltype nicht "Local", wird der "Answer()" übergangen.
----------------------------------
Das Forwarding macht ja das SIP-Telefon alleine (Transfer-Taste). Dann läuft ja der oben beschriebene Mechanismus an.
Wie würdest Du das lösen (SIP-Status senden)? Hast Du dafür mal ein Dialplan-Beispiel?

Gruß Ossie

Eigentlich müsstest Du nur die Statūs durchreichen. Daher steht immer noch die Frage im Raum, welche Statūs Du bekommst, wenn Du weiterleitest. Irgendwas ist auf diesem Teilstück krumm. Soweit ich das verstanden habe: Der Anruf wird weitergeleitet und an irgendeinen VoIP/SIP-Anbieter übergeben. Der wiederum leitet ins alte Telefonnetz. Dein VoIP/SIP-Anbieter gibt Dir während dem Ganzen verschiedene Statūs. Welche bekommst Du bevor der Ruf aufgebaut ist? Und dann die anderen fünf Fragen oben.

 

[gehtdoch]

Hallo Ossie,
aus meiner Sicht gehst Du einen unnötig aufwändigen Weg und machst Dir Gedanken über Dinge, die andere für Dich längst gelöst haben - mit einem Klick bekommst Du derartige 0815-Anforderungen mit viel geringerem Aufwand auf GUI-Ebene gelöst.

Ich würde Dir empfehlen, mal FreePBX z.B. anzuschauen. Da hast Du gleich mehrere Dinge auf einen Schlag:

• einen SIP-Server (wie Asterisk)
• eine mächtige Web-GUI für die strukturierte Verwaltung der gesamten Telefonanlage
• eine Web-GUI für die einzelnen User mit individuellen Rechten je User

Auf diese Weise bekommst Du per Click derart viele Features mit minimalem Aufwand, die sogar nach Anleitung (falls nötig) auch Deine Kunden nutzen können. Im konkreten Fall ist hier die Funktion Follow Me z.B. denkbar. Da kannst Du eingehende Anrufe auf eine Nummer auf beliebig viele andere Nummern (intern und extern) setzen (bei Auswahl unterschiedlichster Konzepte). Ohne auch nur eine Zeile Quellcode / Programmierung anfassen zu müssen.

Aber: nun hört der Anrufer keinen Rufton mehr. Es herrscht Stille, bis der Notdienst-Mitarbeiter abnimmt.

Weiteres Lesen in der Asterisk-Bibel (O'Reilly: "Asterisk - The Definitive Guide") brachte mich zur "Answer()"-Funktion. "Progress()" hatte ich vorher schon mal ohne Erfolg ausprobiert, aber "Answer()" hat's dann gebracht!

Progress dürfte ein 183 session progress generieren. Dieses wiederum spielt ein von Asterisk erzeugtes ring back (im Rahmen von moh) ein - alles, bevor die Verbindung steht (200 OK). Der RTP-Strom wird zu diesem Zeitpunkt logischerweise vom SIP-Provider unterbunden -> daher funktioniert das auch nicht. Mit Answer() hast Du dann die Verbindung akzeptiert (und somit klickt auch der Gebührenzähler für den Caller) - ab jetzt leitet der SIP-Provider auch beliebige RTP-Daten durch (-> Der Caller bezahlt ja - also alles gut).

 

[sonyKatze]

Irgendwie ist mein Post im Post von Ossie gelandet. Wurden die versehentlich zusammengelegt? Egal, also nochmal als eigener Post:

Eigentlich müsstest Du nur die Statūs durchreichen. Daher steht immer noch die Frage im Raum, welche Statūs Du bekommst, wenn Du weiterleitest. Irgendwas ist auf diesem Teilstück krumm. Soweit ich das verstanden habe: Der Anruf wird weitergeleitet und an irgendeinen VoIP/SIP-Anbieter übergeben. Der wiederum leitet ins alte Telefonnetz. Dein VoIP/SIP-Anbieter gibt Dir während dem Ganzen verschiedene Statūs. Welche bekommst Du bevor der Ruf aufgebaut ist? Und dann die anderen fünf Fragen oben.

 

[sonyKatze]

[…] PJSIP-Endpoint des Providers den Parameter inband_progress=yes eingefügt. Ab da war der Ton da, die Teilnehmer konnten sich unterhalten. Aber: nun hört der Anrufer keinen Rufton mehr. Es herrscht Stille, bis der Notdienst-Mitarbeiter abnimmt.

So, heute hatte ich das gleiche Symptom: Gar kein Ton beim Rufaufbau während Asterisk weiterleitet. Bei mir war der Ablauf wie folgt: Provider antwortet nicht mit 180 sondern direkt mit 183. Den darauf folgenden Inband-Progress = RTP-Medienstrom schickt Asterisk an die IP-Adresse aus dem ursprünglichen SIP-INVITE. Weil das Telefon keine öffentliche IP angab und zufälligerweise das gleich Subnetz hatte, schickt Asterisk den Strom lokal. Telefon auf globale Adresse umgestellt. Jetzt hat Asterisk den Strom richtig gesendet. Aber weil das Telefon hinter einer Firewall ist und das Telefon selbst kein Loch „puncht“, also den RTP-Port nicht öffnet, prallen alle RTP-Pakete an der Firewall ab.

Die „Lösung“ ist progressinband=never in der Konfiguratiosndatei sip.conf beim Telefon-Endpoint. Damit wandelt Asterisk alle ankommenden 183 in 180 um. Aber es bleibt ein Workaround, weil so die Ansagen des Mobilfunk-Providers nicht durchkommen, wenn niemand abnahm. Es ist zwar das gleiche Symptom aber nicht dasselbe Symptom – denn ich benutze chan_sip und nicht chan_pjsip, wo es gar kein „never“ als Attribut-Wert dafür gibt.

Den Datenverkehr mitschneiden und die Ursache analysieren ist nötig. In meinem Fall ist es ein Software-Bug (kein punch bei 183) im SIP-Telefon. In Deinem Fall solltest Du wieder einen Schritt zurückgehen, also inband_progress=no setzen (oder besser: Parameter ganz entfernen und Asterisk neu starten). Dann schaust Du, warum die RTP-Ströme nicht zueinander finden. Wenn Du das verstanden hast und doch wieder einen Workaround brauchst, weißt Du auch, welche Fälle Du alle testen musst. Und wenn dann in einem dieser Fälle (wie oben: kein Freiton) wieder ein Workaround brauchst … und so weiter. Am Ende sollte auch stehen, dass Du Dich mit einem Hersteller/Anbieter herumschlagen musst, damit er seinen Fehler behebt. Wenn das nicht fruchtet, setzt Du Dir als langfristiges Ziel dieses fehlerhafte Gerät zu ersetzen.

 

[Ossie]

Hallo @gehtdoch,
danke für Deinen Beitrag (sehe ich leider heute erst).
Ja, als ich anfing, mich ein bißchen mit Asterisk zu beschäftigen, habe ich auch mal testweise mit "FreePBX" herumgespielt - mit dem Hintergedanken, daß der Kunde dann gewisse Dinge selbst mal konfigurieren kann.

Ich war schon etwas erstaunt - das "FreePBX"-GUI halte ich absolut nicht für Endkunden-geeignet. Auch dort muß man eine ganze Menge Hintergrundwissen über die Zusammenhänge haben, und die verwendete Terminologie in der GUI ist auch nicht immer selbsterklärend. Der Chef in einem mittelständischen Unternehmen hat alle Hände voll zu tun, seinen Laden am Laufen zu halten. Sich intensiv mit VoIP-Technik und -Terminologie zu befassen - und daß muß er, auch um die "FreePBX"-GUI richtig(!) zu bedienen - da hat er gar keine Zeit für und auch kein Interesse dran - es sei denn, er wäre ein ausgesprochener Technik-Freak. Auch sowas gibt es, aber eher selten.

Und wenn man die vielen, vielen "FreePBX"-betreffenden Hilferufe in den Foren so liest - so ganz ohne ist das auch nicht.

Ich habe dann nach diesen ersten Erfahrungen "FreePBX" wieder de- und das pure Asterisk installiert - auch natürlich, um zu lernen, wie das geht und was da so abläuft. Und mit dem puren Asterisk hatte ich deutlich schneller kleine Testerfolge als mit "FreePBX".

Hallo @sonyKatze,
nach so langer Zeit noch ein Beitrag zu einem eigentlich längst abgehakten Thema - ich bin begeistert!

Und an deinem Beitrag (und den Beiträgen vieler anderer in diesem Forum) merke ich, daß mir noch sehr viel an Detailwissen über SIP im allgemeinen und Asterisk fehlt. Weiter oben hatten wir kurz schon mal dieses Thema - Didaktik in der Informatik ....

Und weiter oben hatten wir auch schon mal über das sammeln und analysieren von Informationen (Logs, Netzwerk-Mitschnitte usw.) geschrieben. Nach wie vor gebe ich Dir da 100%ig recht.

Mein Problem als selbständiger Einzelkämpfer: Sammeln und analysieren kostet meist sehr, sehr viel Zeit und Geduld. Und in fast allen Fällen ist das vor Ort beim Kunden so gut wie unmöglich, ohne den Betrieb aufzuhalten oder stillzulegen (oder den Kunden zu nerven ...).

In einigen Fällen konnte ich die Anlagen in aller Ruhe zuhause testen und einrichten. Aber nun hatte ich zum ersten Mal einen Telekom-Account einzurichten - und das geht scheinbar nur von dem Anschluß des Kunden aus. Bei mir in der Werkstatt (von meinem Anschluß aus) hat die Telekom die Registrierung abgelehnt, und (konsequenterweise .... - ) wurde am Telekom-Anschluß auch die Registrierung meines Providers abgeschmettert!

Tja - das war eine Arztpraxis, und da kann man leider keine ausgiebigen Analysen durchführen - eigentlich schade.

Und, wo wir gerade dabei sind: Am Telekom-Anschluß wird ein ankommender Anruf immer mit "+49XXXXXX" angezeigt. Die vorher installierte uralte Agfeo-ISDN-Anlage hat die Nummer korrekt angezeigt.

Ich habe viele Hilferufe wegen dieser +49-Anzeige im Netz gefunden, aber bisher keine wirkliche (Asterisk-bezogene) Lösung. Hast Du eine Idee?

Danke - und bleib gesund ....

 

[sonyKatze]

Wegen dem +49 würde ich einen neuen Thread aufmachen. Nicht jeder weiß alles und die Überschrift des Threads zieht solche, die es vielleicht wissen, nicht an.

Deswegen verkaufen viele Profis nur Standard-Lösungen – weil die irgendwer mal durchgetestet hat. Allerdings verstehe ich die Problematik mit dem Paket-Mitschnitt nicht. Du hast eine Konstellation, die Du schnell nachstellen kannst. Die Logs kannst Du dann mit nach Hause nehmen. Wenn der Kunde zu weit weg ist, also die Anfahrt zu problematisch ist, solltest Du Dir einen Wartungs-/Fernzugang legen. SIP ist im Detail so kompliziert, dass Du mit Herumprobieren und Basteln länger brauchst, als mit ordentlichem Analysieren. Bei SIP wirst Du immer dazulernen, weil Software-Implementationen aufeinander treffen – und jede hat ihre eigene Interpretation von den Standards.

 

[gehtdoch]

Hallo @gehtdoch,
Ich war schon etwas erstaunt - das "FreePBX"-GUI halte ich absolut nicht für Endkunden-geeignet. Auch dort muß man eine ganze Menge Hintergrundwissen über die Zusammenhänge haben, und die verwendete Terminologie in der GUI ist auch nicht immer selbsterklärend.

Da kann ich Dir nicht widersprechen. Ich hatte am Anfang auch zu kämpfen, aber wenn man die grundsätzliche Strategie des Routings mal verstanden hat, geht es eigentlich sehr zügig (ich rede von der aktuellen Version).

Der Chef in einem mittelständischen Unternehmen hat alle Hände voll zu tun, seinen Laden am Laufen zu halten.

=> Einrichten kann er das definitiv nicht selbst. Aber auf Basis einer Anleitung ein neues Telefon einbinden sollte eigentlich nicht so schwierig sein. FollowMe und einige andere Features finde ich auch nicht wirklich schwierig mit Anleitung.

Und wenn man die vielen, vielen "FreePBX"-betreffenden Hilferufe in den Foren so liest - so ganz ohne ist das auch nicht.

Wenn es ins Detail geht, wird es schon haarig, wenn man keine Ahnung (von VoIP) hat. Deshalb ja auch die grundsätzliche technische Einrichtung durch den Spezialisten und kleinere Anpassungen dann durch den Kunden selbst auf Basis von Anleitung.

Ich habe dann nach diesen ersten Erfahrungen "FreePBX" wieder de- und das pure Asterisk installiert - auch natürlich, um zu lernen, wie das geht und was da so abläuft. Und mit dem puren Asterisk hatte ich deutlich schneller kleine Testerfolge als mit "FreePBX".

FreePBX ist extrem mächtig und erschlägt Dich allein auf Grund der vielen Features und erst recht, wenn Du am Anfang keinen Plan von deren Vorstellung hast, wie CallRouting ticken soll. Dafür gibt es aber Youtube-Videos, die gar nicht mal so schlecht sind.