[WG-IMS] Scope of IMS in OpenSIPS - RFC
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Dec 6 11:50:20 UTC 2023
Hi Flavio,
Ok, so the idea of SA versus NSA not impacting the actual code (but
maybe scripting logic) seems to take shape here. In regards to the
Charging System, (not sure which components are interacting with it, the
S-CSCF, AS ?) I guess interacts via DIAMETER, right ? AS you said, for
the integration sake :).
Now, about the deliverable, this is a later milestone here (part of the
WG roadmap), but at this point I see the need to provide some basic
scripts here.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 05.12.2023 13:25, Flavio Goncalves wrote:
> Hi,
>
> I'm not an expert, regarding IMS I have not seen many differences in
> SA or NSA. There are differences later in the OCS (Online Charging
> System) completely reworked in Huawei and ZTE to CCS. I had a contact
> with a SA implementation of 5G, the IMS was more or less the same, but
> the online charging was based on the http/2 stack used for CCS
> (Converged Charging System). O good video on CCS
> (https://youtu.be/OoP6C2ziYzY). Vance (sigscale.org
> <http://sigscale.org>), author of the video, produces an open source
> OCS/CCS he has a lot of work in the area, developed in Erlang.
>
> However, the charging system seems out of scope for now. Eventually we
> could test sigscale OCS integration.
>
> 1 - I agree with Carsten, we should start with P-I-S-CSCF, starting
> with P-CSCF.
> 2 - The suggestion from Giovanni of using PyHSS seems great too
>
> One question, regarding the scope. The deliverables of the working
> group. Are we planning to provide the modules or the modules plus
> scripts for reference implementation?
>
> Best regards,
>
> Flavio E. Goncalves
>
>
> Em ter., 5 de dez. de 2023 às 07:50, Bogdan-Andrei Iancu
> <bogdan at opensips.org> escreveu:
>
> 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/20231206/47329f10/attachment-0001.html>
More information about the Wg-ims
mailing list