Hallo zusammen, jetzt komme ich endlich dazu, mein Projekt hochzuladen: https://github.com/chrta/sip_call Funktion Wenn es an der Tür klingelt, wird eine beliebige Nummer in der lokalen Fritzbox angerufen (Rundruf per **9 geht auch). Firmware Dabei handelt es sich um ein C/C++ (gemischt) Projekt auf Basis vom aktuellen ESP-IDF (also freertos, lwip, mbedtls). Das SIP-Protokoll ist selbst implementiert. Es ist seit ein paar Monaten in Betrieb und scheint zuverlässig zu funktionieren. Alle Einstellungen werden dabei statisch in die Firmware einkompiliert. Mit "make menuconfig" müssen SSID, WLAN-Passwort, SIP-Zugang etc gesetzt werden. Die Hardware besteht aus einem beliebiges ESP32-Board, getestet mit http://www.watterott.com/de/ESP-WROOM32-Breakout, 2 Optokopplern und 2 Widerständen. Da ich das ESP32-Board direkt aus dem Klingeltrafo versorge, habe ich noch einen Brückengleichrichter, einen dicken Elko und eine kleine Schaltreglerplatine im Einsatz. Das Projekt ist "Work in Progress", aber der aktuelle Stand funktioniert an einer Fritzbox 7490. Gruß, Christian
:
Bearbeitet durch User
Hallo Christian, Währe das auch mit einem ESP8266 gegangen ? LG Christof
Ich denke, das würde auch mit einem ESP8266 funktionieren. Wahrscheinlich ist nur die Latenz (Klingeln erkennen -> Anruf auslösen) etwas größer.
Christian T. schrieb: > Funktion > Wenn es an der Tür klingelt, wird eine beliebige Nummer in der lokalen > Fritzbox angerufen (Rundruf per **9 geht auch). interessant, mit Clip? Das man im Telefon sieht die Nummer der Türklingel, bzw. Türklingel im Telefon hinterlegen kann zur Nummer?
Joachim B. schrieb: > interessant, mit Clip? > Das man im Telefon sieht die Nummer der Türklingel, bzw. Türklingel im > Telefon hinterlegen kann zur Nummer? Ja, das geht. In der Anrufnachricht (SIP INVITE) wird zusätzlich eine beliebige Zeichenkette übertragen. Per "make menuconfig" kann man die setzen, siehe https://github.com/chrta/sip_call/blob/master/main/Kconfig.projbuild#L93 Bei mir steht zB "Türklingel" im Display, ohne dass man die Telefonnummer der Türklingel unter dem Namen im Telefon (oder der Fritzbox) abspeichern muss.
:
Bearbeitet durch User
Deinen SIP-Connector muss ich mir mal reinpfeifen ich hoffe ich verstehe ihn. Der Umsetzungsansatz hat echt was. Könnte man auch vom Telefon aus die Tür öffnen ?
Einen Türöffner anzuschliessen dürfte nicht so schwer sein. Wenn man den Anruf von dem ESP32 annimmt, kann man danach Tasten auf dem Telefon drücken. Diese werden jetzt schon als SIP INFO-Paket an den ESP32 gesendet. In dem Paket steht direkt die gedrückte Taste im Klartext. Das Parsen und Auslösen einer Aktion fehlt noch.
schomma sehr geil, sowas such ich seit Jahren. Cool, alle Daumen hoch !
Danke für das Lob :) Das Drücken einer Taste am Telefon wird jetzt auch erkannt und an einen Event-Handler übergeben: https://github.com/chrta/sip_call/blob/master/main/main.cpp#L148 An der Stelle könnte man zB eine PIN parsen und dann das Türöffner-Relais ansteuern.
Ein tolles Projekt! Bin ich eigentlich nur drüber gestolpert, weil ich nach boost::sml gesucht hatte. Nun hat mir das als boost::sml Beispiel zwar nix gebracht (kommt da noch mehr?), dafür aber trotzdem angeregt, mal nachzuschauen, ob hier noch ein ESP32 rumfliegt...
MicroWolfgang schrieb: > Nun hat mir das als boost::sml Beispiel zwar nix gebracht (kommt da noch > mehr?), Mein Plan ist es die SIP-Statemachines im SipClient mit boost::sml zu machen und diverse switch-case-Blöcke loszuwerden. Das wird wohl noch eine Weile dauern.
:
Bearbeitet durch User
Ok, Ich sehe du hast gelernt wie man C++ programmiert. Ich kapituliere um deinen Code zu durchschauen reicht mein C++ Wissen nicht.
Christof Rieger schrieb: > Ich kapituliere um deinen Code zu durchschauen reicht mein C++ Wissen > nicht. Der Code ist auch noch nicht dokumentiert, von daher ist die Einstiegsschwelle schon etwas höher, und besonders schön ist er auch noch nicht. Was willst du denn machen? Um einen Türöffner anzusteuern solltest du nur den zuletzt hinzugekommenen Eventhändler in der main.cpp verändern müssen, also sobald SipClientEvent::Event::BUTTON_PRESS kommt, die Tasten merken und bei Bedarf einen GPIO ansteuern.
Kleiner Tip: Statt zwei PC817 Optokopplern kannst Du auch einen PC814 einsetzen. Der hat gleich antiparallele LEDs eingebaut und kann mit AC in beiden Polaritäten verwendet werden. Damit wird es noch kleiner und noch einfacher. Siehe z.B. https://www.vishay.com/docs/83523/83523.pdf fchk
Wie schaut es denn mit der Überlegung auch noch audio in beide richtungen zu Implementieren? Eigentlich sollte das auch simpel sein; Micro; => 4kHz samplen mit nem Timer und 8 bit? das ganze uLaw codieren, was ja quasi kreatives PCM ist? und die andere Richtung entweder einen zusätzlichen DA wandler per i2s oder auch in weichware aufm PWM pin? Theoretisch sollte das machbar sein oder?
Frank K. schrieb: > Kleiner Tip: Statt zwei PC817 Optokopplern kannst Du auch einen PC814 > einsetzen. Danke, das habe ich jetzt ins Readme geschrieben. Ich hatte nur noch ein paar PC817 hier rumfliegen, daher hab ich die benutzt. Martin schrieb: > Wie schaut es denn mit der Überlegung auch noch audio in beide > richtungen zu Implementieren? > > Eigentlich sollte das auch simpel sein; Micro; => 4kHz samplen mit nem > Timer und 8 bit? das ganze uLaw codieren, was ja quasi kreatives PCM > ist? und die andere Richtung entweder einen zusätzlichen DA wandler per > i2s oder auch in weichware aufm PWM pin? > Theoretisch sollte das machbar sein oder? Audio hab ich nicht auf meiner Liste, aber ich nehme natürlich gerne Pull-Requests an :) Erstmal müsste das SDP-Paket angepasst werden: https://github.com/chrta/sip_call/blob/master/components/sip_client/include/sip_client/sip_client.h#L509 Empfangen werden die Audio-Daten in https://github.com/chrta/sip_call/blob/master/components/sip_client/include/sip_client/sip_client.h#L32 aber bisher verworfen. Ich denke um Audio zu versenden, könnte man das über den bestehenden socket im rtp_task machen.
Super, wie sich das entwickelt. Zum Code : Ja, OK bissi Doku fehlt, aber sieht ansonsten schonmal ganz sauber aus. Schade dass ich grad keine Zeit dafür hab, sonst würd ich gern mit einsteigen, weil GENAU SOWAS suche ich schon länger. Weiter so, gruß
Christian T. schrieb: > Frank K. schrieb: >> Kleiner Tip: Statt zwei PC817 Optokopplern kannst Du auch einen PC814 >> einsetzen. > > Danke, das habe ich jetzt ins Readme geschrieben. Ich hatte nur noch ein > paar PC817 hier rumfliegen, daher hab ich die benutzt. Ein einziger PC817 sollte reichen. Dazu eine 1N4148 Diode antiparallel verschaltet, damit die maximale Sperrspannung des PC817 nicht überschritten wird. Dann bekommt der ESP statt 50 Hz ein 25 Hz Signal. >> Eigentlich sollte das auch simpel sein; Micro; => 4kHz samplen mit nem >> Timer und 8 bit? das ganze uLaw codieren, was ja quasi kreatives PCM >> ist? In Europa ist eher A-Law üblich, μ-Law in Amerika. Daher klingt A-Law für empfindliche europäische Ohren vertrauter. Für unempfindliche Ohren ists egal :). Die FritzBox kann beides und ein paar mehr https://ch.avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/1008_Unterstuetzte-Sprach-Codecs-bei-Internettelefonie/ Vielleicht hilft https://github.com/deftio/companders und die andere Richtung entweder einen zusätzlichen DA wandler per >> i2s oder auch in weichware aufm PWM pin? >> Theoretisch sollte das machbar sein oder? > > Audio hab ich nicht auf meiner Liste, aber ich nehme natürlich gerne > Pull-Requests an :) > > Erstmal müsste das SDP-Paket angepasst werden: > https://github.com/chrta/sip_call/blob/master/comp... > > Empfangen werden die Audio-Daten in > https://github.com/chrta/sip_call/blob/master/comp... > aber bisher verworfen. Ich denke um Audio zu versenden, könnte man das > über den bestehenden socket im rtp_task machen.
Hallo Christian, erstmal danke für das erstellen und sharen dieses Projekts. Ich hab mich jetzt auch mal an die Umsetzung gemacht, wird bei mir hardwareseitig ein wenig anspruchsvoller, da ich sehr wenig Power aus meinem Handsprechhörer bekomme. Aber da hab ich schon Ideen und denke, ich krieg das schon hin. Leider fehlt mir dafür ein bissel die Softwareseite. Was erstmal nicht schlimm ist, da Du ja schon sauber vorgearbeitet hast. Allerdings hab ich Dein Programm getestet und dabei klingelt es auf meinem Telefon nach dem Auslösen permanent und findet nicht das Ende nach 5000 (ms?). Das einzige, was ich dann tun kann, ist auf jedem Mobilteil einzeln auf 'ablehnen' klicken (oder auf 'annehmen' und anschließend wieder auflegen). Danach kriege ich einen dauerhaft durchlaufende Ausgabe (im mingw32 Monitorwindow). Nur ein beherzter Druck auf den Hardware-Reset beim ESP32 bringt diesen wieder in den Bereitschaftsmodus. Ist Dir das im Zuge Deiner Entwicklung mal untergekommen und fandest Du eine Lösung? Ich habe versucht, mich im Code zurechtzufinden, um ggfs. ein paar Print-Statements an den vermeintlich richtigen Stellen einzubauen zur Überwachung, aber da bin ich grandios gescheitert. Danke! Joe
Hallo Jack, > Ein einziger PC817 sollte reichen. Dazu eine 1N4148 Diode antiparallel > verschaltet, damit die maximale Sperrspannung des PC817 nicht > überschritten wird. Dann bekommt der ESP statt 50 Hz ein 25 Hz Signal. Ja, danke. Das werde ich noch ändern, sobald ich wieder was daran mache. Hallo Joe, du könntest in der Zeile https://github.com/chrta/sip_call/blob/master/main/button_handler.h#L81 eine Ausgabe einfügen. Evtl. steht das Klingelsignal länger am Eingang an? Dann wird der Timeout auch immer weiter verlängert. Die Dauer, die das Telefon max Klingeln sollte ist per "make menuconfig" einstellbar, siehe https://github.com/chrta/sip_call/blob/master/main/Kconfig.projbuild#L39 Der Standardwert ist 7000 Millisekunden.
In diesem Thread hatte ich mal eine Alternative vorgestellt, die deutlich einfacher ausgefallen ist. Beitrag "Sipdial per ESP8266 an Fritzbox" Was mir hierbei aufgefallen ist, der esp8266 ist deutlich schneller beim WLAN-Verbinden nach dem Tiefschlaf als der ESP32. Der esp8266 speichert sich selbst die letzten Verbindungsdaten intern ab. Dieses Vorgehen wurde aber beim ESP32 noch nicht implementiert. Bzw. kann auch sein, dass ich nicht weiss wie das beim ESP32 geht. Jedenfalls habe ich 0,5 bis 0,8sec mit dem ESP8266 und knapp 3s mit dem ESP32. Wie sind denn die Zeiten bei diesem Projekt hier, was ja eine komplett andere Build-Umgebung hat?
Mit Deepsleep habe ich noch nicht experimentiert. Aber ich glaube, dass es auch so um die 3 bis 5 Sekunden dauert, um sich am AP anzumelden und eine IP-Adresse per DHCP zu bekommen. Ich warte noch, dass Lightsleep(WLAN) für den ESP32 im ESP-IDF implementiert wird. Damit sollte es dann genauso wie beim ESP8266 funktionieren. Mit dem aktuellen Modemsleep habe ich ca 100mA kontinuierlichen Strombedarf bei 240MHz...
Christian T. schrieb: > Hallo Joe, > > du könntest in der Zeile > https://github.com/chrta/sip_call/blob/master/main/button_handler.h#L81 > eine Ausgabe einfügen. Evtl. steht das Klingelsignal länger am Eingang > an? Dann wird der Timeout auch immer weiter verlängert. > > Die Dauer, die das Telefon max Klingeln sollte ist per "make menuconfig" > einstellbar, siehe > https://github.com/chrta/sip_call/blob/master/main/Kconfig.projbuild#L39 > Der Standardwert ist 7000 Millisekunden. Hallo Christian, ich konnte zwar jetzt ein paar Sachen herausfinden, aber richtig voran hat es mich nicht gebracht. Da auch ich die Vermutung habe, dass der Pin falsch ausgelesen wird, wollte ich dessen Status ausgeben. Das ist mir aber nicht gelungen, wie gesagt, ich habe nur minimale C Erfahrung. Im Moment habe ich alles erstmal nur auf einem Board aufgebaut und simuliere das Klingeln durch ne Drahtverbindung mit der ich den Input-Pin kurz auf gnd ziehe, vorher und nachher wird er per Pull up auf 3.3V gehalten. Wenn das nicht richtig erkannt wird, dann kann das schon das Verhalten erklären. Drum würde ich gern den Status des Pins erfahren. Nur wo im Code kann ich den abgreifen und ausgeben? Danke! VG Joe
Martin schrieb: > die andere Richtung entweder einen zusätzlichen DA wandler per > i2s oder auch in weichware aufm PWM pin? siehe https://github.com/earlephilhower/ESP8266Audio#software-i2s-delta-sigma-dac-ie-playing-music-with-a-single-transistor-and-speaker. Ich empfehle noch einen Tiefpass. ;) Alternativ geht auch I2S mit einem MAX98357A (siehe https://www.adafruit.com/product/3006). I2S-input wird gerade implementiert (siehe https://github.com/esp8266/Arduino/issues/4496, https://github.com/joextodd/listener/issues/3) Das SPH0645LM4H ist eine I2S-Mikrofon (siehe https://www.adafruit.com/product/3421).
Joe schrieb: > ...Allerdings hab ich Dein Programm getestet und dabei klingelt es auf meinem Telefon nach > dem Auslösen permanent und findet nicht das Ende nach 5000 (ms?)... Das Problem hatte ich auch. In https://github.com/chrta/sip_call/blob/68cb26ffad099b9ba8548f973deb28bd23912d6e/main/button_handler.h#L102 muss statt des * ein / hin, dann passt die Zeit - zumindestens bei mir. Andernfalls klingen die Telefone eine gefühlte Ewigkeit und der Klingelknopf wird auch erst nach dieser Ewigkeit wieder freigeschaltet. Ich habe das ganze Projekt geforkt. Neben diesem Bugfix habe ich auch mal einen Türöffner implemetiert. Mit Audiogeschichten hab ich allerdings noch gar keine Erfahrung und Momentan auch nicht die Zeit mich da einzuarbeiten.
Gerhard J. schrieb: > Das Problem hatte ich auch. In > https://github.com/chrta/sip_call/blob/68cb26ffad099b9ba8548f973deb28bd23912d6e/main/button_handler.h#L102 > muss statt des * ein / hin, dann passt die Zeit - zumindestens bei mir. > Andernfalls klingen die Telefone eine gefühlte Ewigkeit und der > Klingelknopf wird auch erst nach dieser Ewigkeit wieder freigeschaltet. Vielen Dank für diese Lösung, jetzt funzt es bei mir auch! Wo kann man denn Deinen Fork finden? VG Joe
Forks findest du bei GitHub immer oben rechts, lohnt sich meistens da mal zu schauen ob schon jemand ein Projekt in eine Richtung weiterentwickelt hat die zu zu den eigenen Anforderungen passen. In diesem Fall führt dich das zu https://github.com/MeisterBob/sip_call
Hallo Christian, ich habe nun mehrere Tage benötigt, um esp-idf mit Eclipse und mit dem sip_call-client auf einem ESP-WROOM32 (LOLIN32 V.1.0.0) zum laufen zu bringen. Nachdem alles fehlerfrei compiliert wurde, hatte ich das Problem, dass die wifi-Initialisierung einfach nicht funktioniert hat. Nun habe ich den Fehler gefunden. In der Datei main.cpp, function initialize_wifi(void) wird die struct
1 | wifi_config_t wifi_config; |
nicht korrekt initialisiert. Nach der Dekleration von wifi_config muss der komplette Speicher genullt werden, ansonsten sind die im folgenden nicht initialisierten Bereiche der struct wifi_config undefiniert. Vielleicht gibt es auch eine compileranweisung, die dies erledigt, aber so ist es sicher. Also vor dem ersten strncpy... ein memset... wie folgt einfügen:
1 | wifi_config_t wifi_config; |
2 | memset(&wifi_config, 0, sizeof(wifi_config)); // insert this line to set memmory of struct to 0 |
3 | strncpy((char*)wifi_config.sta.ssid, CONFIG_WIFI_SSID, sizeof(wifi_config.sta.ssid)); |
4 | strncpy((char*)wifi_config.sta.password, CONFIG_WIFI_PASSWORD, sizeof(wifi_config.sta.password)); |
5 | wifi_config.sta.bssid_set = false; |
Ansonsten eine tolle Idee und Umsetzung. VG Didi
Hallo Didi, Dietrich W. schrieb: > In der Datei main.cpp, function initialize_wifi(void) wird die > structwifi_config_t wifi_config; nicht korrekt initialisiert. Danke, das habe ich bei der Umstellung von C nach C++ übersehen. Das sollte jetzt korrigiert sein. Gruß, Christian
Dietrich W. schrieb: > Vielleicht gibt es auch eine compileranweisung, die dies erledigt, Wenn das eine automatische Variable ist (d.h. funktionslokal auf dem Stack), dann wird sie nur dann initialisiert, wenn Du das explizit hinschreibst. Das ist in C und C++ gleichermaßen der Fall.
Man müsste in dieses Projekt nur noch Audio implementieren, dann wäre es perfekt.
Hallo Christian, kannst Du mal schauen?! dein Projekt compiliert nicht unter Ubuntu 18.04.3 // ESP32IDF v4.1-dev-1086-g93a8603c5 https://hastebin.com/cebiweciro.cs
Hallo, das sieht so aus, als hätte sich die esp-idf API geändert. Da gucke ich am Wochenende nach. Ansonsten sollte es mit einer älteren ESP-IDF-Version funktionieren, wenn du nicht solange warten willst.
Christian T. schrieb: > Hallo, > > das sieht so aus, als hätte sich die esp-idf API geändert. Da gucke ich > am Wochenende nach. Oh, cool ... da warte ich lieber :) Wenn ich den Fehler gefixt bekomme schick ich ein Commit. LG
:
Bearbeitet durch User
Das wäre perfekt ... https://github.com/espressif/esp-who/blob/master/docs/en/get-started/ESP-EYE_Getting_Started_Guide.md
:
Bearbeitet durch User
Jetzt sollte es wieder mit dem aktuellen master vom esp-idf funktionieren. Mir ist noch aufgefallen, dass ich einen großen Main-Stack einstellen musste (16k) damit es startet.
Uhh, mein ESP-WROOM-32 und mein ESP-32S ... stallen :( https://hastebin.com/eqebukekup.sql Was benutzt Du für ein ESP?
:
Bearbeitet durch User
> Was benutzt Du für ein ESP?
Ich hab auch den WROOM-32 (auf dem Board von watterott).
Hast du die Größe des Main-Stacks per menuconfig auf 16kByte gestellt?
Edit: Ich habe jetzt eine sdkconfig.defaults hinzugefügt, die das
automatisch macht, falls man eine neue sdkconfig erstellt.
:
Bearbeitet durch User
Christian T. schrieb: > Hast du die Größe des Main-Stacks per menuconfig auf 16kByte gestellt? So tief war ich noch nie im Keller :) (Top) → Component config → Common ESP-related Funzt, danke!!!
Christian, kannst Du nochmal bitte schauen > https://hastebin.com/odecavovib.md Was ich nicht verstehe ist: I (4861) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states> >][transition] waiting_for_auth_reply -> registered vs. I (116581) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states> >][process_event] ev_401_unauthorized
> Was ich nicht verstehe ist: > > I (4861) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, > sip_states> >][transition] waiting_for_auth_reply -> registered > Das ist von der Anmeldung. Das scheint geklappt zu haben. Danach kannst du den ESP anrufen um das zu testen. Siehe auch da https://tools.ietf.org/html/rfc3665#section-2.1 > vs. > > I (116581) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, > sip_states> >][process_event] ev_401_unauthorized Das ist vom Anruf, der vom ESP ausgelöst wird. Das ist anscheinend normal. Bei der Fritzbox passiert das auch. Das INVITE wird wohl immer mit einem 401 beantwortet. Daraufhin wird nochmal ein INVITE mit den Anmeldedaten geschickt, das sollte dann klappen. Im Log ist das aber leider nicht enthalten. Mit sipgate hab ich auch noch nicht getestet.
Christian T. schrieb: > du den ESP anrufen um das zu testen. I (173183) SipClient: Parsing the packet ok, reply code=9 I (173183) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states> >][process_event] ev_rx_invite Witzig, das geht :D
:
Bearbeitet durch User
Hallo, ich bin ziemlich unbeleckt in sachen Ardiono IDE und ESP Ich habe folgede konstellation... ESP32 TTGO mit Camera die jetzt endlich läuft(nachdem ich den Sketch auf meine Kamera angepasst habe).Jetzt bekomme schon mal auf meinem FritzFon ein Bild hochgeladen. Nun möchte ich per SIP Call mit 2 Taster auf GPIO 2 und 4 zwei Gruppen rufen. kann mir jemand dabei helfen meinen sketch mit einem SIP sketch zu vereinen? Ich habe leider überhaupt keine Ahnung wie ich anfangen muss.
Martin schrieb: > Wie schaut es denn mit der Überlegung auch noch audio in beide > richtungen zu Implementieren? > > Eigentlich sollte das auch simpel sein; Micro; => 4kHz samplen mit nem > Timer und 8 bit? das ganze uLaw codieren, was ja quasi kreatives PCM > ist? und die andere Richtung entweder einen zusätzlichen DA wandler per > i2s oder auch in weichware aufm PWM pin? > Theoretisch sollte das machbar sein oder? Genau das brauche ich. Hat sich hier zufällig was bewegt? Die Elektronikseite bekomme ich locker hin (will den ESP dann am Siedle-Haustelefon betreiben und die Dinger liefern sehr wenig Strom). Aber programmieren war noch nie meins.
Habe Probleme mit der sip-Anmeldung an der Fritzox 7590. Hat jemand eine Idee? I (1192) main: Event: WIFI_EVENT 4 I (1272) wifi:AP's beacon interval = 102400 us, DTIM period = 2 I (2192) esp_netif_handlers: sta ip: 192.168.188.74, mask: 255.255.255.0, gw: 192.168.188.1 I (2192) main: Event: IP_EVENT 0 I (2192) main: got ip:192.168.188.74 I (2192) WebServer: Starting server on port: '80' I (2202) UdpSocket: Doing DNS lookup for host=192.168.179.1 port=7078 I (2212) UdpSocket: DNS lookup succeeded. IP=192.168.179.1 I (2212) UdpSocket: ... opened socket 53 I (2222) UdpSocket: Doing DNS lookup for host=192.168.179.1 port=5060 I (2232) UdpSocket: DNS lookup succeeded. IP=192.168.179.1 I (2232) UdpSocket: ... opened socket 54 I (2242) main: SIP client initialized successfully I (2242) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][process_event] ev_start I (2252) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][transition] sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >::operator()() const::idle -> waiting_for_auth_reply I (2282) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][action] sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >::operator()() const::<lambda(SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> >&, const auto:5&)> ev_start I (7342) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][process_event] ev_reply_timeout I (7342) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][transition] waiting_for_auth_reply -> waiting_for_auth_reply I (7362) SipSm: [sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >][action] sip_states<SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> > >::operator()() const::<lambda(SipClientInt<AsioUdpClient, MbedtlsMd5, sip_states, SipClient<AsioUdpClient, MbedtlsMd5> >&, const auto:5&)> ev_reply_timeout
Es sieht so aus, als wäre die IP-Adresse der Fritzbox falsch. Wenn du die Fritzbox auch als Router verwendest, kannst du das per "menuconfig" vor dem Compilieren der Firmware einstellen, siehe https://github.com/chrta/sip_call/blob/main/main/Kconfig.projbuild#L54
Danke! Hatte fast zeitgleich mit der Antwort mal probiert die SIP IP-Adresse auf manuell zu setzen. Damit läuft es, obwohl die Adresse identisch zur DHCP Standard Gateway Adresse ist. Der Beschreibung nach hätte die IP-Adresse ja für SIP übernommen werden müssen, oder?
Laut deinem Log ist die IP Adresse deiner Fritzbox 192.168.188.1. Der Esp32 versucht sich aber mit 192.168.179.1 zu verbinden. Das ist die Default-Adresse für die Fixe IP-Adresskonfiguration. Entweder du hattest noch SIP_SERVER_FIXED_IP aktiviert, oder es ist ein Bug bei dem Übernehmen der Adresse in meinem Code.
Gerade noch mal verifiziert. Nach Rückstellung auf automatische Übernahme vom DHCP und vorheriger Umstellung der festen IP, war der Fehler reproduzierbar wieder da.
Mit der "Intercom" Funktionalität scheint es nie weitergegangen zu sein? Schade
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.