<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">Hi Flavio,<br>
<br>
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 :).<br>
<br>
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.<br>
<br>
Best regards,<br>
</font>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 05.12.2023 13:25, Flavio Goncalves
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJkFROxEhJnQq0=f8hO16u3Gt7eNhqN0HEVr65rPp8VEz0VZTQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi, </div>
<div><br>
</div>
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 (<a href="https://youtu.be/OoP6C2ziYzY"
moz-do-not-send="true" class="moz-txt-link-freetext">https://youtu.be/OoP6C2ziYzY</a>).
Vance (<a href="http://sigscale.org" moz-do-not-send="true">sigscale.org</a>),
author of the video, produces an open source OCS/CCS he has a
lot of work in the area, developed in Erlang.
<div><br>
</div>
<div>However, the charging system seems out of scope for now.
Eventually we could test sigscale OCS integration. </div>
<div><br>
</div>
<div>1 - I agree with Carsten, we should start with P-I-S-CSCF,
starting with P-CSCF. </div>
<div>2 - The suggestion from Giovanni of using PyHSS seems great
too<br>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>
<div>Best regards, </div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Flavio E. Goncalves</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em ter., 5 de dez. de 2023 às
07:50, Bogdan-Andrei Iancu <<a
href="mailto:bogdan@opensips.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bogdan@opensips.org</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font face="monospace">Hi Carsten,<br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
Thanks and regards,<br>
</font>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="https://www.opensips-solutions.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.opensips-solutions.com</a>
<a href="https://www.siphub.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.siphub.com</a></pre>
<div>On 04.12.2023 17:32, Carsten Bock wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>(removed users@ - to avoid political discussions)</div>
<div><br>
</div>
<div>I would also suggest the following initial scope:</div>
<div>- 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 <i>in addition</i> to
Diameter. In a worst-case scenario, you could always
deploy a DRA to translate from Diameter to HTTP/2. </div>
<div>- A MMTel AS for providing essential services -
preferably with a native Diameter Sh Interface for
storing/retrieving supplementary service settings.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Just my initial thoughts,</div>
<div>Carsten</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">--</div>
<div dir="ltr">Carsten Bock I Chief
Technology Innovation Officer &
Founder</div>
<div dir="ltr"><br>
<p
style="margin:0cm 0cm 0.0001pt;background-image:initial;background-position:initial;background-repeat:initial"><span
style="color:black" lang="EN-US">ng-voice
GmbH</span><span
style="color:rgb(0,112,192)"
lang="EN-US"></span></p>
<p
style="margin-right:0cm;margin-bottom:12pt;margin-left:0cm;background-image:initial;background-position:initial;background-repeat:initial"><span
style="color:black" lang="EN-US">Trostbrücke
1 I 20457 Hamburg I Germany<br>
T +49 1511 5942983 I <a
href="http://www.ng-voice.com/"
style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"><span
style="color:black">www.ng-voice.com</span></a></span></p>
<p
style="margin:0cm 0cm 0.0001pt;background-image:initial;background-position:initial;background-repeat:initial"><span
style="color:black" lang="EN-US">Registry
Office at Local Court Hamburg, HRB
120189<br>
Managing Directors: Dr. David
Bachmann, Carsten Bock, Quirin
Maderspacher</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Mi., 29. Nov. 2023
um 16:39 Uhr schrieb Bogdan-Andrei Iancu <<a
href="mailto:bogdan@opensips.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bogdan@opensips.org</a>>:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font face="monospace">Hi Giovanni,<br>
<br>
Thanks for the feedback here, a valuable one as
usual :).<br>
<br>
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).<br>
<br>
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...
:-/ ??<br>
<br>
Best Regards, <br>
</font>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="https://www.opensips-solutions.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.opensips-solutions.com</a>
<a href="https://www.siphub.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.siphub.com</a></pre>
<div>On 29.11.2023 11:11, Giovanni Maruzzelli wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">First of all:<br>
CONGRATULATIONS to the OpenSIPS community !!!<br>
(I believe this is the first step of a long and
satisfying journey)<br>
<br>
On the topic:<br>
in addition to the CSCF component, I would like
to see efforts on the AS (Application Server)
component of the IMS infrastructure.
<div><br>
</div>
<div>The AS is probably way the simplest of it
all, it will probably require the least
modifications/additions to OpenSIPS.</div>
<div><br>
</div>
<div>But I would say AS will be crucial to a lot
of people/use cases.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Also, AS is the correct and manageable way
to provide additional services even if you
build the core IMS infrastructure.</div>
<div><br>
</div>
<div>About HSS: this is the sancta sanctorum of
a carrier/provider<br>
Apart from the venerable fraunhofer java
implementation, now we can count on the
flexible java implementation in <a
href="https://github.com/nickvsnetworking/pyhss" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/nickvsnetworking/pyhss</a>
with a lot of features, good performances, and
actually built for production.</div>
<div><br>
</div>
<div>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.<br>
<br>
MGCF/MGW, if needed, will be a natural
extension of our CSCF/AS architecture.</div>
<div><br>
</div>
<div>Just my two cents, to keep the ball
rolling,</div>
<div><br>
Congratulation again,<br>
<br>
</div>
<div>-giovanni<br>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Nov
28, 2023 at 2:02 PM Bogdan-Andrei Iancu <<a
href="mailto:bogdan@opensips.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bogdan@opensips.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font face="monospace">Hi all,<br>
<br>
(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)<br>
<br>
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.<br>
<br>
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 <b>Call Session
Control Function (CSCF)</b>. And here we
need to look into and address the specific
functionalities of each sub-component: <br>
* P-CSCF<br>
* I-CSCF<br>
* S-CSCF<br>
<br>
Again, these are the pretty obvious
components, still may look into and
evaluate (if of an interest of the
OpenSIPS IMS implementation) areas as:<br>
* HSS </font><font face="monospace">
(from interconnection perspective)<br>
</font><font face="monospace"> * MGCF /
MGW (from interconnection perspective)<br>
* SIP AS<br>
* others ?<br>
<br>
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<br>
<br>
<br>
Best regards,<br>
</font>
<pre cols="72">--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="https://www.opensips-solutions.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.opensips-solutions.com</a>
<a href="https://www.siphub.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.siphub.com</a></pre>
</div>
_______________________________________________<br>
Wg-ims mailing list<br>
<a href="mailto:Wg-ims@lists.opensips.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Wg-ims@lists.opensips.org</a><br>
<a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Sincerely,<br>
<br>
Giovanni Maruzzelli<br>
OpenTelecom.IT<br>
cell: +39 347 266 56 18<br>
<br>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
Wg-ims mailing list<br>
<a href="mailto:Wg-ims@lists.opensips.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Wg-ims@lists.opensips.org</a><br>
<a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
Wg-ims mailing list<br>
<a href="mailto:Wg-ims@lists.opensips.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Wg-ims@lists.opensips.org</a><br>
<a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>