Freizeichenton tauschen

  • Ich hatte vor einiger Zeit schon mal in einem anderen Thread was ähnliches gefragt und will noch mal anknüpfen. Sieht einer von euch eine Möglichkeit das Freizeichen am DoorPi gegen einen anderen Sound zu tauschen?


    Ich frage aus zwei Gründen. Einerseits ist der Sound über den Lautsprecher recht laut, da meine Gegenstellen (Fritz!Fon) sehr leise sind. Das hat aber ein sehr lautes Freizeichen zur Folge. Hört man noch 2 Häuser weiter...Ich könne den Ton also runterpegeln und damit relativ leise machen oder einmal tuten lassen und dann eine Stille einfügen.


    Außerdem finde ich es verwirrend aus Sicht eines Besuchers, dass ein Freizechen kommt, wenn man irgendwo klingelt. Ich als unwissender Besucher hätte in dem Fall ein "Ding Dong" oder ähnliches erwartet.


    Das Setting in der DoorPi hat keinen Einfluss. Ich hatte angenommen, dass Linphone den ringback Sound aus dem folgenden Verzeichnis nimmt.
    /usr/local/lib/python2.7/dist-packages/linphone/share/sounds/linphone 


    Macht es aber nicht, denn den habe ich unter gleichen Namen gegen einen anderen Sound ausgetauscht. Ist aber unverändert geblieben. Also kommt es vermutlich aus der Fritzbox und dort ist der Freizeichenton vermutlich in der Firmware verankert, da er ja standardisiert ist.


    Ich frage mich also, ob man Linphone nicht doch dazu bewegen kann ein anderes Freizeichen, also einen Gong oder "bitte warten" ausgeben zu lassen? Weiß das jemand?

  • Hallo Marcus,


    das Problem ist in Arbeit, siehe Einspielen einer .wav Datei im Rufzustand.


    Eine Vorabhilfe gibt es auch, siehe #1.288
    im alten Forum.


    Ein Hinweis zur dort beschriebenen Vorabhilfe:
    In der Zeile



    40 = os_execute:aplay !BASEPATH!/media/doorbell-25dB.wav -D sysdefault:CARD=0


    muss der Wert für "CARD" zu Deiner Umgebung passen. Der Wert kann mit "alsamixer" ermittelt werden. Dort bekommst Du mit "F6" die bekannten Soundkarten aufgelistet, mit einer Nummer davor. Einfach die Nummer, die vor Deiner Soundkarte steht, bei "CARD" verwenden.


    Gruß
    Ewald

  • @RaspiEHU
    Hallo Ewald,


    ich bin jetzt endlich mal dazu gekommen mich durch die Threads zu lesen. Ich denke du hast dich schon etwas länger und genauer mit dem Thema beschäftigt :)


    Wenn ich das richtig verstehe, dann besteht der Workaround darin, eine Datei im Klingel-Event abzuspielen und den Verstärker dafür gezielt ein und auszuschalten. Das unterdrückt dann die Ausgabe des Freizeichens "hardwaretechnisch".


    Da innerhalb eines Eventhandlers immer sequentiell gearbeitet wird, müsste man alle anderen Aktionen (Mail, Snapshot, interner Gruppenruf usw. vorher abarbeiten. Ist es dann nicht so, dass z. B. ein "call:**621" alles Nachfolgende erst mal nicht verarbeitet sondern auf die Vermittlung bzw. den Timeout des Calls wartet? D.h. dann würde es gar nicht weiter gehen. Vermutlich der Grund, warum deine Calkl Action am Ende steht. Daher darf die wav Datei nur kurz sein. Sonst verzögert sich der Anruf. Teste ich mal.


    @motom001
    Sieht du denn eine Chance, das trotz der vielen anderen Themen in einem kommenden Release beheben zu können? Oder ist das bei dir erst mal in der Prio Liste nach unten gerutscht?


    Grüße und danke euch
    Marcus

    • Offizieller Beitrag

    Oder ist das bei dir erst mal in der Prio Liste nach unten gerutscht?

    Ja und Nein...
    Ursprünglich wollte ich erst einmal DoorPi 3 fertig stellen und nichts mehr an DoorPi 2 machen. Allerdings sind die Rückmeldung ja eher so, dass wenn ich das durchziehe zu DoorPi 3 keiner mehr da ist, da Grundfunktionalitäten nicht sauber lauffähig sind. Nun baue ich gerade mein Zeitplan um und versuche mich auf DoorPi 2 zu konzentrieren auch wenn ich dann fast alles zweimal programmieren muss.


    Das Problem allerdings werde nicht allein lösen können. Dazu werde ich ein Test-Script schreiben und das ganze an den Hersteller von linphone übergeben.


    Oder kann von Euch jemand diesen Teil übernehmen und mit dem Hersteller das Problem 180 / 181 erörtern und zur Lösung führen? Das würde mir viel helfen...

  • @motom001. Könnte ich übernehmen. Allerdings müsste ich mich noch mal etwas in die Thematik einarbeiten um das Problem genauer zu verstehen. Idealerweise vielleicht zusammen mit @RaspiEHU? Du hast doch schon viel recherchiert und getraced.

  • motom001_new: Ich halte das derzeit für weniger wichtig. Wer verschiedene Aktionen innerhalb eines Events gleichzeitig haben möchte, kann dies problemlos mit einem Shellscript realisieren, das parallele Prozesse anstößt.


    Es funktioniert beispielsweise ganz hervorragend, damit auf dem lokalen Raspberry Pi Audiodateien abzuspielen, ohne auf deren Ende zu warten.


    LG


    pah

  • Configure before code... Wichtige Regel in der IT.


    Viele der DoorPi Nutzer widmen Ihr Leben nicht der Linux Welt und freuen sich über eine tolle Software, die konfigurativ anzupassen ist. Das Ziel sollte also sein, diese Möglichkeiten weiterzuentwickeln und zu optimieren. Nicht jeder ist in der Lage sich ein Shellscript zu schreiben bzw. möchte den Aufwand nicht investieren und sich das Wissen dazu zu erarbeiten. Den Einwand konnte man ja schon mehrfach hier lesen und das sollte man respektieren. Man darf nicht immer von sich auf andere schließen.

  • DoorPi enthält derzeit noch so viele Probleme bei Grundfunktionalitäten, dass irgendwelche "Nice-to-have" Funktionalitäten eher unwichtig sind - vor allem dann, wenn es derzeit auch schon ohne sie funktioniert. Und das Argument, dass man selber die Zeit nicht investieren mag und andere doch bitte etwas entwickeln sollen, ist dem Gesamtprojekt auch nicht förderlich.


    LG


    pah

  • Hallo zusammen,


    ich stehe gerade irgendwie auf dem Schlauch.
    Wenn ich in die doorpi.ini die Zeile


    Code
    dialtone = /usr/local/lib/python2.7/dist-packages/linphone/share/sounds/linphone/rings/bigben.wav

    hinzufüge, höre ich aus dem Lautsprecher den BigBen. Wenn ich diese Zeile entferne einen Standard-Wählton.


    Oder habe ich das Problem nicht richtig verstanden?


    Gruß,
    DerStandart

  • Und das Argument, dass man selber die Zeit nicht investieren mag und andere doch bitte etwas entwickeln sollen, ist dem Gesamtprojekt auch nicht förderlich.

    Ach, das ist doch Quatsch. Etwas weiter oben habe ich ja meine Hilfe angeboten.


    Wie geschrieben geht es mir dabei ja auch nicht nur um mich, sondern alle Anwender die nicht so fit auf dem Raspi sind. Ich habe mir bekannterweise selber schon Skripte geschrieben wo ich sie brauchte. Stichwort Loxone (wofür ich mir ja auch schon zynische Kommentare anhören durfte). Und ob eine FHEM Integration oder ein Farbdisplay mehr Prio haben liegt ja im Auge des Betrachters.


    Aber gut ist's. Keine Lust mehr auf diese wenig konstruktive Diskussion.


    Mein Angebot zur Hilfe steht jedenfalls nach wie vor.

  • Ich versuche mal, etwas Klarheit in die Diskusion zu bringen.


    Das Problem tritt nicht auf, wenn DoorPi an einer Asterisk betrieben wird. Nea kann das bestätigen, er hat einen entsprechenden Test gemacht. Es ist nicht ausgeschlossen, dass auch der Betrieb auch an anderen TK System problemlos funktioniert.
    Das Problem tritt auf, wenn DoorPi an einer Fritzbox, in meinem Fall einer 7490, betrieben wird. Dann wird die in der doorpi.ini angegebene .wav nicht während der Rufphase abgespielt, sondern der Rufton der Fritzbox ist zu hören.



    Den Grund hierfür habe ich unter den von mir angegebenen Links, weiter oben, ausführlich beschrieben. Trotzdem noch einmal in Kürze:
    Wird durch die Betätigung eines Klingeltasters ein Ruf durch DoorPi zu einer Nebenstelle ausgelöst, gibt Asterisk als SIP Ringing Cause den Wert 180 zurück.
    Beim gleichen Vorgang an einer Fritzbox wird der Ringing Cause 183 zurückgegeben. Thomas (motom001) hat das bestätigt.


    Zitat von motom001

    Damit ist die Vermutung von @RaspiEHU bestätigt, dass es an dem Signal 180 bzw. 183 liegt. Den Fehler konnte ich auf liblinphone eingrenzen und jegliche Konfiguration hat zum gleichen Ergebnis geführt.
    Aktuell erarbeite ich eine Demo-Python-Datei, die ohne DoorPi läuft und dem Hersteller das Problem verdeutlicht, damit man es als Bug melden kann.


    Da das Problem Linphone ist, ist jede DoorPi Version betroffen, die Linphone als SIP Client verwendet.


    Markus,
    Vielleicht reichen diese Hinweise schon für Dich, um die Thematik bearbeiten zu können. Weitere Traces und Hinweise kann wahrscheinlich Thomas einbringen, er hat entsprechende Versuche, vielleicht sogar schon die oben erwähnte Demo-Python-Datei erstellt, um das Problem an den Hersteller als Bug melden zu können.
    Edit:
    Habe mit dem Absenden gesehen, dass Thomas schon reagiert hat.


    @pahennig
    Es ist tatsächlich so, das dieses Feature schon mit der ersten DoorPi Versionen als Leistungsmerkmal beschrieben wurde. Ich selbst habe mit DoorPi angefangen, als der Linphone Client eingeführt wurde. Das LM hat für mich nie funktioniert. Andere haben das auch festgestellt.
    Im Zuge der Echo Problematik wird zur Zeit intensiv am Linphone Client gearbeitet. Auch wenn die Echo Problematik am Ende u.U. kein Linphone Problem ist, so wäre es meines Erachtens doch sinnvoll, auch das .wav Problem zu bereinigen, da auch Thomas (motom001) schon eine erhebliche Vorleistung zur Bereinigung erbracht hat und man die Linphone Umgebung zur Zeit voll im Blick hat.


    Viele Grüße
    Ewald

  • Ich versuche mal, etwas Klarheit in die Diskusion zu bringen.


    Das Problem tritt nicht auf, wenn DoorPi an einer Asterisk betrieben wird. Nea kann das bestätigen, er hat einen entsprechenden Test gemacht. Es ist nicht ausgeschlossen, dass auch der Betrieb auch an anderen TK System problemlos funktioniert.
    Das Problem tritt auf, wenn DoorPi an einer Fritzbox, in meinem Fall einer 7490, betrieben wird. Dann wird die in der doorpi.ini angegebene .wav nicht während der Rufphase abgespielt, sondern der Rufton der Fritzbox ist zu hören.

    Die Ursache könnte darin liegen, dass die FB vielleicht keine Early Media unterstützt. Das kann ich mir mal ansehen.


    Um Bandbreite zu sparen wird erst möglichst spät RTP übertragen. Das ist der Standard. Während der TRYING/RINGING Phase wird der Ringtone vom Client eingespielt und NICHT übertragen. Die RTP wird erst nach dem OK/ACK etabliert. Daher kann z.B. der Big Ben auch nicht zu hören sein.


    Die Option EARLY MEDIA ermöglicht das Übertragen von RTP schon während vor dem OK/ACK. Wenn man ins Asterisk Early Media deaktivieren würde, hätte man vermutlich den gleichen Effekt wie in der FB.

    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    Einmal editiert, zuletzt von AndyGR42 () aus folgendem Grund: SIP ist nicht gleich SIP: Korrekturen bei den SIP Messages

  • Hallo Thomas.


    Um den Rufton hören zu können, müsste man Early Media aktivieren. Richtig... deaktivieren :)


    Das versuche ich gerade zu tracen, aber dazu muss ich noch ein bisschen was umbauen um den Swicth Port vom Pi zu spiegeln.


    Mir ist bei der SIP Implementierung aber etwas anderes aufgefallen. DoorPi sendet REGISTER zu oft (26x), zu schnell (Abstand 3ms) und wartet offensichtlich nicht auf die Antwort des SIP Service. Ich nehme doch an, dass DoorPi das Register auslöst, oder? Wenn ich linphonec allein starte passiert das nicht. Grundsätzlich ist das jetzt nicht so arg tragisch, empfindliche Server oder Firewalls könnten das aber als Angriff werten.


    Register läuft normalerweise so ab:


    • Client sendet REGISTER (ohne Anmeldeinformationen)
    • Server antwortet mit UNAUTHORIZED
    • Client Antwortet mit OK (nicht immer)
    • Client sendet REGISTER (mit Anmeldeinformationen)
    • Server Antwortet mit OK


    Das kann durchaus ein par mal hin- und her gehen, bis realm, nonce und response zusammen passen. DoorPi sendet aber erst mal massenhaft REGISTER ohne Anmeldeinformationen und stößt den Prozess damit vielfach parallel an. Zumindest bei mir. Da man in linphone dazu nix konfigurieren kann, muss die Aktion ja aus DoorPi ausgelöst werden.


    Problem erledigt. Hing mit der Netzwerk Config wegen dem Trace zusammen. DoorPi macht an der Stelle alles wie erwartet :)



    Ich habe den Output mal damit aufgezeichnet: sudo doorpi_cli --trace |& tee /home/pi/log_DoorPi.txt

    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    3 Mal editiert, zuletzt von AndyGR42 ()

  • So, das "Problem" liegt bei der FB. Diese sendet kein RINGING (180). Laut RFC3960 darf der Client keine lokalen Ringback Töne einspielen, bevor er nicht eine 180 empfangen hat. Asterisk macht das vermutlich. Zudem darf der Client zu diesem Zeitpunkt keine RTP Pakete empfangen. Nur dann benutzt er den lokalen Ringback Ton. Und auch nur so lange, bis er RTP empfängt.



    Das Early Media verhalten müsste in der PBX (FritzBox) deaktiviert werden. Außerdem müsste die FB RINGING senden an Stelle von bzw. im Anschluss an TRYING.


    Linphon verhält sich hier völlig RFC konform. Es scheint auch keinen Switch zu geben um das Verhalten zu deaktivieren.


    BTW, Early Media zu deaktivieren kann auch zur Folge haben, dass die ersten Sekunden nach dem OK/ACK verloren gehen, da es etwas dauern kann den RTP Strom aufzubauen. Im LAN sollte das normalerweise kein Problem sein. Muss man eine FW überwinden schon. Daher ist Early Media eigentlich Standard. Dazu gibt es keine Option im SIP. Der Server schickt einfach Pakete (Ringback, wie es auch ein herkömmlicher Telefonanschluss machen würde) und überlässt dem Client die Aktion. In der Regel wird der Client seinerseits mit dem Senden von RTP beginnen.