Hauptmenü

Modul 96_SIP

Begonnen von Wzut, 19 Februar 2017, 19:10:09

Vorheriges Thema - Nächstes Thema

Wolle02

Zitat von: Wzut am 27 Oktober 2020, 17:15:05
versuch mal set <name> reset, dass killt einen aktiven Child Prozess.

Das hab ich natürlich probiert, aber leider läuft der Anruf weiter. Im "call_state" steht dann weiterhin "calling <Rufnummer>" und im "state" steht "initialized".    :-[

Wzut

dann hat die FB bzw dein SIP Server schon komplett das Heft in der Hand und lässt es sich so einfach nicht mehr abnehmen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wolle02

Ah, ok. Aber nur für mein Verständnis; wie muss ich mir das vorstellen? Das FHEM SIP-Device ist ja in der FB als "LAN-Telefon" eingerichtet. Von dort geht der Callaufbau dann zu meinem VOIP-Anbieter. Wenn ich mit meinem DECT-Telefon an der FB eine Verbindung über meinen VOIP-Anbieter aufbaue ist das ja eigentlich der gleiche Weg über die gleichen Komponenten (FB -> SIP Server). Wenn ich aber an meinem DECT-Telefon nach Rufaufbau die rote Taste drücke, dannn wird der Rufaufbau beendet. Welche Befehle/Protokolle da im Hintergrund wie zusammenarbeiten, weiß ich natürlich nicht.
Warum funktioniert das mit dem SIP-Device nicht bzw. ist die Funktionalität der "roten Taste" hier nicht möglich?

Wzut

Ich schrieb "so einfach" im Sinne von einfach den Prozess weghauen und nicht "gar nicht".
Man kann bestimmt der FB die rote Taste unterschieben ( $call->cancel ? ) aber das haben wir im Modul so nicht drin und ich habe es persönlich auch noch nie probiert.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wolle02

Alles klar; entschuldige bitte das Verständnisproblem.  :D

Dürfte ich denn das als Featurerequest vortragen?

Zum Hintergrund:
Ich möchte gerne das SIP-Modul als Alarmierungsmöglichkeit im Zusammenhang mit dem Alarmmodul benutzen. Grundsätzlich funktioniert das auch sehr gut. Wenn jetzt aber ein Fehlalarm (z.B. durch falsches Betreten oder eine Störung) erfolgt und dieser mittels eines Alarm-Resets wieder beendet wird, dann soll natürlich auch die Alarmierung mittels eines Anrufs über das SIP-Modul nicht mehr erfolgen. Dazu muss aber der Anruf abgebrochen werden, weil er sonst trotzdem rausgeht.

Gruß
Wolle

Wzut

Zitat von: Wolle02 am 28 Oktober 2020, 07:51:35
Dürfte ich denn das als Featurerequest vortragen?
na sicher wünschen darf man sich immer :) Wir haben auf Userwunsch schon einige Dinge im Modul umgesetzt die wir selbst gar nicht brauchen.
Das Problem sehe ich für mich momentan in der freien Zeit, wird sich vllt. ab Januar 2021 ändern wenn ich endlich in Rente bin,
aber eventuell hat ja Peter (plin)  Luft sich das mal zur Brust zu nehmen .....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Zitat von: Wzut am 28 Oktober 2020, 08:18:29
na sicher wünschen darf man sich immer :) Wir haben auf Userwunsch schon einige Dinge im Modul umgesetzt die wir selbst gar nicht brauchen.
Das Problem sehe ich für mich momentan in der freien Zeit, wird sich vllt. ab Januar 2021 ändern wenn ich endlich in Rente bin,
aber eventuell hat ja Peter (plin)  Luft sich das mal zur Brust zu nehmen .....
Ich kann am Wochenende mal schauen was das Net::SIP Modul dafür ein petto hat.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

thunder1902

#1117
Hallo!
Ich komme nicht weiter ...

Habe Fhem im Raspberry-Docker am Laufen, und bekomme bei einem initiiertem Anruf mit "call **621 30 !Hallo Test" nichts angesagt.

Wenn ich den Anruf starte, klingelt auch das Telefon. Nur die Ansage wird nicht ausgeführt.

Mein Device sieht so aus:
defmod telsip2 SIP
attr telsip2 T2S_Device mytts
attr telsip2 T2S_Timeout 10
attr telsip2 audio_converter sox
attr telsip2 disabled 1
attr telsip2 history_file ./log/telsip2.sip
attr telsip2 history_size 0
attr telsip2 room SIP
attr telsip2 sip_dtmf_loop once
attr telsip2 sip_dtmf_send audio
attr telsip2 sip_dtmf_size 2
attr telsip2 sip_elbc yes
attr telsip2 sip_from sip:telefon@192.168.178.1
attr telsip2 sip_ip 172.17.0.9
attr telsip2 sip_listen none
attr telsip2 sip_port 5060
attr telsip2 sip_registrar 192.168.178.1
attr telsip2 sip_ringtime 3
attr telsip2 sip_user telefon
attr telsip2 sip_waittime 5
attr telsip2 verbose 5


