Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

Wzut

spontan fällt mir da auf :
sip_listen wfp
sip_waittime 3000

D.h. du nutzt den Mode wfp und 3000 Sekunden bis das Gespräch angenommen werden soll.
Was passiert denn wenn die 50 Minuten um sind ?
Wie schaut denn deine Anwendung aus ? Sicher das wfp für dich die richtige Betriebsart ist ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Je nachdem was passieren soll ist eine Kombination aus sip_filter/sip_blocking evtl. zielführend.
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

Muschelpuster

#377
Auch von mir erst einmal einen fettes Daumen hoch für diese Modul.

Zitat von: RitterSport am 23 Juni 2017, 16:26:02
Ich kann es drehen und wenden wie ich möchte, aber ich bekomme es NICHT hin das das Telefone nicht weniger als 10 mal klingelt.

set Klingel_Telefon **610 01 -> minimum 10 x klingeln
set Klingel_Telefon **610 1   -> minimum 10 x klingeln
set Klingel_Telefon **610 5 -> dito
Genau das Problem habe ich auch. Da ich ansatzweise das SIP-Protokoll verstehe, habe ich neben dem Log mal einen tcpdump auf dem FHEM-System gemacht und das finde ich nicht schön.
Zwar ist es bei Digest Authentication normal, dass ein Register als unauthorized abgelehnt wird und dann neu versucht wird, aber das in dem Spiel das Modul am Ende bereits 6 Bindings zur Fritte hat sollte eher nicht so sein. Genauso verrückt sieht der Rufaufbau aus: Zuerst ein Invite, dass wird mit Unauthorizied abgelehnt und dann aber doch ein ACK und dann ein neues Invite und die Fritte wählt los. Und das alles auf der gleichen CallID.. Das mag ja alles legitim sein, aber ich finde es auf jeden Fall spannend.
Ähnlich sieht es auch am gewünschten Rufende aus: FHEM schickt ein Bye, Fritte sagt erst Cancelled, dann ok und klingelt munter weiter.
Da scheint das Net::SIP doch einige Schwächen, oder zumindest Meinungsverschiedenheiten mit Onkel Fritz zu haben, denn mit anderen SIPClients gibt es an der Fritte keine Probleme.

getracte Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

geiercasi

Zitat von: Wzut am 04 November 2017, 17:42:08
spontan fällt mir da auf :
sip_listen wfp
sip_waittime 3000

D.h. du nutzt den Mode wfp und 3000 Sekunden bis das Gespräch angenommen werden soll.
Was passiert denn wenn die 50 Minuten um sind ?
Wie schaut denn deine Anwendung aus ? Sicher das wfp für dich die richtige Betriebsart ist ?
der Client schaltet bisher die Anrufweiterschaltung der Telefonanlage und soll keine Anrufe an nehmen.
Nun ist sip_waittime 3 & attr obelix sip_ringtime 300 eingestellt. das löst aber mein Problem nicht.
Bei sip_listen none wird ein Anruf ja garnicht war genommen. Ich möchte aber bei einem Anruf eine Hue blinken lassen, aber nur bis zum auflegen also caller_state waitting.

Gruß und danke für deine Fragen :)

Wzut

Zitat von: Muschelpuster am 05 November 2017, 10:33:47
Auch von mir erst einmal einen fettes Daumen hoch für diese Modul.
Danke :)
Zitat von: Muschelpuster am 05 November 2017, 10:33:47
scheint das Net::SIP doch einige Schwächen, oder zumindest Meinungsverschiedenheiten mit Onkel Fritz zu haben
Wenn du schon solche Erkentnisse hast und auch noch offensichtlich das entsprechendes SIP KnowHow wäre es dann nicht sinnvoll du würdest mal Kontakt mit Steffen Ullrich aufnehmen ? Ich denke er entwickelt sein Net::SIP noch immer weiter und wenn dort Bugs beseitigt werden kommt uns das doch allen wieder zu Gute.

Zitat von: geiercasi am 05 November 2017, 11:38:32
Ich möchte aber bei einem Anruf eine Hue blinken lassen, aber nur bis zum auflegen also caller_state waitting.
ja wie beim letzten Fall, reine Anklingel Maschine. IMHO müsste da ein extra Listen Modus her  um diese Fälle elegant abzudecken. Ich habe da bei mir auch so einen Einsatzfall im Hinterkopf, mal schauen wie die nächste Zeit Luft ist um mir über das Thema mal ein paar Gedanken zu machen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Zitat von: Wzut am 05 November 2017, 13:06:43
ja wie beim letzten Fall, reine Anklingel Maschine. IMHO müsste da ein extra Listen Modus her  um diese Fälle elegant abzudecken. Ich habe da bei mir auch so einen Einsatzfall im Hinterkopf, mal schauen wie die nächste Zeit Luft ist um mir über das Thema mal ein paar Gedanken zu machen.
@wzut: Denk an sip_filter/sip_blocking. Die hatten wir denke ich für genau so einen Fall vorgesehen. Statuseinzeige der SIP-Connection aber der Client soll nicht drangehen. Ist aber auch schon eine Weile her. Die Konstellation müsste ich auch erst noch mal durchspielen.
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

