[OpenSIPS-Users] Help dropping SQL injection attacks

2023-11-29 Thread Gregory Massel via Users 

Hi all

I'm wondering what the best practice is in terms of detection and 
dropping attempted SQL injection attacks?


Is something like the following adequate or can this be enhanced:

if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
drop();
}

Obviously this does not remove the need to escape anything passed to 
avp_db_query(), however, what I want to do is identify these sorts of 
attacks at the top of the script and avoid processing.


To date all the attacks I've seen focus on the contact and from user, e.g.:

INVITEsip:00111390237920793@x.x.x.x:5060;transport=UDP  SIP/2.0
Contact:
To:
From:;tag=v2pjtxqb

I'm not quite sure how to match the Contact user. Would the following work?

if ( $(ct.fields(uri){uri.user}) != 
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
drop();
}

--
Regards
*Gregory Massel*___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Răzvan Crainea 

Hi, Andrew!

What WebRTC client are you using? Could you capture the SIP messages 
exchanged between the two endpoints?


Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 11/29/23 17:37, Andrew Colin via Users wrote:

Correct I am using WSS

I have tested with SIP as well and had no issues

*From: *Bogdan-Andrei Iancu 
*Date: *Wednesday, 29 November 2023 at 15:33
*To: *Andrew Colin , 
users@lists.opensips.org 

*Subject: *Re: [OpenSIPS-Users] Strange Nat issue

The routing of the ACK is done accordingly to the routing info in the 
ACK itself (like RURI and Route hdrs). To see which is the next hop (as 
SIP for the ACK), after the successful loose_route(), log the $ru and 
$du... And I understand you are actually using WSS, right ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

   https://www.opensips-solutions.com  

   https://www.siphub.com  

On 29.11.2023 17:27, Andrew Colin wrote:

Hi Bogdan,

Seems to be in the context of the ACK yes.

Why would I be seeing proto 5 if we are using WSS then?

Kind Regards

*From: *Bogdan-Andrei Iancu 

*Date: *Wednesday, 29 November 2023 at 15:17
*To: *users@lists.opensips.org 
 , Andrew
Colin  
*Subject: *Re: [OpenSIPS-Users] Strange Nat issue

Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in the
context of the ACK ?

Regards,


Bogdan-Andrei Iancu

  


OpenSIPS Founder and Developer

   https://www.opensips-solutions.com  

   https://www.siphub.com  

On 29.11.2023 15:15, Andrew Colin via Users wrote:

Hi All,

Recently deployed opensips into AWS and when we make calls
between 2 webrtc clients I keep seeing this error in the logs
and the call eventually drops after 32 seconds

ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no
corresponding listening socket)

ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue




___

Users mailing list

Users@lists.opensips.org  

http://lists.opensips.org/cgi-bin/mailman/listinfo/users  



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Johan De Clercq 
I agree Giovanni. If the decision is made to go nsa (even not in first 
release), that should be taken into account. That’s why we need to scope.

Verzonden vanuit Outlook voor iOS

Van: Giovanni Maruzzelli 
Verzonden: Wednesday, November 29, 2023 6:45:58 PM
Aan: Bogdan-Andrei Iancu 
CC: Johan De Clercq ; Giovanni Maruzzelli 
; wg-...@lists.opensips.org 
; OpenSIPS users mailling list 

Onderwerp: Re: [WG-IMS] Scope of IMS in OpenSIPS - RFC

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 
mailto:bog...@opensips.org>> 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 
mailto:bog...@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 
mailto:bog...@opensips.org>> wrote:
Hi all,

(disclaimer : cross lists posting is not a good practice - we will do this only 
to catch the attention and get momentum with this initial topic)

As a first step here, is to work out the scope of the IMS implementation in 
OpenSIPS. IMS is a vast concept, with SIP and non-SIP components, and we want 
to understand and agree

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Giovanni Maruzzelli 
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 <
> bog...@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,

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Bogdan-Andrei Iancu 

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

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Bogdan-Andrei Iancu 

Have you tried the xlog'ing I suggested?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 29.11.2023 18:46, Andrew Colin wrote:


Could this be an issue with my websocket connection?

*From: *Bogdan-Andrei Iancu 
*Date: *Wednesday, 29 November 2023 at 15:33
*To: *Andrew Colin , 
users@lists.opensips.org 

*Subject: *Re: [OpenSIPS-Users] Strange Nat issue

The routing of the ACK is done accordingly to the routing info in the 
ACK itself (like RURI and Route hdrs). To see which is the next hop 
(as SIP for the ACK), after the successful loose_route(), log the $ru 
and $du... And I understand you are actually using WSS, right ?


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 29.11.2023 17:27, Andrew Colin wrote:

Hi Bogdan,

Seems to be in the context of the ACK yes.

Why would I be seeing proto 5 if we are using WSS then?

Kind Regards

*From: *Bogdan-Andrei Iancu 

*Date: *Wednesday, 29 November 2023 at 15:17
*To: *users@lists.opensips.org 
, Andrew Colin
 
*Subject: *Re: [OpenSIPS-Users] Strange Nat issue

Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in
the context of the ACK ?

Regards,