Was mir noch aufgefallen ist, dass die angegebene Log Datei "history_file ./log/telsip2.sip" auch nicht erstellt wird.

Eine statische Route habe ich bereits in meiner Fritzbox erstellt - sowie auch die anderen Maßnahmen, die in https://forum.fhem.de/index.php?topic=102206.0 diesem Thread beschrieben sind.
Die Audiodateien werden im cache-Verzeichnis erstellt.
Hier noch der gesamte Log, der in der Log-Datei steht:

2020.11.16 18:35:17 5: telsip2, MD5: Dies ist ein Test -> a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 5: telsip2, mp3 File file not found in cache
2020.11.16 18:35:17 4: telsip2, wait_for_t2s file : cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 4: telsip2, new T2S file cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 5: telsip2, /usr/bin/sox cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3 -t raw -r 8000 -c 1 -e a-law cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw 2>&1
2020.11.16 18:35:17 4: telsip2, audio file cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw found
2020.11.16 18:35:17 4: telsip2, telsip2|**621|30|cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw|0
2020.11.16 18:35:17 4: telsip2, call -> telsip2|**621|30|cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw|0|0
2020.11.16 18:35:17 5: telsip2, call has pid 22412
2020.11.16 18:35:17 4: telsip2[22412], my parent is 57
2020.11.16 18:35:17 4: telsip2[22412], trying to use port 5070
2020.11.16 18:35:17 4: telsip2[22412], register new expire : 2020-11-16 18:40:17
2020.11.16 18:35:17 5: telsip2, readingS:state Val:calling
2020.11.16 18:35:17 4: telsip2[22412], CallStart with 1 files - first file : cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw - PCMA/8000 , repeat 0
2020.11.16 18:35:17 4: telsip2[22412], calling : **621
2020.11.16 18:35:17 5: telsip2, readingS:call_state Val:calling **621
2020.11.16 18:35:21 4: telsip2[22412], cb_final - status : OK
2020.11.16 18:35:21 4: telsip2[22412], call established
2020.11.16 18:35:21 5: telsip2, readingS:call_state Val:established
2020.11.16 18:35:23 5: telsip2[22412], 0. Ende des ersten Loops
2020.11.16 18:35:23 5: telsip2[22412], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x47f8700)
2020.11.16 18:35:23 5: telsip2[22412], 2. fi : 0
2020.11.16 18:35:23 5: telsip2[22412], 4. timeout : 0
2020.11.16 18:35:23 5: telsip2[22412], 6. call_established : 1
2020.11.16 18:35:23 5: telsip2[22412], call->bye
2020.11.16 18:35:23 5: telsip2[22412], RTP done : Net::SIP::Simple::Call=HASH(0x47f8700)
2020.11.16 18:35:23 5: telsip2[22412], Timeout  : 0
2020.11.16 18:35:23 5: telsip2[22412], while    : 0
2020.11.16 18:35:23 5: telsip2[22412], Status   : OK
2020.11.16 18:35:23 4: telsip2[22412], Calltime : 2
2020.11.16 18:35:23 4: telsip2, CALLDone -> telsip2|1|ok|2
2020.11.16 18:35:23 5: telsip2, fifo is empty
2020.11.16 18:35:23 5: telsip2, no elbc


Kann mir jemand helfen??

Wzut

Zitat von: thunder1902 am 16 November 2020, 18:36:59
attr telsip2 history_file ./log/telsip2.sip
attr telsip2 history_size 0
size ungleich 0 stellen , ist die max Anzahl von Einträgen.
Docker & RTP -> https://wiki.fhem.de/wiki/SIP-Client#Docker
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wolle02

Zitat von: plin am 28 Oktober 2020, 18:10:49
Ich kann am Wochenende mal schauen was das Net::SIP Modul dafür ein petto hat.

Guten Morgen plin,

hast du hier eventl schon etwas herausbekommen?

Gruß
Wolle

plin

@wzut:

Schau Dir mal im Net/SIP/Request.pm die Passage

###########################################################################
# Create cancel for request
# Args: $self
# Returns: $cancel
#   $cancel: Net::SIP::Request containing CANCEL for $self
###########################################################################
sub create_cancel {
    my Net::SIP::Request $self = shift;
    # CANCEL uses cseq from request
    $self->cseq =~m{(\d+)};
    my $cseq = "$1 CANCEL";
    my %auth;
    for (qw(authorization proxy-authorization)) {
        my $v = scalar($self->get_header($_)) or next;
        $auth{$_} = $v;
    }
    my $header = {
        'call-id' => scalar($self->get_header('call-id')),
        from      => scalar($self->get_header('from')),
        # unlike ACK the 'to' header is from the original request
        to        => [ $self->get_header('to') ],
        via       => [ ($self->get_header( 'via' ))[0] ],
        route     => [ $self->get_header( 'route' ) ],
        cseq      => $cseq,
        %auth
    };
    return Net::SIP::Request->new( 'CANCEL',$self->uri,$header );
}


