SDP is probably out of scope

[vodik]

Honestly, we probably don't want to integrate SDP support.

For QA purposes, I've written and been using our aiortp library. It works surprisingly well (could probably also function as a decent IVR). I've also used and experimented with gstreamer, who's API also glues very nicely into our API.

So maybe we don't have to worry about this.

[codecov-io]

Codecov Report

Merging #99 into master will increase coverage by 4.93%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #99      +/-   ##
==========================================
+ Coverage   70.42%   75.35%   +4.93%     
==========================================
  Files          15       15              
  Lines        1562     1834     +272     
  Branches      267      381     +114     
==========================================
+ Hits         1100     1382     +282     
+ Misses        343      327      -16     
- Partials      119      125       +6

Impacted Files	Coverage Δ
aiosip/message.py	78.57% <0%> (+0.95%)	:arrow_up:
aiosip/contact.py	81.33% <0%> (+2.76%)	:arrow_up:
aiosip/transaction.py	62.75% <0%> (+4.82%)	:arrow_up:
aiosip/application.py	76.58% <0%> (+5.99%)	:arrow_up:
aiosip/peers.py	77.74% <0%> (+6.7%)	:arrow_up:
aiosip/dialog.py	83.6% <0%> (+10.1%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 70f91af...5942c09. Read the comment docs.

[vodik]

@codecov-io I don't understand how you work...

[ludovic-gasc]

Hi @vodik,

For me, I have no problems to have an integration of aiortp in aiosip, or have an "upper" project that uses aiosip and aiortp to build a softphone.

Instead of to remove SDP support, I would replace it that with a link to aiortp project. Ok for you ?

[vodik]

I think an upper project makes most sense.

Internally we're playing with a few media engines actually (including non-python engines), at the moment, and I don't really there's a reason to pick one directly here. I really don't think there's a good one-size-fits-all solution to it.

I'm playing more and more with trying to deploy aiosip and media support in a micro-services setup and, in those environments, I think it makes a lot of sense to schedule media and signalling on different machines with different scaling policies. In fact, it might even make sense to schedule different kinds of audio different (ivr vs. straight rtp proxying vs. muxing a conference call)

How about, instead, we document how media can be integrated and can use aiortp as an example as its very simple?

[ludovic-gasc]

I really don't think there's a good one-size-fits-all solution to it.

If one moment you publish a blog post or something similar, I'm interested in to know the technical details.

I think it makes a lot of sense to schedule media and signalling on different machines with different scaling policies. In fact, it might even make sense to schedule different kinds of audio different (ivr vs. straight rtp proxying vs. muxing a conference call)

What are the advantages you see to do that ?

How about, instead, we document how media can be integrated and can use aiortp as an example as its very simple?

An upper end-user tool l would be more user friendly, however it would be already awesome to have an example of aiosip+aiortp to play together.

[vodik]

Yeah, I think I probably should write something. I've actually been drafting a blog.

I have a lot to say on this topic, all from second hand experience with how FreeSWITCH and Asterisk works and where the pain points are, but I think fundamentally, especially in a cloud environment, you want to split signalling from media.

Apologies ahead of time if its a hard to follow stream of consciousness. I haven't quite formulated concrete thoughts on everything yet, its just a pile of ideas and concerns.

And note, I don't have empirical evidence for anything I'm about to put forward, and its an area I want to explore. But where I've seen problems with scaling Asterisk or reasoning about FreeSWITCH's behaviour is that most issues come from the compromise of trying to put everything in an all-in-one solution.

Scheduling

I mean, at the simplest level, media and signalling have different latency requirements. Media is (soft) realtime. Signalling have tolerate higher latency and might actually benefit being tuned for throughout. But you can't really tune an operating system's network stack for both. Its either lower latency with lower throughout or higher latency with higher throughput.

Scaling and fail over

Both protocols have different requirements here too. So long as signalling state is persistent (I've been meaning to toy with tossing aiosip state in a database - or even playing with Kafka), any new node should be able to take over an existing dialog without skipping a beat. All that matters is that Contact and Via headers stay accurate.

This means, in theory, I think it should be really easy to make SIP side of a cloud service highly elastic.

But media is different. You can't just fail over or scale out - it has to be orchestrated at the signalling layer with re-INVITEs.

Load

Signalling tasks should be very low load and low risk (if state is tracked properly) so signalling nodes should be safe to heavily saturate.

Media, on the other hand, has two problems: one is that an outage is more difficult to handle as per above - so one might want nodes to be more thinly allocated instead so any problems affect as few customers as possible.

Also load characteristics can vary widely depending on features. Proxying media isn't too demanding, but adding transcoding can be. Or muxing a conference call between many different RTP streams. In fact, it might even make sense to make special purpose nodes for these various tasks to optimize them as much as possible - or do it in a different language.

[ludovic-gasc]

Your point of view is very interesting. I'm OK to remove SDP support in the todo-list and be my guest to push an integration example with aiosip and external SDP library.

[moises-silva]

I have a lot to say on this topic, all from second hand experience with how FreeSWITCH and Asterisk works and where the pain points are, but I think fundamentally, especially in a cloud environment, you want to split signalling from media.

This has been the case for decades pretty much elsewhere that I know of before Asterisk/FreeSWITCH architectures (see things as old as Megaco/H.248 used in combination with SS7/SIGTRAN).

I've never asked FS/Asterisk creators but I can guess the orchestration complexity wasn't justified by the gains for the target users ('just' a PBX initially). Even today in large cloud environments using Asterisk/FreeSWITCH they often are used just as a media layer that talk a bit of SIP to initiate media sessions. The bulk of scalability for signaling is left with opensips/kamailio (or other SIP proxies) and then scaling horizontally for media servers/gateways (Asterisk/FreeSWITCH).