Bogdan-Andrei Iancu

  


OpenSIPS Founder and Developer

   https://www.opensips-solutions.com

   https://www.siphub.com

On 29.11.2023 15:15, Andrew Colin via Users wrote:

Hi All,

Recently deployed opensips into AWS and when we make calls
between 2 webrtc clients I keep seeing this error in the logs
and the call eventually drops after 32 seconds

ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no
corresponding listening socket)

ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue




___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Johan De Clercq 
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-...@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-...@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread 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-...@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims



--
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Andrew Colin via Users 
Correct I am using WSS

I have tested with SIP as well and had no issues




From: Bogdan-Andrei Iancu 
Date: Wednesday, 29 November 2023 at 15:33
To: Andrew Colin , users@lists.opensips.org 

Subject: Re: [OpenSIPS-Users] Strange Nat issue
The routing of the ACK is done accordingly to the routing info in the ACK 
itself (like RURI and Route hdrs). To see which is the next hop (as SIP for the 
ACK), after the successful loose_route(), log the $ru and $du... And I 
understand you are actually using WSS, right ?

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  https://www.opensips-solutions.com

  https://www.siphub.com
On 29.11.2023 17:27, Andrew Colin wrote:
Hi Bogdan,

Seems to be in the context of the ACK yes.
Why would I be seeing proto 5 if we are using WSS then?


Kind Regards




From: Bogdan-Andrei Iancu 
Date: Wednesday, 29 November 2023 at 15:17
To: users@lists.opensips.org 
, Andrew Colin 

Subject: Re: [OpenSIPS-Users] Strange Nat issue
Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in the context of 
the ACK ?

Regards,



Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  https://www.opensips-solutions.com

  https://www.siphub.com
On 29.11.2023 15:15, Andrew Colin via Users wrote:
Hi All,

Recently deployed opensips into AWS and when we make calls between 2 webrtc 
clients I keep seeing this error in the logs and the call eventually drops 
after 32 seconds


ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no corresponding 
listening socket)
ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue





___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Bogdan-Andrei Iancu 
The routing of the ACK is done accordingly to the routing info in the 
ACK itself (like RURI and Route hdrs). To see which is the next hop (as 
SIP for the ACK), after the successful loose_route(), log the $ru and 
$du... And I understand you are actually using WSS, right ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 29.11.2023 17:27, Andrew Colin wrote:


Hi Bogdan,

Seems to be in the context of the ACK yes.

Why would I be seeing proto 5 if we are using WSS then?

Kind Regards

*From: *Bogdan-Andrei Iancu 
*Date: *Wednesday, 29 November 2023 at 15:17
*To: *users@lists.opensips.org , Andrew 
Colin 

*Subject: *Re: [OpenSIPS-Users] Strange Nat issue

Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in the 
context of the ACK ?


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 29.11.2023 15:15, Andrew Colin via Users wrote:

Hi All,

Recently deployed opensips into AWS and when we make calls between
2 webrtc clients I keep seeing this error in the logs and the call
eventually drops after 32 seconds

ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no
corresponding listening socket)

ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue



___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Andrew Colin via Users 
Hi Bogdan,

Seems to be in the context of the ACK yes.
Why would I be seeing proto 5 if we are using WSS then?


Kind Regards




From: Bogdan-Andrei Iancu 
Date: Wednesday, 29 November 2023 at 15:17
To: users@lists.opensips.org , Andrew Colin 

Subject: Re: [OpenSIPS-Users] Strange Nat issue
Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in the context of 
the ACK ?

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  https://www.opensips-solutions.com

  https://www.siphub.com
On 29.11.2023 15:15, Andrew Colin via Users wrote:
Hi All,

Recently deployed opensips into AWS and when we make calls between 2 webrtc 
clients I keep seeing this error in the logs and the call eventually drops 
after 32 seconds


ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no corresponding 
listening socket)
ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue




___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Bogdan-Andrei Iancu 

Hi Andrew,

Proto 5 is WS (not WSS). Can you confirm if the error occurs in the 
context of the ACK ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 29.11.2023 15:15, Andrew Colin via Users wrote:


Hi All,

Recently deployed opensips into AWS and when we make calls between 2 
webrtc clients I keep seeing this error in the logs and the call 
eventually drops after 32 seconds


ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no 
corresponding listening socket)


ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Strange Nat issue

2023-11-29 Thread Andrew Colin via Users 
Hi All,

Recently deployed opensips into AWS and when we make calls between 2 webrtc 
clients I keep seeing this error in the logs and the call eventually drops 
after 32 seconds


ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 5  (no corresponding 
listening socket)
ERROR:tm:t_forward_nonack: failure to add branches

Normal SIP to SIP calls do not have the issue

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Giovanni Maruzzelli 
On Wed, Nov 29, 2023 at 10:11 AM Giovanni Maruzzelli 
wrote:

> 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.
>
>
Errata: PyHSS is obviously written in Python (not in Java at all), and very
much open to integrating features/etc on GitHub

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [WG-IMS] Scope of IMS in OpenSIPS - RFC

2023-11-29 Thread Giovanni Maruzzelli 
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-...@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/wg-ims
>


-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users