[WG-IMS] Scope of IMS in OpenSIPS - RFC

Bogdan-Andrei Iancu bogdan at opensips.org
Tue Dec 5 11:20:23 UTC 2023


Johan,

Hopefully this SHOULD not be a problem. Even now we have the possibility 
to script custom Diameter requests (as set of AVPs), see [1]. And we 
plan some more work here, to better handle the AVPs carrying raw binary 
data. If more will be needed, we will try to address it, for sure :)

[1] 
https://opensips.org/docs/modules/3.4.x/aaa_diameter.html#func_dm_send_request

Regards

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 05.12.2023 13:05, Johan De Clercq wrote:
> Bogdan,
> on the diameter implementation, you need to be very careful here.
> Only a minimal set is required, but bear in mind that every vendor 
> that you interop with has other avp's.
> So the diameter implementation should be easy extendible.
>
> Op di 5 dec 2023 om 11:51 schreef Bogdan-Andrei Iancu 
> <bogdan at opensips.org>:
>
>     Hi Carsten,
>
>     OK, thanks for the heads-up on the HTTP/2, we can have it on the
>     list with a lower priority, maybe subject to future release,
>     depending on the overall volume of work.
>
>     Now, on the AS part, I understand MMTel is a global standard for
>     IMS, but (please baer with me as a rookie in the area) do you have
>     some links to some document to give a quick understanding on the
>     MMTel specs for the AS part? More or less, what I'm trying to
>     understand here is what kind of interface the AS should provide
>     (for routing and service creation) when comes to call handling. On
>     the Sh interface, we just need to be careful with the Diameter
>     implementation (to support all the Sh mappings).
>
>
>     Thanks and regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        https://www.opensips-solutions.com
>        https://www.siphub.com
>
>     On 04.12.2023 17:32, Carsten Bock wrote:
>>     Hi,
>>
>>     (removed users@ - to avoid political discussions)
>>
>>     I would also suggest the following initial scope:
>>     - IMS-Core (P-/I-/S-CSCF). I would not spend too much time on
>>     HTTP/2 for now. In most deployments, Diameter is still the way to
>>     go - even though I've seen more and more offerings of HTTP/2 /in
>>     addition/ to Diameter. In a worst-case scenario, you could always
>>     deploy a DRA to translate from Diameter to HTTP/2.
>>     - A MMTel AS for providing essential services - preferably with a
>>     native Diameter Sh Interface for storing/retrieving supplementary
>>     service settings.
>>
>>     This would allow you to provide essential VoLTE services. If
>>     you're an MVNO, Emergency services are handled by the hosting
>>     MNO, and other services like SRVCC are losing importance as we speak.
>>
>>     Just my initial thoughts,
>>     Carsten
>>
>>
>>     --
>>     Carsten Bock I Chief Technology Innovation Officer & Founder
>>
>>     ng-voice GmbH
>>
>>     Trostbrücke 1 I 20457 Hamburg I Germany
>>     T +49 1511 5942983 I www.ng-voice.com <http://www.ng-voice.com/>
>>
>>     Registry Office at Local Court Hamburg, HRB 120189
>>     Managing Directors: Dr. David Bachmann, Carsten Bock, Quirin
>>     Maderspacher
>>
>>
>>
>>     Am Mi., 29. Nov. 2023 um 16:39 Uhr schrieb Bogdan-Andrei Iancu
>>     <bogdan at opensips.org>:
>>
>>         Hi Giovanni,
>>
>>         Thanks for the feedback here, a valuable one as usual :).
>>
>>         On the HSS, what you are saying aligns with the my own
>>         thoughts - that its functioning logic is somehow outside the
>>         our scope here, but we need to pay attention to the
>>         interfacing (DIAMETER or HTTP2.0).
>>
>>         Now, on the AS side - as I understand, it holds whatever
>>         custom logic the operator may have in routing and proving
>>         services (included VAS's). So to say, I see it as a highly
>>         programmable component. And if so, what we need to provide
>>         here is probably a very high level interface / API to allow
>>         call manipulation in a very abstract way... :-/ ??
>>
>>         Best Regards,
>>
>>         Bogdan-Andrei Iancu
>>
>>         OpenSIPS Founder and Developer
>>            https://www.opensips-solutions.com
>>            https://www.siphub.com
>>
>>         On 29.11.2023 11:11, Giovanni Maruzzelli wrote:
>>>         First of all:
>>>         CONGRATULATIONS to the OpenSIPS community !!!
>>>         (I believe this is the first step of a long and
>>>         satisfying journey)
>>>
>>>         On the topic:
>>>         in addition to the CSCF component, I would like to see
>>>         efforts on the AS (Application Server) component of the IMS
>>>         infrastructure.
>>>
>>>         The AS is probably way the simplest of it all, it will
>>>         probably require the least modifications/additions to OpenSIPS.
>>>
>>>         But I would say AS will be crucial to a lot of people/use cases.
>>>
>>>         While for sure there will be a lot of cases for our
>>>         community to build the voice/video complete IMS
>>>         infrastructure on top of private 5G networks in enterprises
>>>         and public administrations, I see as very much relevant also
>>>         the use case of building infrastructure to provide
>>>         additional third party services to big carriers, and to big
>>>         carriers partners.
>>>
>>>         Also, AS is the correct and manageable way to provide
>>>         additional services even if you build the core IMS
>>>         infrastructure.
>>>
>>>         About HSS: this is the sancta sanctorum of a carrier/provider
>>>         Apart from the venerable fraunhofer java implementation, now
>>>         we can count on the flexible java implementation in
>>>         https://github.com/nickvsnetworking/pyhss with a lot of
>>>         features, good performances, and actually built for production.
>>>
>>>         I would say better we concentrate on accessing the various
>>>         different protocols of HSS (diameter/http2) from the various
>>>         components (each component in IMS access HSS with a
>>>         different interface with different vocabularies and actions.
>>>
>>>         MGCF/MGW, if needed, will be a natural extension of our
>>>         CSCF/AS architecture.
>>>
>>>         Just my two cents, to keep the ball rolling,
>>>
>>>         Congratulation again,
>>>
>>>         -giovanni
>>>
>>>
>>>         On Tue, Nov 28, 2023 at 2:02 PM Bogdan-Andrei Iancu
>>>         <bogdan at opensips.org> wrote:
>>>
>>>             Hi all,
>>>
>>>             (disclaimer : cross lists posting is not a good practice
>>>             - we will do this only to catch the attention and get
>>>             momentum with this initial topic)
>>>
>>>             As a first step here, is to work out the scope of the
>>>             IMS implementation in OpenSIPS. IMS is a vast concept,
>>>             with SIP and non-SIP components, and we want to
>>>             understand and agree on which components of IMS may be
>>>             subject of work from the OpenSIPS perspective. For
>>>             example, we do consider the CSCF as a must here, but we
>>>             may explore the HSS, AS, MGW or other components.
>>>
>>>             From the OpenSIPS perspective, we look for IMS
>>>             components which are SIP related. At least as a starting
>>>             point. So, the first obvious candidate is the *Call
>>>             Session Control Function (CSCF)*. And here we need to
>>>             look into and address the specific functionalities of
>>>             each sub-component:
>>>                 * P-CSCF
>>>                 * I-CSCF
>>>                 * S-CSCF
>>>
>>>             Again, these are the pretty obvious components, still
>>>             may look into and evaluate (if of an interest of the
>>>             OpenSIPS IMS implementation) areas as:
>>>                 * HSS (from interconnection perspective)
>>>                 * MGCF / MGW  (from interconnection perspective)
>>>                 * SIP AS
>>>                 * others ?
>>>
>>>             Any feedback (with explanations and arguments) about
>>>             what we should consider for our IMS implementation is
>>>             more the welcome. I set here just a simple starting
>>>             point, with no limitations or so. Feel free to
>>>             contribute to the topic
>>>
>>>
>>>             Best regards,
>>>
>>>             -- 
>>>             Bogdan-Andrei Iancu
>>>
>>>             OpenSIPS Founder and Developer
>>>                https://www.opensips-solutions.com
>>>                https://www.siphub.com
>>>
>>>             _______________________________________________
>>>             Wg-ims mailing list
>>>             Wg-ims at lists.opensips.org
>>>             http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims
>>>
>>>
>>>
>>>         -- 
>>>         Sincerely,
>>>
>>>         Giovanni Maruzzelli
>>>         OpenTelecom.IT
>>>         cell: +39 347 266 56 18
>>>
>>
>>         _______________________________________________
>>         Wg-ims mailing list
>>         Wg-ims at lists.opensips.org
>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims
>>
>
>     _______________________________________________
>     Wg-ims mailing list
>     Wg-ims at lists.opensips.org
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/wg-ims/attachments/20231205/42c56d33/attachment-0001.html>


More information about the Wg-ims mailing list