[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIP and Golang

From: David Sugar
Subject: Re: SIP and Golang
Date: Wed, 21 Jun 2023 08:32:54 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0

Hi Aymeric,

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 wrote:
Hi David,

I never tried golang and have no knowledge on it.

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 message.


Le mer. 21 juin 2023, 13:28, David Sugar <tychosoft@gmail.com> a écrit :
I am curious if anyone has tried adapting osip2/eXosip2 for use with golang?

I never could find a non-proprietary pure golang sip stack that was ever
completed, or even actively worked on, in years. There are proprietary
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 critical, and
may want code simplicity and safety where your new code is at, and to
leverage other parts of the go ecosystem. There is some simple ability
to embed C code and headers, and call C functions directly into go when
building with cgo (or gccgo), so it seem at least theoretically possible
to consider this.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]