[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIP and Golang
Re: SIP and Golang
Wed, 21 Jun 2023 08:32:54 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0
indeed, I do something similar with my C++ servers, though I can
decompose the event structures and manipulate osip types,
including the lists, directly in C++ code. There is some ability
to import and carry arbitrary C structs thru unsafe pointers in
go, but probably it would be easier to map and translate it into a
pure go application specific event struct and then let the eXosip
event object become free immediately after. Yes, the rest of the
api being essentially int and string should make it pretty easy.
This is why I feel it is doable.
On 6/21/23 08:08, Aymeric Moizard
I never tried golang and have no knowledge on
I wrote many wrapper to other language and 95%
of eXosip2 APIs are pretty straight forward because they only
only have integer and string as parameters.
The only API where complexity is coming is
eXosip_event_wait which returns a structure with pointers on
osip message in it. Those pointers are also structure to many
pointers and list.
I usually implement a few additional C method to
get most common sip headers or elements from sip headers or
the SDP. This is usually enough because the developer usually
don't need the flexibility to access everything from the
curious if anyone has tried adapting osip2/eXosip2 for use
I never could find a non-proprietary pure golang sip stack
that was ever
completed, or even actively worked on, in years. There are
go sip products and stacks, so clearly it is possible to
make one, but
that is a lot of work to do from scratch, and the
community already has
this excellent working code base.
As to why go vs C/C++, go could be nicer for simpler
things for the
upper layer code, where you don't need to be performance
may want code simplicity and safety where your new code is
at, and to
leverage other parts of the go ecosystem. There is some
to embed C code and headers, and call C functions directly
into go when
building with cgo (or gccgo), so it seem at least
to consider this.