Modul 96_SIP

[Jamo]

Hallo Kurt,
Kannst Du mal probieren, die Code Tags zu nehmen, wenn Du deine Logs postest? Das ist der ,,#" button in der unteren Reihe über dem Eingabefenster, damit muss man nicht endlios scrollen wenn man die Antwort lesen will.

[plin]

Hallo Kurt,

jetzt habe ich all Deine Ratschläge befolgt, aber ich kann machen, was ich will: Dtmf-Codes werden nicht erkannt. Hier ein List ohne vorhergehendes reset.

Auch diesen Vorschlag?

Kannst du den Test mal mit einem anderen Telefon machen um zu sehen ob die Event Zeiten dann größer sind ?

Zum Vergleich kann man gut die FritzFON-App hernehmen. Dann kriegen wir raus, ob es an Deiner FHEM-Insrtanz oder am Client-Telefon liegt.

VG plin

[Kurt77]

Hallo plin,
ich hatte beim letzten log mit einem Telefon"Wohnzimmer" statt mit "Buero" telefoniert.
Jetzt habe ich's nochmal, Deinem Rat folgend, mit der fritzappfon (auf einem IPhone) getestet. Auch mit der App wird kein dtmf-Code erkannt.

@Jamo:
Ich versuche es mal, aber ich glaube es wird schiefgehen.

Code Auswählen Erweitern

define irgendwas irgendwas

Sieht das für Dich gut aus?

Danke und Gruß,
Kurt

[Jamo]

Du musst deinen code zwischen dem  [ code ] und (also HIER) dem  [ \code ] reinkopieren, dann siehts so aus:

Code Auswählen Erweitern

Du musst deinen code zwischen dem und (also HIER) dem reinkopieren, dann siehts so aus:

[Kurt77]

Hallo Jamo,
versuchen wir es nochmal.

Code Auswählen Erweitern


define irgendwas irgendwas


Passt das jetzt so?

Danke und Gruß,
Kurt

[Jamo]

Ja, sieht gut aus. Danke!

[Wzut]

@plin : schau dir mal den Teil von Kurt an :

Code Auswählen Erweitern


2020.08.24 20:38:36 5: MySipClient[655], cb_est_dtmf
2020.08.24 20:38:36 5: MySipClient, readingS:caller_state Val:established
2020.08.24 20:38:46 5: MySipClient, listen process 655 found
eigentlich müsste direkt nach dem cb_est_dtmf ein while dtmf_loop : start reinvite1 kommen
Da dieses fehlt sieht das für mich aus als ob das Programm noch in der darüberliegenden $ua->loop(\$call) festhängt und dann nicht in die while($dtmf_loop) Schleife geht.
Das würde auch erklären warum er dann die Ansage von $msg1 durch   $call->reinvite nicht bekommt.

Da es nach einem Reset geht, muß das doch bedeuten das nach Ende des ersten Calls irgendeine Variable nicht zurück gesetzt wird innerhalb der großen while(1) Schleife. Ich vermute jetzt fast es hat was mit der Perl Version unter Buster auf sich und vllt. sollte man nochmal an das ToDo im Kommentar gehen :  "Was kann davon noch nach while(1) ?"
denn vermutlich ist es jetzt kein "kann" mehr sondern ein "muß" ?

Mir graut etwas davor mein Testsystem komplett auf Buster umzustellen, da ich aktuell noch mit den MAX Modulen einige Baustellen habe, aber über kurz oder lang wird da wohl kein Weg daran vorbeiführen.

[OT on]
@Jamo, lass ihn. Wenn du mit seiner Hardware klar kommen müsstest würden deine Post garantiert noch schlimmer aussehen ....
Ich habe den Fehler einmal gemacht bzw. den Fettnapf gefunden und bei Elektrolurch wegen seiner falsch gesetzten Code Tags mal als Antwort geschrieben "na na, das übern wir aber noch ein bissel"
[OT off]

[plin]

Hi,

ein paar Tests von meiner Seite.

Ich habe eine SD-Karte mit einem Debian Buster auf armbian erzeugt die in meinem BananaPi halbswegs funktioniert.

• sip_audiofile_dtmf = !Ihre Eingabe bitte
• sip_audiofile_ok    = !Danke
• Test mit einem FritzFON C5

