Future of the project?

[vaizki]

Hi everyone, especially @ovv and @vodik ..

I am using aiosip in a couple of projects but from a private fork at this time because the PRs for even simple fixes for obviously broken functionality don't make it into this repo. I think these changes would benefit the project and there are several other major PRs / issues which have been hanging around for a long time.

To me it seems like we have maybe 5-10 users of the project at this time and no active development. Probably everyone else has some private forks also where the things they need work and let's not touch it.

I do not personally have experience in maintaining GitHub repos (or TBH even the time to do it) but I think this project deserves some kind of ongoing maintenance at least. Currently the project is a bit "uncontributable" with the CI broken, major changes (ursine etc) not integrated and issues / PRs not progressing at all. At the same time it's pretty much the only asyncio python SIP library that I've found.

So discussion... is there love for the project still around? Anyone still using aiosip? And what next? Volunteers?

[ovv]

Hello @vaizki

I'm no longer working for Eyepea and do not have any personal interest in aiosip. I doubt Eyepea have the time and the will to maintain it at the moment.

I agree that it could use some work and will benefit for some improvements. If someone is interested into taking ownership, I could try reaching out to Eyepea asking for a project transfer.

[MartyTremblay]

Adding my two cents... I'd love to see someone take this project under their care. I've been looking far and wide for a native Python library to replace pjsua from my project and aiosip seems to be our best bet. I'm not much of a Python developer, especially for something low-level such as this, so I wouldn't be a good steward of it.

[nicolaipre]

@MartyTremblay that makes us two. I am looking for a pure Python SIP implementation that supports audio streaming to buffers (and not only capture/playback devices), and this seems to be the best I have come across so far, used together with aiortp by @vodik

I have also looked rtclite by theintencity who has implemented the RFCs, but there is no support for Python3 here so I have attempted to port it to Python 3, but ran into some issues with gevent.

I feel this project is more clean, and I like the support for AsyncIO.

If anyone is interested in further developing this project, drop me a message and we can work on it together.

[vaizki]

I am still using aiosip actively but I have made small fixes only to my own fork right now. I don't have time to learn how to steward projects on github and never done it so it would be great if someone who knows the ropes is interested in keeping this alive?

[stalkerg]

Probably I will make fork but I don't know what name should I use.

[MartyTremblay]

@stalkerg, what about PurePythonSIP ?

[stalkerg]

I added a timeout error for wait_for_terminate into my fork.
https://github.com/stalkerg/aiosip

[nicolaipre]

I added a timeout error for wait_for_terminate into my fork.
https://github.com/stalkerg/aiosip

Do you plan on implementing aiortp into your fork?

[stalkerg]

Do you plan on implementing aiortp into your fork?

good question... currently I am using RTP implementation (without network level) from https://github.com/aiortc/aiortc project and it works perfectly. (at least because that lib support normal work with SDP)
But if you not needed WebRTC the aiortc will be overkill.
Unfortunately, aiosip and aiortp designed not so good and have many issues.
And yes, we need a library for SDP... without SDP the SIP+RTP has no sense. Also, you need somehow implement codec matching... some helpers exist in aiortc but it deeply integrated into the project.

Basically, in the ideal world, it will be good to separate aiortc into a few separate and independent libraries (same as aioice) and reuse it in the new solution. But I think @jlaine will be against.

[nicolaipre]

Do you plan on implementing aiortp into your fork?

good question... currently I am using RTP implementation (without network level) from https://github.com/aiortc/aiortc project and it works perfectly. (at least because that lib support normal work with SDP)
But if you not needed WebRTC the aiortc will be overkill.
Unfortunately, aiosip and aiortp designed not so good and have many issues.
And yes, we need a library for SDP... without SDP the SIP+RTP has no sense. Also, you need somehow implement codec matching... some helpers exist in aiortc but it deeply integrated into the project.

Basically, in the ideal world, it will be good to separate aiortc into a few separate and independent libraries (same as aioice) and reuse it in the new solution. But I think @jlaine will be against.

I see! Thank you for the rapid response. I have been looking for a non-WebRTC implementation for quite some time, but I am still stuck with pjsip/pjsua it seems...

