From carsten at ng-voice.com Mon Dec 4 15:32:53 2023 From: carsten at ng-voice.com (Carsten Bock) Date: Mon, 4 Dec 2023 16:32:53 +0100 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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 > 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: From bogdan at opensips.org Tue Dec 5 10:23:09 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 5 Dec 2023 12:23:09 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: Hi Giovanni, I did some reading about this NSA vs SA and as I understand, this will not impact the actual functionalities we need, but more the logic and interfacing with other components (HSS or PC(R)F). More or less, from OpenSIPS perspective, we need the same set of features, but the scripting will differ (as logic and DIAMETER messages). Is this correct? PS: what I'm trying to understand is if we do need anything special from coding perspective in order to address both NSA and SA Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 29.11.2023 19:45, Giovanni Maruzzelli wrote: > Yes, actually there is a difference between 5g and 4g infrastructure, > that actually often involve different interfacing from IMS to it, > particularly pcscf and icscf, eg: the way they interact with hss and > pcf/pcrf. > Problem is that 4g infrastructure is different from 5g. When they > implement 4g+5g, they implement actually both (so, no problem) > > 4g+5g is called NSA (not stand alone) > > A pure 5g is SA (stand alone) and offer different interfaces from the > ones provided by 4g. > > In NSA you (IMS) can behave like it's pure 4g (you use 4g interfaces > to do all things, even for the 5g part) > > In SA not at all, you must interface to 5g > > The main difference for what ims is concerned is pcf vs pcrf > > Let's note that most private networks (enterprise, etc) will be SA > > Most carriers will obviously be NSA > > > > answered from mobile, please pardon terseness and typos, > -giovanni > > On Wed, Nov 29, 2023, 18:25 Bogdan-Andrei Iancu > wrote: > > Hi Johan, > > The lowest point we should address in the whole IMS arch is the > P-CSCF, so we are agnostic to the actual transport layer below us > (like the xG stuff). Or am I saying here something wrong and there > are some implications to the upper layers ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 29.11.2023 18:07, Johan De Clercq wrote: >> In addition, the IMS should be able to handle 4G and 5G calls. >> In my opinion, we should no longer about 2 and 3 G as they are >> being phased out everywhere. >> >> wkr, >> >> Op wo 29 nov 2023 om 16:39 schreef Bogdan-Andrei Iancu >> : >> >> 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 >>> 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: From bogdan at opensips.org Tue Dec 5 10:50:44 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 5 Dec 2023 12:50:44 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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 > : > > 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 >> 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: From Johan at democon.be Tue Dec 5 11:05:23 2023 From: Johan at democon.be (Johan De Clercq) Date: Tue, 5 Dec 2023 12:05:23 +0100 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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 : > 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 >> 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: From bogdan at opensips.org Tue Dec 5 11:20:23 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 5 Dec 2023 13:20:23 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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 > : > > 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 >> : >> >> 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 >>> 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: From flavio at opensips.org Tue Dec 5 11:25:27 2023 From: flavio at opensips.org (Flavio Goncalves) Date: Tue, 5 Dec 2023 08:25:27 -0300 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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), 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 > > 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 >> 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: From carsten at ng-voice.com Tue Dec 5 12:33:06 2023 From: carsten at ng-voice.com (Carsten Bock) Date: Tue, 5 Dec 2023 13:33:06 +0100 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: 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 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 > > 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 >> 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: From bogdan at opensips.org Wed Dec 6 11:50:20 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 6 Dec 2023 13:50:20 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: <202352d0-d64b-455c-bc99-359b222b765b@opensips.org> 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 > ), 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 > 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 >> >> 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 >> : >> >> 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 >>> 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: From bogdan at opensips.org Wed Dec 6 11:53:11 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 6 Dec 2023 13:53:11 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: <5f95732e-8afb-49cc-81b0-434fddceaaaf@opensips.org> 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 > > 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 > : > > 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 >> : >> >> 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 >>> 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: From gmaruzz at gmail.com Wed Dec 6 13:19:55 2023 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Wed, 6 Dec 2023 14:19:55 +0100 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: On Tue, Dec 5, 2023 at 11:23 AM Bogdan-Andrei Iancu wrote: > I did some reading about this NSA vs SA and as I understand, this will not > impact the actual functionalities we need, but more the logic and > interfacing with other components (HSS or PC(R)F). > > Maybe I gave the impression it is a problem of formal requirements (and that's not), actually in my view it is a problem of (open source) implementations. One of the problems is that in 5G (let's call it NR, NewRadio), Open5GS implemented a different interface in PCF vs the one implemented in PCRF. So, while in LTE (4G) Open5GS uses Diameter for interfacing, in NR (5G) it has only implemented HTTP2. Then, we need HTTP2 and NR specific logic for implementing VoNR (Voice over New Radio) using Open5GS as NR core. More or less, from OpenSIPS perspective, we need the same set of features, > but the scripting will differ (as logic and DIAMETER messages). > > Yep, definitely: if all specs would have been implemented, VoNR would have *both* diameter and http2, so, it would be a superset of VoLTE with added http2 and some more things, and you can decide to interface it from IMS (that's us) via diameter (like in VoLTE) or via HTTP2 (VoNR specific). But Open5GS does not implement diameter in NR. Yes, as Carlsten said, we may implement a network function of a translator between diameter and http2, no idea if that is easier than implementing http2 into (x)CSCF. Maybe (just maybe) with kubernetes and all these deployment environments mainly tailored to web, they will heavily push with http2 for additional services. Or maybe in near future Open5GS will implement diameter in NR. Without Open5GS interfacing us (IMS) we'll not be able to actually test real implementation with actual 5G phones (and devil is always in details, simulations are nice, but...) -giovanni -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Dec 6 13:59:48 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 6 Dec 2023 15:59:48 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: <0d7d8cd9-8070-43af-babf-d5a83dc002cb@opensips.org> Message-ID: Hi Giovanni, Thanks for this valuable summary on the http2/diameter in 5g/4g - things are much, much clear now :) Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 06.12.2023 15:19, Giovanni Maruzzelli wrote: > On Tue, Dec 5, 2023 at 11:23 AM Bogdan-Andrei Iancu > wrote: > > I did some reading about this NSA vs SA and as I understand, this > will not impact the actual functionalities we need, but more the > logic and interfacing with other components (HSS or PC(R)F). > > > Maybe I gave the impression it is a problem of formal requirements > (and that's not), actually in my view it is a problem of (open source) > implementations. > > One of the problems is that in 5G (let's call it NR, NewRadio), > Open5GS implemented a different interface in PCF vs the one > implemented in PCRF. > > So, while in LTE (4G) Open5GS uses Diameter for interfacing, in NR > (5G) it has only implemented HTTP2. > Then, we need HTTP2 and NR specific logic for implementing VoNR (Voice > over New Radio) using Open5GS as NR core. > > More or less, from OpenSIPS perspective, we need the same set of > features, but the scripting will differ (as logic and DIAMETER > messages). > > > Yep, definitely: if all specs would have been implemented, VoNR would > have *both* diameter and http2, so, it would be a superset of VoLTE > with added http2 and some more things, and you can decide to interface > it from IMS (that's us) via diameter (like in VoLTE) or via HTTP2 > (VoNR specific). But Open5GS does not implement diameter in NR. > > Yes, as Carlsten said, we may implement a network function of a > translator between diameter and http2, no idea if that is easier than > implementing http2 into (x)CSCF. > Maybe (just maybe) with kubernetes and all these deployment > environments mainly tailored to web, they will heavily push with http2 > for additional services. > Or maybe in near future Open5GS will implement diameter in NR. > > Without Open5GS interfacing us (IMS)  we'll not be able to actually > test real implementation with actual 5G phones (and devil is always in > details, simulations are nice, but...) > > -giovanni > -- > Sincerely, > > Giovanni Maruzzelli > OpenTelecom.IT > cell: +39 347 266 56 18 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Dec 8 10:46:34 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 8 Dec 2023 12:46:34 +0200 Subject: [WG-IMS] Scope of IMS in OpenSIPS - RFC In-Reply-To: References: Message-ID: <92fe6f7a-5a8d-4ec0-95ab-46152100e74a@opensips.org> Hi all, I want to thank everyone who got involved in this discussion and contributed with info or ideas. I see it as a great exercise with great results :). And speaking of results, I tried to summarize here [1] the main ideas of the discussion, so we can use the info during the next steps. Now, with the scope in place, On Monday I will kick off the discussion on the technical requirements, so stay tuned ;) [1] https://github.com/OpenSIPS/opensips/wiki/IMS-Working-Group-Scope Great job everyone! Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 28.11.2023 15:02, Bogdan-Andrei Iancu 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Dec 12 10:56:39 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 12 Dec 2023 12:56:39 +0200 Subject: [WG-IMS] Technical Requirements - RFC Message-ID: Hi all, As the scoping process was successfully completed last week (see the conclusions here ), the next milestone is to explore the technical details and implications of each IMS component to be addressed. Here we are heavily relying on the input (as expertise) from people already involved in the IMS world, so please contribute as much as possible :). A first list of technical requirements is already compiled here - I tried to group the requirements around the components we have scoped as to be addressed. Now, what we need to do here: * verify and complete the list of requirements, to be sure nothing is missing in order to properly implement the IMS support. * comments or details about the items on the list are welcome - as many details/info as better * a "weak" item on the list is the Presence server - even if the SIP flows are clear, what is not yet 100% clear (at least for me) is what "event"'s are needed here - for sure the "presence" and as far as I heard the "reg" (RFC3680). But anyone can throw more light here ? Thanks and regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Dec 18 10:26:13 2023 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 18 Dec 2023 12:26:13 +0200 Subject: [WG-IMS] Technical Requirements - RFC In-Reply-To: References: Message-ID: <13ce34f7-cf46-44c7-8d5c-51d5125a23ed@opensips.org> Hi all, A quick reminder on this, as we should try to wrap up this stage by the end of this week (before the holiday). This will help us to stay on tracks with the 3.5 release. So, if you have any input on the tech requirements topic, please contribute :) Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 12.12.2023 12:56, Bogdan-Andrei Iancu wrote: > Hi all, > > As the scoping process was successfully completed last week (see the > conclusions here > ), > the next milestone is to explore the technical details and > implications of each IMS component to be addressed. > Here we are heavily relying on the input (as expertise) from people > already involved in the IMS world, so please contribute as much as > possible :). > > A first list of technical requirements is already compiled here > > - I tried to group the requirements around the components we have > scoped as to be addressed. > > Now, what we need to do here: > > * verify and complete the list of requirements, to be sure nothing is > missing in order to properly implement the IMS support. > > * comments or details about the items on the list are welcome - as > many details/info as better > > * a "weak" item on the list is the Presence server - even if the SIP > flows are clear, what is not yet 100% clear (at least for me) is what > "event"'s are needed here - for sure the "presence" and as far as I > heard the "reg" (RFC3680). But anyone can throw more light here ? > > > Thanks and 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Dec 20 10:56:24 2023 From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=) Date: Wed, 20 Dec 2023 12:56:24 +0200 Subject: [WG-IMS] Technical Requirements - RFC In-Reply-To: <13ce34f7-cf46-44c7-8d5c-51d5125a23ed@opensips.org> References: <13ce34f7-cf46-44c7-8d5c-51d5125a23ed@opensips.org> Message-ID: Hi, all! Let me jump in with some ideas about the high-level design of the IMS AKA authentication: the plan is to create an entity for managing the AV (authentication vectors) required by the AKA algorithm. This entity will interact via two generic interfaces. The first interface will face the authentication module and it should provide to the (new IMS) challenging and authentication functions an internal API that can be used to get a new AV, mark it as used, invalidate it, etc. The second interface will be required by the AV storage entity in order to fetch the needed AVs - this interface may be implemented by various modules. An example of such implementation would be a module that uses the internal diameter interface to do the Cx MAR/MAA requests to get the AVs from an HSS. Another implementation may require to run some routes to fetch the AVs through other script mechanisms, like hand-crafted Diameter requests, etc. Any feedback is welcome, so if you have any suggestions, do let us know. Best regards, Răzvan Crainea OpenSIPS Core Developer / SIPhub CTO http://www.opensips-solutions.com / https://www.siphub.com On 12/18/23 12:26, Bogdan-Andrei Iancu wrote: > Hi all, > > A quick reminder on this, as we should try to wrap up this stage by the > end of this week (before the holiday). This will help us to stay on > tracks with the 3.5 release. > > So, if you have any input on the tech requirements topic, please > contribute :) > > Thanks and regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >   https://www.opensips-solutions.com >   https://www.siphub.com > > On 12.12.2023 12:56, Bogdan-Andrei Iancu wrote: >> Hi all, >> >> As the scoping process was successfully completed last week (see the >> conclusions here >> ), >> the next milestone is to explore the technical details and >> implications of each IMS component to be addressed. >> Here we are heavily relying on the input (as expertise) from people >> already involved in the IMS world, so please contribute as much as >> possible :). >> >> A first list of technical requirements is already compiled here >> - I tried to group the requirements around the components we have scoped as to be addressed. >> >> Now, what we need to do here: >> >> * verify and complete the list of requirements, to be sure nothing is >> missing in order to properly implement the IMS support. >> >> * comments or details about the items on the list are welcome - as >> many details/info as better >> >> * a "weak" item on the list is the Presence server - even if the SIP >> flows are clear, what is not yet 100% clear (at least for me) is what >> "event"'s are needed here - for sure the "presence" and as far as I >> heard the "reg" (RFC3680). But anyone can throw more light here ? >> >> >> Thanks and 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 > > Hi all, > > A quick reminder on this, as we should try to wrap up this stage by the > end of this week (before the holiday). This will help us to stay on > tracks with the 3.5 release. > > So, if you have any input on the tech requirements topic, please > contribute :) > > Thanks and regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 12.12.2023 12:56, Bogdan-Andrei Iancu wrote: >> Hi all, >> >> As the scoping process was successfully completed last week (see the >> conclusions here >> ), >> the next milestone is to explore the technical details and >> implications of each IMS component to be addressed. >> Here we are heavily relying on the input (as expertise) from people >> already involved in the IMS world, so please contribute as much as >> possible :). >> >> A first list of technical requirements is already compiled here >> - I tried to group the requirements around the components we have scoped as to be addressed. >> >> Now, what we need to do here: >> >> * verify and complete the list of requirements, to be sure nothing is >> missing in order to properly implement the IMS support. >> >> * comments or details about the items on the list are welcome - as >> many details/info as better >> >> * a "weak" item on the list is the Presence server - even if the SIP >> flows are clear, what is not yet 100% clear (at least for me) is what >> "event"'s are needed here - for sure the "presence" and as far as I >> heard the "reg" (RFC3680). But anyone can throw more light here ? >> >> >> Thanks and 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 > > > _______________________________________________ > Wg-ims mailing list > Wg-ims at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims