esp32phone as a submodule

[sosaucily]

Hi! This is a cool project, I've seen enough people chatting about something like this online, so I'm happy to see you took it on. I'm interested in using this, and helping out a bit along the way as I can as well.

Would you be open to organizing this in such a way that the esp32phone / sipphone module could itself be a stand-along submodule that can be imported into a project? Then there would be a project like this, which included all the code to run and test the esp32baresip phone (an example of how to use it), and another module that people can actually import directly.

Thanks!

[fAuernigg]

Thanks for your feedback. I can try to make a library with an interface compatible with esp-idf out of this project including an example/demo.
Is this what you mean with submodule?

What do you mean with import? Do you mean import into arduino ide?
My approach was to build it standalone (easiest way with the included docker definition) . Anyhow I'm using arduino libraries via "arduino-esp32" because of it's good esp abstraction layer. A library for arduino ide would be possible of course.

[sosaucily]

Well now to use the important files I would probably copy sipphone.cpp over into my project, along with a few other files you wrote. I would also need to import the various submodules you need, set to the right branch, etc. So a module with an interface for instantiating and using a sipphone from other projects, and being able to cleanly do updates to it over time, etc. So if it was itself a submodule that would be upgraded (same we we upgrade ESP-IDF sometimes) would be great.

At least, I think this could make sense. I don't use ESP-Adruino in my project, so it's been taking me some time to get everything working together correctly. So I may not be aware of the best way to do some of these things.

[fAuernigg]

Ok now I understand your way of integration. A git submodule inside your project makes sense and would be integrated into your esp-idf project as a component having a defined interface in a sip phone header file. I will add such project soon.

[sosaucily]

Awesome! Espressif provides a sip client but it's closed-source and doesn't offer the same feature set of baresip 👍

[sosaucily]

Btw, do you think the custom branches by cspiel1 (esp32 branches for re and baresip) will get PR'd into the original repos?

[cspiel1]

On Mon 02.12.19 02:32, Jesse Smith wrote: Btw, do you think the custom branches by cspiel1 (esp32 branches for re and baresip) will get PR'd into the original repos?

These branches are very specific for esp32. They contain these changes compared to mainline: - Avoid reading/writing config from filesystem. An alternative might be to setup a SPIFFS. So maybe this changes could be omitted. - Renames some functions in order to avoid name conflicts with other components. In esp32 all included components are built and linked together to one large image app-template.elf. So each symbol has to be unique over all components. - Network specific changes. Most of the used network interface is similar to linux. E.g. socket, bind, ... But a few changes in code are necessary. - The i2s audio driver module is the major impact of the project and already mainline. Except a view lines the code should fit for any freeRTOS system. Maybe there will be added some #ifdefs in the future in order to support different freeRTOS systems. We (mrxa13 and me) will provide soon a repository on github of an esp-idf component for baresip (and one for libre) that contains the esp32 specific changes as patches. regards,c

[sosaucily]

That's awesome, very exciting to hear about this project. Actually seems like, with some legwork, each of the differences you mention on your custom branches can probably be integrated into the main repo. I'm happy to help out with that as best I can, probably once things are moved over to that new repo you mention.

[sosaucily]

Another question, why is this client pegged to v3.2 of the esp-idf? I try to compile with stable AKA release/v3.3 but it throws some errors compiling the SoC module.