[jlaine]

For what it's worth, for work I needed a minimal SIP stack with support for media codecs, so (no surprise) I built one which leverages aiortc's code, including ICE / DTLS / SRTP.

One key takeaway was that writing the parser / serialization code for SIP is quite straightforward if you leverage werkzeug's many HTTP parsing utilities. Specifically I made use of:

from werkzeug.datastructures import Headers, WWWAuthenticate
from werkzeug.http import (
    parse_authorization_header,
    parse_options_header,
    parse_www_authenticate_header,
    quote_header_value,
)

EDIT: I'm already over-extended in terms of opensource projects so I don't plan to maintain yet another project

[stalkerg]

EDIT: I'm already over-extended in terms of opensource projects so I don't plan to maintain yet another project

The main question here is it possible to separate aiortc into:
aiortc
sdplib
rtplib
abstract rtpcodec
implementation rtpcodec

[vovkd]

I'm on it too

Do you plan on implementing aiortp into your fork?

good question... currently I am using RTP implementation (without network level) from https://github.com/aiortc/aiortc project and it works perfectly. (at least because that lib support normal work with SDP)
But if you not needed WebRTC the aiortc will be overkill.
Unfortunately, aiosip and aiortp designed not so good and have many issues.
And yes, we need a library for SDP... without SDP the SIP+RTP has no sense. Also, you need somehow implement codec matching... some helpers exist in aiortc but it deeply integrated into the project.

Basically, in the ideal world, it will be good to separate aiortc into a few separate and independent libraries (same as aioice) and reuse it in the new solution. But I think @jlaine will be against.

I need to make calls and process incoming audio frames on the fly. For now i use PJSIP + pjsua, but it is a reall pain to work with So if i want to go away from pjsua, i need a lucky combination of three: aiosip, aiortp, aiortc?

[stalkerg]

@vovkd if you need calls by SIP when yes... aiosip, aiortp, aiortc, and some holly tape.
I have maybe 10 different monkey patching for all these libs and some re-implementations to work with.
Unfortunately, I can't show you an example because it's a commercial code. But you can check my aiosip fork https://github.com/stalkerg/aiosip at least it's working and have some important modifications.

[vovkd]

@vovkd if you need calls by SIP when yes... aiosip, aiortp, aiortc, and some holly tape.
I have maybe 10 different monkey patching for all these libs and some re-implementations to work with.
Unfortunately, I can't show you an example because it's a commercial code. But you can check my aiosip fork https://github.com/stalkerg/aiosip at least it's working and have some important modifications.

i've done it with PJSIP's pjsua python binding, but would like to go away from it. It's a hell to work with PJSIP/pjsua. I'll look at your fork, thanks.

[stalkerg]

i've done it with PJSIP's pjsua python binding, but would like to go away from it. It's a hell to work with PJSIP/pjsua. I'll look at your fork, thanks.

I think you can but at the same time, you probably should invest into the fork of this lib (probably my).

[rmedaer]

Hi team,

Raphael speaking, lead-dev at Eyepea/ALLOcloud. Bad news here; we won't maintain anymore this library. Indeed we decided to move away from custom SIP stack in favour of pjsip stack.

i've done it with PJSIP's pjsua python binding, but would like to go away from it. It's a hell to work with PJSIP/pjsua

Indeed, it might be complex to deal with this python binding in early stage of your project. However this stack has much more benefits:

• well maintained
• security
• features
• ...

About @ovv comment:

I doubt Eyepea have the time and the will to maintain it at the moment.

Indeed we don't have time to manage this custom (re)implementation of SIP stack and we certainly don't want to rewrite the wheel. Although, we do have time to share with you the work we did to get pjsip/pjsua Python binding "asynchronous friendly". This is the good news! This open-sourcing is planned for 2021 with @hlobit @nicolasturcksin and @negletios.

Kind regards,

[stalkerg]

Indeed we decided to move away from custom SIP stack in favour of pjsip stack.

For me, it's super overkill because I need only a primitive part of SIP only without any audio/video processing. Even aiosip it's probably too much. Also, because aiosip designed like OOP lib it's difficult to maintain for my cases.
I thinking about simplifying the current aiosip.

