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

Tue Dec 5 11:05:23 UTC 2023

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
>
> 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/a6daca50/attachment-0001.html>