sojos

Hallo Wzut,

Zitat von: Wzut am 03 November 2017, 11:46:48
1. Das Modul sollte eigentlich mit jeder Art von SIP Server klar kommen. Wenn du hier mal etwas liest findest ausser FB Nutzer auch Vertreter von Asterisk oder externen SIP Providern ( eventuell schau dir mal www.sipgate.de an )

Port-Forwarding habe ich eingerichtet.
Die Attribute vom SIP-Module sind:

T2S_Device:         myT2S
sip_dtmf_loop:      once
sip_dtmf_send:     audio
sip_dtmf_size:      2
sip_elbc:              yes
sip_from:             sip:+491111111@tel.t-online.de
sip_ip:                 192.168.1.16
sip_listen:            none
sip_port:              5080
sip_registrar:        tel.t-online.de
sip_ringtime:        3
sip_user:              X.yyyyyy@t-online.de
verbose:               5

Telefonnummer habe ich hier auf 111111 geändert.
Die "sip_ip" ist die meines Raspberry auf dem fhem läuft.
Leider weis ich nicht so recht was ich unter "sip_from" eingeben soll,
die Beispiele die ich bisher gesehen habe beziehen sich alle auf eine FB
Wenn ich jetzt anrufen versuche erscheint folgendes im Log:


2017.11.05 16:22:25 4: TelefonAnruf, calling 01111111, ringtime: 30 , no message
2017.11.05 16:22:25 4: TelefonAnruf, TelefonAnruf|01111111|30||0
2017.11.05 16:22:25 4: TelefonAnruf, call -> TelefonAnruf|01111111|30||0|0
2017.11.05 16:22:25 5: TelefonAnruf, call has pid 21245
2017.11.05 16:22:25 4: TelefonAnruf[21245], my parent is 2206
2017.11.05 16:22:26 4: TelefonAnruf[21245], register new expire : Sun Nov  5 16:33:26 2017
2017.11.05 16:22:26 5: TelefonAnruf[21245], telnet : set TelefonAnruf state calling exit
2017.11.05 16:22:26 4: TelefonAnruf[21245], CallStart DTMF : ABCD*#123--4567890
Can't use string ("01111111") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.

Telefonnummer hier wieder ausgetauscht.
Ich habe mich mal bei sipgate.de angemeldet und versuch es nach Freischaltung auch damit.



Wzut

Zitat von: sojos am 05 November 2017, 16:48:11
Can't use string ("01111111") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Da müssen wir zuerst ansetzen, der Fehler findet sich hier und im alten im Fred recht oft : zu alte Version von Net::SIP !
Am besten via CPAN das altuelle Net::SIP installieren -> sudo cpan install Net::SIP

@plin , ja da war was ... aber bedingt duch mein Alter hab ich es schon wieder vergessen und muss wieder im Quelltext suchen,
wenn du es nicht für mich zum einfachen nachlesen ins Wiki schreibst :)

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Muschelpuster

Zitat von: Wzut am 05 November 2017, 13:06:43Wenn du schon solche Erkentnisse hast und auch noch offensichtlich das entsprechendes SIP KnowHow wäre es dann nicht sinnvoll du würdest mal Kontakt mit Steffen Ullrich aufnehmen ? Ich denke er entwickelt sein Net::SIP noch immer weiter und wenn dort Bugs beseitigt werden kommt uns das doch allen wieder zu Gute.
Da bin ich mir nicht ganz so sicher, wenn ich unter https://metacpan.org/pod/distribution/Net-SIP/lib/Net/SIP.pod#COPYRIGHT schaue:
ZitatThis module and are modules in the Net::SIP Hierarchy distributed together with this module are copyright (c) 2006-2013, Steffen Ullrich. All Rights Reserved.
Wobei ich die aktuelle Version 0.810 wohl vom 08.08.17 ist, wenn ich die Seite richtig deute.