Indeed we don't have time to manage this custom (re)implementation of SIP stack and we certainly don't want to rewrite the wheel.

What about the name? aiosip it's really good for what we doing here.

[vovkd]

Hi team,

Raphael speaking, lead-dev at Eyepea/ALLOcloud. Bad news here; we won't maintain anymore this library. Indeed we decided to move away from custom SIP stack in favour of pjsip stack.

i've done it with PJSIP's pjsua python binding, but would like to go away from it. It's a hell to work with PJSIP/pjsua

Indeed, it might be complex to deal with this python binding in early stage of your project. However this stack has much more benefits:

• well maintained
• security
• features
• ...

About @ovv comment:

I doubt Eyepea have the time and the will to maintain it at the moment.

Indeed we don't have time to manage this custom (re)implementation of SIP stack and we certainly don't want to rewrite the wheel. Although, we do have time to share with you the work we did to get pjsip/pjsua Python binding "asynchronous friendly". This is the good news! This open-sourcing is planned for 2021 with @hlobit @nicolasturcksin and @negletios.

Kind regards,

it's a good news, @rmedaer ! Can your binding access received by PJSIP RTP packets? Or maybe you could point me in the right direction? What is the right way to pass incoming RTP packets to python?

I've choosed PJSIP exactly with the same thoughts in mind and successfully built a prototype, but i needed to process rtp packets inside python app and this is what caused me most problems. Well, i've wrote a custom PJSIP port that calls callback from python and it's works, but not in the Kubernets (i think there is some racing problems that arise when running inside Kubernetes). And we are using it heavily. This is were i stopped for now

[vovkd]

@MartyTremblay there is rtclite and snl - pure python sip stack implementation, but both looks like abandoned projects. I've succeed to establish calls with both. rtclite more feature rich and snl is more simple SIP-stack implementation

[oldani]

Indeed we don't have time to manage this custom (re)implementation of SIP stack and we certainly don't want to rewrite the wheel. Although, we do have time to share with you the work we did to get pjsip/pjsua Python binding "asynchronous friendly". This is the good news! This open-sourcing is planned for 2021 with @hlobit @nicolasturcksin and @negletios.

Thanks for the update, Is there any date we may expect this to come out?

[malarinv]

Indeed we don't have time to manage this custom (re)implementation of SIP stack and we certainly don't want to rewrite the wheel. Although, we do have time to share with you the work we did to get pjsip/pjsua Python binding "asynchronous friendly". This is the good news! This open-sourcing is planned for 2021 with @hlobit @nicolasturcksin and @negletios.

Thanks for the update, Is there any date we may expect this to come out?

I am looking forward to it as well! 😃 @rmedaer

[stalkerg]

Maybe in the next half of the year, I can back to this project.

[oktavlachs]

Hi @rmedaer @hlobit @nicolasturcksin @negletios.

Do you have an update on your "asynchronous friendly" pjsip/pjsua Python binding? Can it be found somewhere here open source?

Would be great to get an update. Thank you! :)

[stalkerg]

@oktavlachs seems like not so many invests in such areas, especially for Python. I know how it should be designed after all but it's literally a full-time job at least for 4-6 months.
PS it's also should support trio not only asyncio

[negletios]

@oktavlachs we don't have any update yet since many people involved in this project moved to other areas / companies etc.

@stalkerg the trio support is debatable and I don't think it's something we have interested in.

I would like to do an implementation at some point but as @stalkerg said it's literally a full-time job and we are currently very busy

[negletios]

BTW, there is a very basic sip user agent implementation that we have but it's not documented and works for specific cases. @hlobit wanna give some feedback? maybe we can expose this to another repository and start working on this ?

[nicolaipre]

FWIW; there is also another project that seems quite good: https://github.com/tayler6000/pyVoIP

If you plan on separating it into a new project, maybe one could use parts from both aiosip and pyvoip and make a new asynchronous framework based on both?

I have not tried pyVOIP myself but it looks far better than using the pjsip/pjsua bindings I have used before.