[Re-devel] Playing with re as a SIP library
andrey.gursky at e-mail.ua
Sat Jul 29 01:51:12 CEST 2017
On 2017-07-26 09:10, Lorenzo Miniero wrote:
> 2017-07-26 2:17 GMT+02:00 Andrey Gursky <andrey.gursky at e-mail.ua>:
>> Hi Lorenzo,
>> On 2017-07-25 12:20, Lorenzo Miniero wrote:
>>> Hi all,
>>> I made a lot of progress with the re-based SIP plugin in Janus,
>>> and I
>>> really enjoyed working with the library so far! I still am
>>> encountering some issues with it, though, and so would like to try
>>> sort them out before merging the code in master. I'd really
>>> any hint you guys could give me on any of the following points: 1.
>>> 3. are probably not really that important, but 2. and 4. seem to
>>> and so far I've bashed my head trying to get those working without
>>> * We have a configuration property called
>>> keepalive_interval in the
>>> Sofia plugin, which basically triggers some keepalives via OPTIONS
>>> requests on a regular basis when registering. By looking at the
>>> it seems like re should do this automatically, so we probably
>>> need this. Can you confirm that's the case?
>>> * I still found no way to tell re I'm behind a NAT,
>>> though... the
>>> Contact header seems to always use a private address. Is there any
>>> to tell re to use a STUN request for the Contact header, or a way
>>> use rport when registering?
>> this seems to be similar to what Niall was asking a month ago:
>> and exactly what I described in a reply:
> Hi Andrey,
> sorry, I should have checked the history... I remember reading Niall's
> post at the time (the last time I played with this was about a month
> ago indeed) but not your reply, which I must have missed, apologies.
> Thanks for the clarification! Your example seems to be in line with
> what I experienced, when I tried to REGISTER to an external server
> from behind a NAT. So you're saying that at the moment this is broken,
> and a patch would be needed to address the proper behaviour you
I believe so. And I'm really wondering how people are using baresip?
Only for outgoing calls? Or there are no home/mobile users at all?
>> * With the other plugin we also have the possibility to do
>> HA1-based authentication (the password is already hashed in
>> by the client). Is this possible with re? This is something I don't
>> really care about, as I was never able to use it myself, but not
>> if there are people out there using it instead.
>> * What's the proper way to cancel a request? To make a
>> example, with the current implementation, if I do a REGISTER to
>> I don't get an answer, re automatically retries for about a minute
>> before giving up. If I have my user exit, I still see the retries
>> going on, although I do a mem_deref on the struct sipreg instance,
>> after a few seconds even a sip_close on the struct sip instance the
>> register client is associated with (forcing the transactions to
>> interrupt). Eventually this results in a callback being invoked with
>> an argument pointer that is now invalid (user long gone), and can at
>> times result in a crash. Anything I'm forgetting to do here?
>> Thanks in advance for any help you'll be able to give me!
>> 2017-03-17 19:10 GMT+01:00 Lorenzo Mangani
>> <lorenzo.mangani at gmail.com>:
>> Great progress, Lorenzo!
>> Is Albert still subscribed to the mailing list? :)
>> Lorenzo Mangani
>> _Managing Director and Core Dev_
>> QXIP BV - Capture Engineering
>> Amsterdam, The Netherlands
>> Desk: +31 20 8080468  / +1 202-632-7227  
>> Mobile: +31 6 4603-2730 
>> Email: info at qxip.net
>> Find our more about HOMER, PCAPTURE, CAPTAGENT and all our Services
>> and Solutions at http://qxip.net
>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>> attachments, is for the sole use of the intended recipient(s) and
>> may contain confidential or legally privileged information. Any
>> unauthorized review, use, disclosure or distribution is prohibited.
>> If you are not the intended recipient, please contact the sender by
>> reply e-mail and destroy all copies of this original message.
>> On Fri, Mar 17, 2017 at 6:26 PM, Lorenzo Miniero
>> <lminiero at gmail.com> wrote:
>> While I think I fixed 3. (I was missing a call to poll_method_set),
>> I'm still encountering issues I can't seem to be able to overcome...
>> specifically, it crashes in the memory management code whenever I
>> try to register:
>> which surprises me as I think I'm doing that part right. Anyway, in
>> case anybody wants to see how the effort looks like and play with
>> it, and maybe even help move it forward, I've published a first
>> version of the plugin as a pull request on the Janus repo:
>> https://github.com/meetecho/janus-gateway/pull/823  
>> At this point, any nudge in the right direction may help me make a
>> step closer to fix this.
>> 2017-03-13 11:09 GMT+01:00 Lorenzo Miniero <lminiero at gmail.com>:
>> 2017-03-06 18:01 GMT+01:00 Lorenzo Miniero <lminiero at gmail.com>:
>> Hi all,
>> I'm trying to use re as a library to implement a SIP stack.
>> Specifically, the purpose it to add a new server-side plugin to my
>> open source WebRTC server, Janus. I already have a SIP plugin, which
>> is based on Sofia, but I wanted to provide a re-based alternative as
>> well. The idea, just as with the Sofia-based plugin, is to allow
>> WebRTC users to rely on a server-side SIP stack to interact with SIP
>> infrastructures, while keeping the web communication much lighter
>> and high level (e.g., JSON messages to start a call or accept one).
>> This works fine, but some have expressed concerns on Sofia as a
>> stack, which led me to investigate re as a possible alternative (a
>> plugin which does no SIP at all internally is also in the works, but
>> that's a separate matter).
>> That said, I'm having a bit of a hard time to figure out the best
>> way to approach this. I started working on this plugin, studying
>> some examples I found around and so on, but su far with pretty
>> scarce results. I believe I may be misunderstanding some concepts in
>> the library, and so I thought I'd write here to ask for directions,
>> in order to make sure I'm not on the wrong path.
>> * As anticipated, this plugin acts as a SIP client on behalf of a
>> WebRTC user. This means that if you get multiple WebRTC users, you
>> handle multiple SIP clients internally, each with their own
>> REGISTERs, INVITEs, and so on. Looking at the library this doesn't
>> look like an issue, as the callbacks do have opaque pointers that
>> will allow me to reference the right session. The question though
>> is: do I use a single, static 'struct sip' allocated instance for
>> them all, or does each client need its own? My guess is that it's
>> the former, considering that the 'exit_handler' for a sip_alloc is
>> supposed to be a re_cancel() that exits the whole loop, but this
>> isn't completely clear to me.
>> * In the same spirit as the question above, would I need a global
>> sipsess_listen or one per client instead? A shared one would allow
>> to re-use the same local port for many different sessions, but I'm
>> not sure if this is the way the library is supposed to work
>> (especially if TCP is used, for instance) and so I guess this might
>> actually be per-user instead. As a side note, would a sipsess_listen
>> only be needed in case you register and so want to be able to handle
>> incoming call, or is it a more general transport-related setting to
>> allow any incoming SIP message (e.g., responses, acks) to be
>> * I have troubles understanding how the event loop works... as a
>> test, I'm creating a single SIP stack at the plugin startup, and
>> then, in a dedicated thread, I call re_main() to start the event
>> loop (it's a thread since, as anticipated, this is not the main
>> application but a plugin part of something larger). Anyway, when I
>> try to send a REGISTER as part of user-provided input, nothing seems
>> to happen: the call to the method succeeds, but no SIP message is
>> sent. My guess is that I'm doing something wrong with the event
>> loop, as when I call re_cancel() in my plugin shutdown procedure,
>> for instance, that doesn't break the event loop either, meaning the
>> call to re_main() done in the thread is never interrupted, and is
>> possibly stuck somewhere. What may I be doing wrong there?
>> That's all, for now. I'm sure that, moving on, I'll encounter other
>> problems I might ask some directions about, but at the moment this
>> are the major roadblocks I met, which are actually preventing me
>> from moving on as they're related to fundamental aspects of the
>> library. Any feedback would be greatly appreciated!
>> Nothing..? Any help even just on point 3. would really help, as I
>> believe I might figure out the rest when I at least manage to get
>> the ball rolling.
>> Re-devel mailing list
>> Re-devel at lists.creytiv.com
>> http://lists.creytiv.com/mailman/listinfo/re-devel  
>>  tel:+31%2020%20808%200468
>>  tel:(202)%20632-7227
>>  https://github.com/meetecho/janus-gateway/pull/823 
>>  http://lists.creytiv.com/mailman/listinfo/re-devel 
>> Re-devel mailing list
>> Re-devel at lists.creytiv.com
>> http://lists.creytiv.com/mailman/listinfo/re-devel 
>  http://lists.creytiv.com/pipermail/re-devel/2017-June/001243.html
>  http://lists.creytiv.com/pipermail/re-devel/2017-June/001244.html
>  tel:202-632-7227
>  tel:%2B31%206%204603-2730
>  https://gist.github.com/lminiero/acf570362c8460bb8cd09a28b62f8488
>  https://github.com/meetecho/janus-gateway/pull/823
>  http://lists.creytiv.com/mailman/listinfo/re-devel
Re-devel mailing list
Re-devel at lists.creytiv.com
More information about the Re-devel