<div dir="ltr">In addition, the IMS should be able to handle 4G and 5G calls.   <div>In my opinion, we should no longer about 2 and 3 G as they are being phased out everywhere. </div><div><br></div><div>wkr, </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op wo 29 nov 2023 om 16:39 schreef Bogdan-Andrei Iancu <<a href="mailto:bogdan@opensips.org">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"><u></u>

  
    
  
  <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">https://www.opensips-solutions.com</a>
  <a href="https://www.siphub.com" target="_blank">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">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">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">https://www.opensips-solutions.com</a>
  <a href="https://www.siphub.com" target="_blank">https://www.siphub.com</a></pre>
          </div>
          _______________________________________________<br>
          Wg-ims mailing list<br>
          <a href="mailto:Wg-ims@lists.opensips.org" target="_blank">Wg-ims@lists.opensips.org</a><br>
          <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims" rel="noreferrer" target="_blank">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">Wg-ims@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims</a><br>
</blockquote></div>