1. Anruf: gekrächzte Ansage, #, 6, 6, 6, 6, (alle Tasten werden lt. og erkannt), 7, dtmf_event=67, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1,  2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2,  3, dtmf_event=23, Danke, SIP-Client legt auf

Wiederholung mit dem alten Raspbian Stretch

1. Anruf: gekrächzte Ansage, #, 6, 6, 6, 6, (alle Tasten werden lt. og erkannt), 7, dtmf_event=67, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1,  2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2,  3, dtmf_event=23, Danke, SIP-Client legt auf

reset des listen_dtmf

1. Anruf: gekrächzte Ansage, #, 3, 4, dtmf_event=34, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1,  2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2,  3, dtmf_event=23, Danke, SIP-Client legt auf

Mittels T2S ein Audiofile IhreEingabeBitte.mp3 erzeugt und umbenannt

• sip_audiofile_dtmf = IhreEingabeBitte.mp3
• sip_audiofile_ok    = !Danke

1. Anruf: Ihre Eingabe bitte, #, 3, 4, dtmf_event=34, Danke, SIP-Client legt auf
2. Anruf: Ihre Eingabe bitte, #, 1,  2, dtmf_event=12, Danke, SIP-Client legt auf

Fazit

• Debian Strech und Buster machen keinen Unterschied
• Bei Textvorgabe und Nutzung von T2S klappt's nur einem nach einem reset
• Bei file für die Anage und Nutzung von T2S für's OK klappt's jedes Mal

VG plin

[Wzut]

• Debian Strech und Buster machen keinen Unterschied
• Bei Textvorgabe und Nutzung von T2S klappt's nur einem nach einem reset
• Bei file für die Anage und Nutzung von T2S für's OK klappt's jedes Mal

OK, THX , damit wäre das Thema Buster vs. Stretch erste inmal vom Tisch.
Die anderen beiden Punkte hatte ich ja auch schon beschrieben, da werde ich auf jeden Fall nachbessern.
BTW: man muss die Datei von T2S nicht unbedingt umbennen, ich habe sie bei mir einfach direkt eingetragen :

Code Auswählen Erweitern

attr sip sip_audiofile_dtmf cache/d15c45ea5f2d96592ed16b06899fcf5b.mp3
attr sip sip_audiofile_ok cache/f9757ae70d3bb25d746ee1fa4f8d08a9.mp3

[plin]

BTW: man muss die Datei von T2S nicht unbedingt umbennen, ich habe sie bei mir einfach direkt eingetragen :

mmmh, was sagt Dir "d15c45ea5f2d96592ed16b06899fcf5b"? Ich finde da "IhreEingabeBitte" deutlich transparenter (sozusagen WYSIWYG)  .

[Kurt77]

Hallo,
danke für die Mühen, aber mir hilft das leider nicht.
Immer das gleiche Fehlerbild auch wenn ich Dateien einbinde.

Gruß Kurt

[Wzut]

Das ist mir schon klar, aber du hast ein Fehlerbild das wir z.Z. nicht nachstellen können.
Könnten wir es würden wir garantiert auch eine Lösung aus dem Hut zaubern.
Ich bin z.Z. dabei intern im Modul etwas aufzuräumen ( Stichwort PBP ) daher kann ich dir im Moment nur anbieten die nächsten Tage eine Betaversion hier reinzustellen mit noch mehr Log Ausgaben.

Achso : eine Idee um dein Problem quick und dirty zu umgehen hätte ich noch, dazu musst du aber verraten was du mit den erkannten DTMF Reading machen willst.

[plin]

@Kurt: Welche Net::SIP-Version nutzt Du? Ich bin bei  our $VERSION = '0.808';

[Wzut]

@plin, ich dachte Buster liefert 0.820 aus ? Auf CPAN ist er inzwischen bei 0.823

[plin]

@plin, ich dachte Buster liefert 0.820 aus ? Auf CPAN ist er inzwischen bei 0.823

Das ist die in meinem FHEM-Dev aktive Version mit der ich die oben genannten Tests unter Stretch durchgeführt habe. Buster muss ich erst mal wieder reinstecken/hochfahren.