Modul 96_SIP

[JoWiemann]

Hallo,

habe jetzt Net::SIP mit cpan neu installiert und bekomme auf 2 RPi mit aktuellem wheezy folgende Fehlermeldung:

[Thu Mar 16 21:06:45 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.

Der Aufruf erfolgt mit: set FritzSip call **611 30 cache/DideT.alaw

Wenn ich den Ruf annehme erhalte ich nur eine Abfolge von Tönen, als wenn noch gewählt würde.

Grüße Jörg

PS: Hier noch das List

Code Auswählen Erweitern


Internals:
   AC         /usr/bin/sox
   CFGFN
   NAME       FritzSip
   NOTIFYDEV  myT2S
   NR         125
   NTFY_ORDER 50-FritzSip
   STATE      initialized
   TYPE       SIP
   VERSION    V1.42 / 15.03.17
   Readings:
     2017-03-16 21:06:50   call            done
     2017-03-16 21:06:50   call_state      unknown peer hangup
address
     2017-03-16 21:06:50   state           initialized
   Helper:
Attributes:
   T2S_Device myT2S
   T2S_Timeout 30
   audio_converter sox
   room       Telefon
   sip_dtmf_loop once
   sip_dtmf_send audio
   sip_dtmf_size 2
   sip_from   sip:626@fritz.box
   sip_ip     xxx.xxx.x.xx
   sip_listen none
   sip_port   5090
   sip_registrar fritz.box
   sip_ringtime 10
   sip_user   626
   verbose    5


[Wzut]

Die Abfolge von Tönen die du hörst ist ein Fallback damit man überhaupt etwas hört, da ist schon ok.
Nicht ok ist allerdings warum das Modul dir die Datei nicht vorspielt. Du hast verbose auf 5 stehen, d.h. in deinem Log File sollte eigentlich jeder einzelne Schritt nachvollziehbar sein. Poste doch bitte mal das Stück vom Beginn des Calls bis zum Ende.
Welche Version des Sip::Net Paketes hast du installiert ?
In meiner Version ist in Zeile 115 des  Eventloop.pm kein größer/kleiner Vergleich, aber in der Ecke wird bei mir gewartet ob die Maximal Zeit abgelaufen ist.
Danach musste die Eventloop Zeile bei dir auch auftauchen wenn du ganz ohne Parameter einen Call absetzt :
set FritzSip call **611   
wichtig ist allerdings das du nach wie vor das attr Sip_audiofile_call nicht setzt.

Edit : was mich noch intressiert ist wo kommt der Teil "30M-BM- " her ?

Edit 2 : Ich denke ich habe deinen Fehler :

Code Auswählen Erweitern

2017.03.17 08:07:12 1: PERL WARNING: Argument "test.alaw" isn't numeric in numeric lt (<) at /usr/lib/perl5/Net/SIP/Dispatcher/Eventloop.pm line 79.
passiert wenn die Max Zeit weggelassen wird und an deren Stelle das Audiofile steht

[DerTom]

Na ja, was soll es hier auch an Kritik geben, wo das so gut funktioniert?

Nun ja...

[JoWiemann]

Welche Version des Sip::Net Paketes hast du installiert ?
In meiner Version ist in Zeile 115 des  Eventloop.pm kein größer/kleiner Vergleich, aber in der Ecke wird bei mir gewartet ob die Maximal Zeit abgelaufen ist.
Danach musste die Eventloop Zeile bei dir auch auftauchen wenn du ganz ohne Parameter einen Call absetzt :
set FritzSip call **611   
wichtig ist allerdings das du nach wie vor das attr Sip_audiofile_call nicht setzt.

Edit : was mich noch intressiert ist wo kommt der Teil "30M-BM- " her ?

Edit 2 : Ich denke ich habe deinen Fehler :

Code Auswählen Erweitern

2017.03.17 08:07:12 1: PERL WARNING: Argument "test.alaw" isn't numeric in numeric lt (<) at /usr/lib/perl5/Net/SIP/Dispatcher/Eventloop.pm line 79.
passiert wenn die Max Zeit weggelassen wird und an deren Stelle das Audiofile steht

Log mit verbose 5

Code Auswählen Erweitern


2017.03.17 09:25:17 4: FritzSip, CALLDone -> FritzSip|1|unknown peer hangup
2017.03.17 09:25:17 5: FritzSip, Hangup : HASH(0x2dac0a0)
2017.03.17 09:25:17 5: FritzSip, RTP done : 0
[Fri Mar 17 09:25:12 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.
2017.03.17 09:25:12 4: FritzSip, calling : **610

exit
2017.03.17 09:25:12 5: FritzSip, telnet : set FritzSip call_state calling **610
2017.03.17 09:25:12 4: FritzSip, CallStart DTMF : ABCD*#123--4567890

exit
2017.03.17 09:25:12 5: FritzSip, telnet : set FritzSip state calling
2017.03.17 09:25:12 4: FritzSip, register new expire : Fri Mar 17 09:30:12 2017
2017.03.17 09:25:09 5: FritzSip, call has pid 18570
2017.03.17 09:25:09 4: FritzSip, calling **610, ringtime: 30 cache/DideT.alaw , no message
2017.03.17 09:23:32 4: FritzSip, CALLDone -> FritzSip|1|unknown peer hangup
2017.03.17 09:23:32 5: FritzSip, Hangup : HASH(0x2d967b0)
2017.03.17 09:23:32 5: FritzSip, RTP done : 0
[Fri Mar 17 09:23:26 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.
2017.03.17 09:23:26 4: FritzSip, calling : **610

exit
2017.03.17 09:23:26 5: FritzSip, telnet : set FritzSip call_state calling **610
2017.03.17 09:23:26 4: FritzSip, CallStart DTMF : ABCD*#123--4567890

exit
2017.03.17 09:23:26 5: FritzSip, telnet : set FritzSip state calling
2017.03.17 09:23:26 4: FritzSip, register new expire : Fri Mar 17 09:28:26 2017
2017.03.17 09:23:23 5: FritzSip, call has pid 18501
2017.03.17 09:23:23 4: FritzSip, calling **610, ringtime: 30 cache/DideT.alaw , no message


Installiert ist: Net-SIP-0.807

ich habe mal folgendes Log in die sub SIP_Set($@) eingebaut:
if  ($cmd eq "call")
  {
    Log3 $name, 4, $name.", params from set: a[2] = $a[2], a[3] = $a[3], a[4] = $a[4]";

und bekomme:
2017.03.17 09:56:54 4: FritzSip, params from set: a[2] = **610, a[3] = 30 cache/DideT.alaw, a[4] =

Und was ist die Lösung: Ein Leerzeichen im: set FritzSip call **610 30 cache/DideT.alaw war kein Leerzeichen sondern ein hex a0  zwischen 30 und cache/DideT.alaw.

Und bitte nicht frage wie das dahin gekommen ist 

Grüße Jörg

Und da soll man drauf kommen....

[Wzut]

Und da soll man drauf kommen....

find ich aber gut das dir das passiert ist, das hat gezeigt das in der nächsten Version unbedingt eine Überprüfung auf nummerisch mit rein muß, ala :

Code Auswählen Erweitern

return "invalid max time : $ringtime" unless $ringtime =~ m/^\d+$/;

[JoWiemann]

Hallo,

ich habe noch einen Fehler in Text2Speech gefunden. Auf einem meiner RPi läuft Fhem aus historischen Gründen unter /usr/share/fhem. Ich hatte zunächst vergessen TTS_CacheFileDir zu setzen. Als folge läuft Text2Speech auf einen Fehler in der sub Text2Speech_DoIt($) bei:

Code Auswählen Erweitern


  unless(-e $TTS_CacheFileDir or mkdir $TTS_CacheFileDir) {
    #Verzeichnis anlegen gescheitert
    Log3 $hash->{NAME}, 2, "Text2Speech: Angegebenes Verzeichnis $TTS_CacheFileDir konnte erstmalig nicht angelegt werden.";
    return undef;
  }


Dadurch wird $hash->{helper}{RUNNING_PID} nicht gelöscht und Text2Speech funktioniert erst wieder, wenn Fhem neu gestartet wird.

Grüße Jörg

[Wzut]

@Jörg, poste das bitte unter https://forum.fhem.de/index.php/topic,18481.0.html
da es ein reines T2S Problem ist und ich nicht sicher bin ob Tobias hier überhaupt mitliest.

[JoWiemann]

Danke für den Hinweis und erledigt.

Grüße Jörg

[Wzut]

Nun ja...

Ist mir schon klar das du unzufrieden bist weil bei dir die DTMF Erkennung nicht so läuft wie gewünscht.
Da du auch geschrieben hast das bei dir 5 FHEM Prozesse laufen und du dir im Unklaren bist warum, versuche doch bitte mal  folgendes und in dieser Reihenfolge :
1. ändere das Attribut sip_listen auf none und speichere mit fhem save.
2. starte dein System komplett neu ( also nicht nur fhem)
3. Wieviele Prozesse laufen nun ?
4a. ändere das Attribut verbose auf 5 , falls es kleiner ist
4b. ändere das Attribut sip_listen von none auf dtmf
5. wenn du eine aktuelle Version des SIP Moduls hast sollte nun sofort der Listen Prozess starten
( Internals checken nach LPID , logfile ) wenn nein mit set <name> listen von Hand starten.
6. läuft nun ein Prozess mehr als unter Punkt 3. ?
7. jetzt wechsele auf deine Fritzbox und lege dort einen weiteren SIP User komplett an
8. richte ein weiteres SIP Device unter fhem ein ( define testSIP SIP )
    passe die Attribute des neuen Device an (sip_listen auf none oder leer und sip_dtmf_send auf audio) und setze das Passwort.
9. du solltest jetzt in der Lage sein mit diesem testSIP den ersten Client anzurufen :
   set testSIP call Nummer-des-listen-Device
10. wenn der Anruf beendet ist ändere das Attribut sip_dtmf_send von audio auf rfc2833
11. rufe wieder die Nr1. an via   set testSIP call Nummer-des-listen-Device
12. poste den kompletten Log Abschnit von Schritt 9 bis 11
   

[plin]

@DerTom und @Wzut:

Ich darf noch mal an die Hardware erinnern: "Cubietruck unter Debian jessie (8.7)".

Bei mir läuft listen_for_dtmf weder auf dem BananaPi noch auf dem Raspi2. Der Cubietruck ist leistungsfähiger, hat aber auch einen ARM-Prozessor. Meine FHEM-Instanz für IP-basierte Aktivitäten läuft auf einem Intel-Server. listen_for_dtmf erzeugt dort ca. 10% CPU-Auslastung eines Cores, während auf meinem Raspi2 ein Core binnen 1-2 Sekunden auf 100% hochgeht und dann bis zum Auflegen da hängen bleibt.

Ich stelle mir die Frage, ob die DTMF-Erkennung der Net::SIP ein Problem mit der Prozessorarchitektur ARM hat.

Hat jemand einen Raspi3 auf man mal testen könnte?

[Wzut]

ja ja , ich wollte das ja auch mal testen.
Normal läuft bei mir FHEM als auch die ganzen Tests auf einem Intel Board. Wenn der Prozess in die DTMF Erkennung geht steigt die Last,
zwar nicht auf 100% aber doch deutlich. Jetzt habe ich mal einen sehr alten RasPi aus der Bastelkiste geholt , Single Core mit 512 MB
OS : Jessie via NAS. Da das gesammte Filesystem auf dem NAS liegt ist er zwar kein Rennpferd aber meine DoorPi Testinstallation inkluse FHEM läuft eigentlich recht ordenlich.
Test :
- Doorpi Prozess gestoppt (linphone)
- dem FHEM Prozess sein SIP Device spendiert und listen_for_dtmf angeworfen und siehe da ...
Ich höre nicht mal das Zirpgeräusch wenn  der Client abnimmt
Es wird keine einzige Taste erkannt !
Lege ich am Telefon auf erfolgt auch keinerlei Log Eintrag zum Thema bye
Fazit : So ist  ist das Ding für listen_for_dtmf auf keinen Fall zu gebrauchen.
Wenn ich die nächste Woche etwas Zeit finde werde ich auf dem Ding wieder anfangen mit den mini Scripten zu testen, mal schaun ob ich da schlauer werde.

Ich checke jetzt noch eine neue Version des Moduls ein, habe ein paar Kleinigkeiten beim Logging angepasst und ein neues Attribut sip_filter.
sip_filter ist eine Komma getrennte Liste von Rufnummern oder Rufnummernteilen die festlegen ob der Client bei listen überhaupt abheben soll.
Bsp : attr mySIP sip_filter **61,123
**61 = alle DECT Telefone der Fritzbox (610 -619 )
123 = alle Rufnummern in denen die Folge 123 enthalten ist. 

[det.]

...Ich checke jetzt noch eine neue Version des Moduls ein, habe ein paar Kleinigkeiten beim Logging angepasst und ein neues Attribut sip_filter.
sip_filter ist eine Komma getrennte Liste von Rufnummern oder Rufnummernteilen die festlegen ob der Client bei listen überhaupt abheben soll.
Bsp : attr mySIP sip_filter **61,123
**61 = alle DECT Telefone der Fritzbox (610 -619 )
123 = alle Rufnummern in denen die Folge 123 enthalten ist.

Vielen Dank, darauf hatte ich noch gewartet. die Text2speech Funktion geht prima, habe auch ein Intel (NUK) System. Das ist zwangsläufig, wenn man schon ca. 7 Jahre Fhem im Einsatz hat.


Hatte leider heute das Problem, das FHEM beim Neustart hängen blieb mit dieser letzten Zeile im LOG:

Code Auswählen Erweitern

Undefined subroutine &main::SIP_watchdog_t2s called at fhem.pl line 2907.
nach Auskommentieren des T2S geht es wieder, anschließendes wieder Reinnehmen des T2S funktioniert auch

[Wzut]

@det, danke für die Info. SIP_watchdog_t2s ist falsch es muss SIP_watchdog_T2S sein. Werde ich gleich fixen

[plin]

Performance auf Raspi

@Wzut:

Ich war gerade mal so kühn und habe in .../Net/SIP/DTMF.pm (v 0.808, Zeile 385) folgende Änderung vorgenommen:

<snip>
sub _dtmf_xtc_audio {
        return;
    };

sub xxx_dtmf_xtc_audio {
    _init_audio_processing() if !@costab;
</snip>

Dadurch wird vermutlich die Frequenz-Erkennung und daraus Ableitung von DTMF-Tönen ausgeschaltet. Ohne diese Routine läuft's auch auf dem Raspi.

SIP-Client war meine Analyse-Script (peter30.pl). Ich kann von meiner FritzFon-App aus anrufen, es werden Tastendrücke empfangen und korrekt erkannt. Ist aber vermutlich nur RFC2833 und kein klassisches piep-piep-DTMF-Audio.

Was nun? Man müsste in die _dtmf_xtc_audio einsteigen und vermutlich deren Vorgehensweise ändern:

• feststellen, ob so etwas wie DTMF-Audio in der payload enthalten ist
• nein => nix wie raus hier und keine CPU-Last erzeugen
• ja => payload analysieren was evtl. DTMF-Events auslöst

Mit dem Ansatz ließe sich vielleicht die CPU-Auslastung reduzieren.

Oder man nimmt die Sub komplett auseinander und schreibt eine performantere Fassung.

[plin]

Oder man nimmt die Sub komplett auseinander und schreibt eine performantere Fassung.

mmh, wäre doch mal eine schöne Übung für pah's Studenten ? Ein Wettbewerb???