Wie geschrieben verstehe ich als gelernter Telefoner ansatzweise SIP, aber grundsätzlich ist SIP IMHO schon recht schwierig. Der Erfolg beruht keineswegs darauf, dass SIP das perfekte Protokoll ist, sondern einfach nur, dass es als textbasiertes Protokoll relativ leicht zu programmieren ist. Dafür verbraucht es aber z.B. viel mehr Protokolloverhead sowie Rechenleistung zum Parsen des Protokolls gegenüber z.B. H.323, was HEX-kodiert arbeitet. In unserem Umfeld kein Thema, im Enterprise-Sektor schon. Zudem ist SIP aber eben nur 'weich' über eine RFC definiert, was immer Interpretationsspielraum zulässt und so auch mein täglich Sorgenkind ist. Sei es, dass Devices und Anlagen da Meinungsverschiedenheiten haben oder eben die Anlagen mit den Providern - irgendetwas klemmt im SIP immer  :(
Nun müsste ich aber zuerst einmal mein Net::SIP auf diese Version bekommen (Debian Stretch liefert derzeit über apt die 0.808 aus). Dazu habe ich schon etwas gelesen, am Ende aber die Aussage gefunden, dass es keine gute Idee ist, mit apt installierte Perl-Module mittels CPAN zu aktualisieren. Da fehlt mir im Moment noch etwas know how, aber ich werde nochmal eine Studienreise in's Netz der Netze machen  ;)

inaktuelle Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Wzut

Zitat von: Muschelpuster am 05 November 2017, 18:02:10
Nun müsste ich aber zuerst einmal mein Net::SIP auf diese Version bekommen (Debian Stretch liefert derzeit über apt die 0.808 aus). Dazu habe ich schon etwas gelesen, am Ende aber die Aussage gefunden, dass es keine gute Idee ist, mit apt installierte Perl-Module mittels CPAN zu aktualisieren. Da fehlt mir im Moment noch etwas know how
Die 0.808 ist zumindest eine Version die läuft und konnte recht einfach installiert werden auch wenn man mit cpan nicht so vertraut ist bzw.
cpan zu viel meckert und dann doch nicht installiert. Inzwischen gibt es zwar schon 0.810 aber der Weg den ich hier https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836 beschrieben habe sollte auch für 0.810 noch gültig sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

#385
Zitat von: plin am 05 November 2017, 16:16:45
@wzut: Denk an sip_filter/sip_blocking. Die hatten wir denke ich für genau so einen Fall vorgesehen. Statuseinzeige der SIP-Connection aber der Client soll nicht drangehen. Ist aber auch schon eine Weile her. Die Konstellation müsste ich auch erst noch mal durchspielen.

Hab's gerade noch mal ausprobiert. Bei sip_filter = 12345 erkennt er den Anruf und ignoriert ihn. Bei sip_blocking = .* registriert er den Anruf und drückt ihn direkt weg.  Also beides keine Lösung.

@geiercasi: Wie wär's denn mit einem simplen Fritzbox-Client? Der zeigt mir die Anrufe im CallMonitor an.
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

@plin, meine Oma hätte jetzt gesagt "zwei Dumme ein Gedanke"  :) Ich habe das gestern Abend auch so mal durchprobiert.
Sicher der Call Monitor ist da die bessere Wahl, allerdings halt nur wenn man auch eine FB hat. Ich bin mir immer noch unsicher ob Net::SIP das nicht doch könnte.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

eppi

Hallo
Wie bereits geschrieben, nutze ich das SIP-Modul (besten Dank dafür) um ankommende Anrufe zu signalisieren. Da ich früher eine Fritzbox im Einsatz hatte, konnte ich das Modul FB_Calllist http://www.fhem.de/commandref.html#FB_CALLLIST nutzen, um Anrufe zu speichern. Wie könnte man das mit dem SIP-Modul machen, dass es ebenfalls als Call-History-Liste in FHEM integriert wird? Habt ihr eine Idee?
Danke und Gruss Eppi

plin

Zitat von: eppi am 07 November 2017, 18:35:21
Hallo
Wie bereits geschrieben, nutze ich das SIP-Modul (besten Dank dafür) um ankommende Anrufe zu signalisieren. Da ich früher eine Fritzbox im Einsatz hatte, konnte ich das Modul FB_Calllist http://www.fhem.de/commandref.html#FB_CALLLIST nutzen, um Anrufe zu speichern. Wie könnte man das mit dem SIP-Modul machen, dass es ebenfalls als Call-History-Liste in FHEM integriert wird? Habt ihr eine Idee?
Danke und Gruss Eppi

Wie wäre es mit einem FileLog?
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

Zitat von: Wzut am 07 November 2017, 09:38:34
Ich habe das gestern Abend auch so mal durchprobiert.

Das "mal durchprobieren" wurde bei mir eine längere Aktion bis hin zur Ergänzung des Wiki. Mein Test-SIP-Account konnte sich mit den altbekannten Einstellungen nicht anmelden (FritzOS 6.90).
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