an. Mittels Net::SIP::Request->new( 'CANCEL',$self->uri,$header ) könnte da evtl. etwas gehen.

VG plin
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Wzut

ja ok, da ist offensichtlich etwas da um einen laufenden Call mit CANCEL zu beenden.
Die gute Frage ist aber nun wie bindet man das sinnvoll ein und vor allem wo ?
Wo dreht das seine Runden sobald der Call raus ist ? -> $ua->loop(  ? und da noch eine Variable $cancel als Abbruchmöglichkeit ?
Und dann die Frage, wie kommt die Info das abgebrochen werden soll vom Parent zum Child ?
Wir haben bisher nur die Gegenrichtung mit BlockingInforParent.
Beim lesen des Codes kam mir noch eine andere Idee : Wir starten doch mit $ua->add_timer($ringtime,\$stopvar)  eine max Call Zeit.
Wenn man nun nachträglich diesen laufenden Timer so manipulliert könnte das er abgelaufen ist, dann sorgt doch die bestehende Kette für ein sauberes Ende des Calls ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Zitat von: Wzut am 21 November 2020, 18:05:24
ja ok, da ist offensichtlich etwas da um einen laufenden Call mit CANCEL zu beenden.
Die gute Frage ist aber nun wie bindet man das sinnvoll ein und vor allem wo ?
Wo dreht das seine Runden sobald der Call raus ist ? -> $ua->loop(  ? und da noch eine Variable $cancel als Abbruchmöglichkeit ?
Und dann die Frage, wie kommt die Info das abgebrochen werden soll vom Parent zum Child ?
Ich habe CANCEL-Requests gesehen bei denen man die kompletten Call-Informationen mitgibt. Vielleicht wird so der Call identifiziert.

Zitat von: Wzut am 21 November 2020, 18:05:24
Beim lesen des Codes kam mir noch eine andere Idee : Wir starten doch mit $ua->add_timer($ringtime,\$stopvar)  eine max Call Zeit.
Wenn man nun nachträglich diesen laufenden Timer so manipulliert könnte das er abgelaufen ist, dann sorgt doch die bestehende Kette für ein sauberes Ende des Calls ?
Die Idee hatte ich auch schon. Kommt man da noch dran? Schaut der ausgehende Call immer wieder auf die Variable?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

Ich habe mein Glück mal auf Basis des samples/invite_and_send.pl versucht. Puh. Während des ausgehenden Calls wartet das Script. Ein Versuch parallel dazu den CANCEL wie in 3pcc.pl abzussetzen hat bisher auch noch nicht gefruchtet.

Wie wär's mit einem FHEM shutdown restart? Der ist einfacher zu realisieren  :).
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

pwlr

Moin,
Ihr kennt das sicher, diese nervigen Werbeanrufe und sonstiger Müll. Da das bei mir in letzter Zeit immer schlimmer wird, bin ich bei der Suche nach einer Lösung auf dieses Modul gestoßen. Super Sache, danke an den Entwickler und alle Mitwirkenden !!  :) :)

Mit einer Sperre über eine Blacklist kommt man nicht richtig weiter, weil diese Leute offensichlich große Rufnummernkontingente besitzen. Also, mein Konzept, alle Anrufe zurückweisen, die nicht in einer Whitelist (Telefonbuch der Fritz!Box) enthalten sind. Das ist zwar ne heftige Lösung, weil neue Kontakte nicht immer sofort im Telefonbuch eingepflegt sind. Aber mal versuchen und über ein userReading filtern, caller_nr ohne caller_name per set <sip_client> reject abweisen.

userReadings   promotion:(caller_state.*) {stop_sales_promotion($name)}

und dann in einer sub
if ($caller_state eq "calling" and $caller_name eq "unknown") => reject

Allerdings habe ich mir mit diesem Prinzip teilweise FHEM-Loops bis hin zu Abstürzen des Raspi eingehandelt. Die Lösung war dann ein verzögertes reject mit einem AT.
sub stop_sales_promotion_01 ($){
my($name) = @_;
my$sub_name = "stop_sales_promotion_01";
Log3 $name, 2, "$name $sub_name: start";

fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client reject");

#fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client fetch"); #funktioniert

Log3 $name, 2, "$name $sub_name: end";
return;
};


Funktioniert teilweise, allerding beendet der sip_client NICHT das Gespräch, obwohl nach Lage der readings in der Weboberfläche alles klar ist.

Ich bin ratlos, was mache ich falsch ? :(
Oder gibt es eine bessere Lösung ?
Bin für jeden Tipp dankbar
Moin
Bernd