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

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Dec 6 11:53:11 UTC 2023


Hi Carsten,

Gotcha you! basically the MMTel AS should implement some predefined 
logic (like routing between devices, to other networks) with the 
addition of those listed service - and the settings for the service 
resides in HSS (via Sh). I hope I got it right :)

Best regards,

Bogdan-Andrei Iancu

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

On 05.12.2023 14:33, Carsten Bock wrote:
> Hi,
>
> The central role of the MMTel is purely to 
> provide supplementary services like call-forwarding, call-barring, 
> etc. As a result, it only has SIP- (ISC-Interface towards the S-CSCF) 
> and the Sh-Interface (for storing and retrieving the settings from the 
> HSS).
>
> You can find a list of supplementary services here:
> https://www.gsma.com/newsroom/wp-content/uploads//IR.92-v18.0-3.pdf
> (Page 24)
>
> You can actually create most of the supplementary services in a few 
> hundred lines of OpenSIPS.cfg - the complex part is restoring and 
> retrieving the settings using the Sh-Interface.
>
> IR.92 compliance is a widespread request when it comes to VoLTE 
> deployments.
>
> Thanks,
> 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 Di., 5. Dez. 2023 um 11:50 Uhr schrieb 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/wg-ims/attachments/20231206/cde9fa7a/attachment-0001.html>


More information about the Wg-ims mailing list