Add "siprec" to SIPExtensions

[kimwinther]

I've been using sipsocery to build a siprec server (SRS) and have it working now; my siprec client (SRC) adds a "Require: siprec" header, so I did have to add "siprec" as a known SIP extension (in SIPConstants.cs) in order for the SIPREC invites to be processed by the parser.

Is there anything that speaks against making the siprec extension a permanently know extension (included in master)?

[sipsorcery]

Is there anything that speaks against making the siprec extension a permanently know extension (included in master)?

No, there shouldn't be a problem.

There are already lots of extensions. As long as any new ones don't break existing behaviour it should be fine.

[kimwinther]

great - its a simple addition - whats the procedure - new branch and a pull request?
SIPConstants.cs.diff.txt

[sipsorcery]

Yes, a PR is the preferred approach.

[jbieniusiew]

Hi All,
I'm working on SIPREC SRS implementation based on SipSorcery.
From what I gathered so far, I need to do following:

• SDP.cs needs to be extended, so it can parse SDP and XML parts of SIPREC INVITE (which Content-Type is multipart/mixed)
• "a=label" SDP attributes needs to be handled in SDP.cs and propagated with the SDP answer.
• Multiple VoIPMediaSession needs to be launched, for each m=audio element read from SDP

@kimwinther could you please share your experiences related to the SRS? E.g.
Were you able to build fully functional recording server?
What was SRC is your setup?
Did you check how many calls it can handle at the same time?

BR
Jacek

[kimwinther]

Hi Jacek,

Yes, I did build a fully functional SRS and it is in use with an Avaya SBCE as SRC, handling about 700 simultaneous calls.
On a Mac Mini M1 it can easily handle 1000 simul. calls (2000 RTP streams); the heavy part is setting up the calls (processing the SIP INVITE and XML payload, setting up RTP handlers, etc), so you will have a lower "new calls per second" limit.

Once a call is setup, sipsorcery does not add much overhead, so it really depends on what you need the RTP for. In my case, we forward RTP to another server(pool) for "speech to text" processing and forwarding-only is very lightweight.

When doing load tests, be aware that writing debug logs is an expensive affair :-)

Best regards

Kim

[jbieniusiew]

Hi Kim,
Sounds great. Thank you for sharing your observations.
Best Regards
Jacek

[vangarp]

@kimwinther @jbieniusiew are any of your implementations of siprec server based on sipsorcery available for reference? Will save me some time reimplementing if you are willing to share