[OpenSIPS-Users] OpenSIPS and Teams - Route headers and FQDN

[Daren FERREIRA]

Hello,

According to my understanding of OpenSIPS Route headers management with 
loose_route function, it is only able to test matching between local listening 
IP addresses and Route headers, not with FQDN.

In other words, if FQDN are presents in Route headers, they are compared to 
local IP addresses (well visible in logs), so, this never matches and you get a 
"WARNING:rr:after_loose: no socket found to match 2nd RR"

This has never been a limitation until I had to work with Microsoft TEAMS, that 
requires the use of FQDN in Route headers.

I tried using aliases, Route headers tags, and lots of other things, without 
success…

Even if aliases would have been a solution, that is not a scalable solution 
when using OpenSIPS as a multi-tenant SBC for Teams (as aliases changes require 
an OpenSIPS restart).

The only workaround I found was rewriting $du and $socket (so partially 
reimplement loose_route() ) based on context values stored in dialog variables 
(that’s working quite well anyway).

Many people seems to use OpenSIPS successfully with TEAMS and nobody seems to 
have publicly complained about such limitations on forums.

I may have missed something, and so I wonder what can be done to better work 
with Route headers.

Do anybody have any idea on what I may have missed?

Thank you for your advices and comments.

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

Re: [OpenSIPS-Users] OpenSIPS and Teams - Route headers and FQDN

[John Burke via Users]

Hey Daren,

Aliases should work I believe, however, you can also use the domain module[1] 
to dynamically maintain “local” FQDNs.

[1] https://opensips.org/docs/modules/devel/domain.html

Sent from my iPhone

> On Feb 21, 2023, at 8:33 AM, Daren FERREIRA  wrote:
> 
> Hello,
> 
> According to my understanding of OpenSIPS Route headers management with 
> loose_route function, it is only able to test matching between local 
> listening IP addresses and Route headers, not with FQDN.
> 
> In other words, if FQDN are presents in Route headers, they are compared to 
> local IP addresses (well visible in logs), so, this never matches and you get 
> a "WARNING:rr:after_loose: no socket found to match 2nd RR"
> 
> This has never been a limitation until I had to work with Microsoft TEAMS, 
> that requires the use of FQDN in Route headers.
> 
> I tried using aliases, Route headers tags, and lots of other things, without 
> success…
> 
> Even if aliases would have been a solution, that is not a scalable solution 
> when using OpenSIPS as a multi-tenant SBC for Teams (as aliases changes 
> require an OpenSIPS restart).
> 
> The only workaround I found was rewriting $du and $socket (so partially 
> reimplement loose_route() ) based on context values stored in dialog 
> variables (that’s working quite well anyway).
> 
> Many people seems to use OpenSIPS successfully with TEAMS and nobody seems to 
> have publicly complained about such limitations on forums.
> 
> I may have missed something, and so I wonder what can be done to better work 
> with Route headers.
> 
> Do anybody have any idea on what I may have missed?
> 
> Thank you for your advices and comments.
> 
> Daren
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> --
> Please be cautious! This email was sent from outside of Voxtelesys.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS and Teams - Route headers and FQDN

[Daren FERREIRA]

Hi John,

Everything I read, even in the opensips source code (grep_sock_info_ext 
function) shows it is only comparing Route headers values to its local IP 
addresses.
Whatever I set, comparison is always made with IPs not FQDN.

I do use domain modules for other tests and functions but according to my 
tests, domain module is not linked nor « consumed » by loose_route(), so that 
doesn’t solve my issue.

I wonder if the reason I face this problems is not because:
- I use the same IP address to talk to Microsoft as to talk to my internal 
devices => If IP would be different on the « WAN » and « LAN » side, maybe that 
would be much easier for opensips to match?
- I use UDP TLS with Microsoft and UDP with my internal devices => If protocol 
would be the same, there won’t have to switch between sockets?

Maybe a mix of both…

Or maybe most people using OpenSIPS with Teams don’t use it for multi-tenant, 
use it statically or have done the same « cooking » I made without complaining 
;-)

Thank you for you reply :-)



> Le 21 févr. 2023 à 15:40, John Burke via Users  a 
> écrit :
> 
> Hey Daren,
> 
> Aliases should work I believe, however, you can also use the domain module[1] 
> to dynamically maintain “local” FQDNs.
> 
> [1] https://opensips.org/docs/modules/devel/domain.html
> 
> Sent from my iPhone
> 
>> On Feb 21, 2023, at 8:33 AM, Daren FERREIRA  wrote:
>> 
>> Hello,
>> 
>> According to my understanding of OpenSIPS Route headers management with 
>> loose_route function, it is only able to test matching between local 
>> listening IP addresses and Route headers, not with FQDN.
>> 
>> In other words, if FQDN are presents in Route headers, they are compared to 
>> local IP addresses (well visible in logs), so, this never matches and you 
>> get a "WARNING:rr:after_loose: no socket found to match 2nd RR"
>> 
>> This has never been a limitation until I had to work with Microsoft TEAMS, 
>> that requires the use of FQDN in Route headers.
>> 
>> I tried using aliases, Route headers tags, and lots of other things, without 
>> success…
>> 
>> Even if aliases would have been a solution, that is not a scalable solution 
>> when using OpenSIPS as a multi-tenant SBC for Teams (as aliases changes 
>> require an OpenSIPS restart).
>> 
>> The only workaround I found was rewriting $du and $socket (so partially 
>> reimplement loose_route() ) based on context values stored in dialog 
>> variables (that’s working quite well anyway).
>> 
>> Many people seems to use OpenSIPS successfully with TEAMS and nobody seems 
>> to have publicly complained about such limitations on forums.
>> 
>> I may have missed something, and so I wonder what can be done to better work 
>> with Route headers.
>> 
>> Do anybody have any idea on what I may have missed?
>> 
>> Thank you for your advices and comments.
>> 
>> Daren
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> --
>> Please be cautious! This email was sent from outside of Voxtelesys.
> ___
> 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] WSS errors

[nutxase via Users]

Hi Razvan

Thanks for the reply

Would you mind clarifying if i must enable the ping from the webrtc client or 
if there is a specific paramater i am missing in my opensips config

Thanks!!




Sent with Proton Mail secure email.

--- Original Message ---
On Monday, February 20th, 2023 at 5:04 PM, Pat M via Users 
 wrote:


> Hello Razvan Son
> 
> I am too facing this issue, does the ping need to come from the mobile client 
> or from opensips itself?
> 
> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> --- Original Message ---
> On Friday, January 27th, 2023 at 1:07 PM, Răzvan Crainea raz...@opensips.org 
> wrote:
> 
> 
> 
> > Hi, nutxase!
> > 
> > Connection to your browser gets closed, and OpenSIPS tries to
> > re-connect, but fails (due to browser jail, etc.) You should enable
> > pinging in your setup to keep the connection open, and ideally reconnect
> > from the browser if the connection gets closed.
> > 
> > Best regards,
> > 
> > Răzvan Crainea
> > OpenSIPS Core Developer
> > http://www.opensips-solutions.com
> > 
> > On 1/23/23 18:38, nutxase via Users wrote:
> > 
> > > Hey All
> > > 
> > > Strange error
> > > 
> > > i have registrations working via WSS and all works fine about after
> > > about 5 incoming calls
> > > the log gets these errors and the only way to receive calls again is to
> > > restart opensips
> > > 
> > > Jan 19 20:06:41 [localhost] /usr/sbin/opensips[4263]: 
> > > ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed
> > > Jan 19 20:06:41 [localhost] /usr/sbin/opensips[4263]: 
> > > ERROR:proto_wss:ws_connect: connect failed
> > > Jan 19 20:06:41 [localhost] /usr/sbin/opensips[4263]: 
> > > ERROR:proto_wss:proto_wss_send: connect failed
> > > Jan 19 20:06:41 [localhost] /usr/sbin/opensips[4263]: ERROR:tm:msg_send: 
> > > send() to :39048 for proto wss/6 failed
> > > Jan 19 20:06:41 [localhost] /usr/sbin/opensips[4263]: 
> > > ERROR:tm:t_forward_nonack: sending request failed
> > > 
> > > Sent with Proton Mail https://proton.me/ secure email.
> > > 
> > > ___
> > > 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

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

Re: [OpenSIPS-Users] OpenSIPS and Teams - Route headers and FQDN

[Karsten Wemheuer]

Hi Daren,

because you mention MS Teams: do you know the blogpost "OpenSIPS as MS
Teams SBC" [1]? Maybe the description will help you.

Have a nice day,
Karsten

[1] https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/

Am Dienstag, dem 21.02.2023 um 15:30 +0100 schrieb Daren FERREIRA:
> Hello,
>
> According to my understanding of OpenSIPS Route headers management
> with loose_route function, it is only able to test matching between
> local listening IP addresses and Route headers, not with FQDN.
>
> In other words, if FQDN are presents in Route headers, they are
> compared to local IP addresses (well visible in logs), so, this never
> matches and you get a "WARNING:rr:after_loose: no socket found to
> match 2nd RR"
>
> This has never been a limitation until I had to work with Microsoft
> TEAMS, that requires the use of FQDN in Route headers.
>
> I tried using aliases, Route headers tags, and lots of other things,
> without success…
>
> Even if aliases would have been a solution, that is not a scalable
> solution when using OpenSIPS as a multi-tenant SBC for Teams (as
> aliases changes require an OpenSIPS restart).
>
> The only workaround I found was rewriting $du and $socket (so
> partially reimplement loose_route() ) based on context values stored
> in dialog variables (that’s working quite well anyway).
>
> Many people seems to use OpenSIPS successfully with TEAMS and nobody
> seems to have publicly complained about such limitations on forums.
>
> I may have missed something, and so I wonder what can be done to
> better work with Route headers.
>
> Do anybody have any idea on what I may have missed?
>
> Thank you for your advices and comments.
>
> Daren
> ___
> 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] OpenSIPS and Teams - Route headers and FQDN

[Daren FERREIRA]

Hello Karsten,

Of course I did, that was my first reference ;-)

Have a nice day too

Daren


> Le 21 févr. 2023 à 16:48, Karsten Wemheuer  a écrit :
> 
> Hi Daren,
> 
> because you mention MS Teams: do you know the blogpost "OpenSIPS as MS
> Teams SBC" [1]? Maybe the description will help you.
> 
> Have a nice day,
> Karsten
> 
> [1] https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/
> 
> Am Dienstag, dem 21.02.2023 um 15:30 +0100 schrieb Daren FERREIRA:
>> Hello,
>> 
>> According to my understanding of OpenSIPS Route headers management
>> with loose_route function, it is only able to test matching between
>> local listening IP addresses and Route headers, not with FQDN.
>> 
>> In other words, if FQDN are presents in Route headers, they are
>> compared to local IP addresses (well visible in logs), so, this never
>> matches and you get a "WARNING:rr:after_loose: no socket found to
>> match 2nd RR"
>> 
>> This has never been a limitation until I had to work with Microsoft
>> TEAMS, that requires the use of FQDN in Route headers.
>> 
>> I tried using aliases, Route headers tags, and lots of other things,
>> without success…
>> 
>> Even if aliases would have been a solution, that is not a scalable
>> solution when using OpenSIPS as a multi-tenant SBC for Teams (as
>> aliases changes require an OpenSIPS restart).
>> 
>> The only workaround I found was rewriting $du and $socket (so
>> partially reimplement loose_route() ) based on context values stored
>> in dialog variables (that’s working quite well anyway).
>> 
>> Many people seems to use OpenSIPS successfully with TEAMS and nobody
>> seems to have publicly complained about such limitations on forums.
>> 
>> I may have missed something, and so I wonder what can be done to
>> better work with Route headers.
>> 
>> Do anybody have any idea on what I may have missed?
>> 
>> Thank you for your advices and comments.
>> 
>> Daren
>> ___
>> 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] OpenSIPS and Teams - Route headers and FQDN

[Daren FERREIRA]

Hey John,

I made some more tests and, indeed, domain is well used by loose_route my 
problem is:



On both cases, the most important informations are $socket_out and $du I print 
on my log messages:


If domain is defined and known, is is considered as local but socket and $du 
are emptied because of the previously mentioned warning: 
"WARNING:rr:after_loose: no socket found to match 2nd RR" And I get

Feb 21 17:27:49 opensips[48264]: Feb 21 17:27:49 [48264] INFORMATIONS ROUTE C2: 
SOURCE 52.114.75.24 METHOD ACK STATUS  REPLY_REASON  RECEIVED_ON 
tls:100.64.0.1 REPLY FROM tls:100.64.0.1:5061 DU 
sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on
 - myFQDN.com 


If domain is not defined, is is not considered as local and socket and $du are 
left as is and so, not treated as it should. And I get:

Feb 21 17:31:32 opensips[48264]: Feb 21 17:31:32 [48264] INFORMATIONS ROUTE C2: 
SOURCE 52.114.75.24 METHOD ACK STATUS  REPLY_REASON  RECEIVED_ON 
tls:100.64.0.1 REPLY FROM udp:100.64.0.1:5060 DU  - 


My message has been blocked because of its length. Full log is available on 
https://pastebin.com/tXKAJpeL


In short terms: 

REPLY FROM $socket_out DU $du

"REPLY FROM tls:100.64.0.1:5061 DU 
sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on"
"REPLY FROM udp:100.64.0.1:5060 DU  »


Where we well see that $du is empty… (and in some cases $socket_out is wrong).

That seems to confirm my thoughts about a potential problem with reusing the 
same IP facing Microsoft as the facing my internal devices and/or the mix 
between UDP and TLS.


On you case, to you use the same IP address for facing Microsoft and you 
devices? Do you use TLS on both sides of the call?

Thank you 




> Le 21 févr. 2023 à 17:07, John Burke  a écrit :
> 
> Hey Daren
> 
> It's been a while since I've been inside the MS integration TBH, but I 
> remember digging into the code at the time and am pretty sure it was the 
> domain module that fixed the multi-tenant FQDN loose-routing issue.  You 
> dismissed the domain implemented based on your source code searching, but did 
> you give it a quick try?
> 
> I quickly looked up some notes:
> 
> 
> 
> 
> My memory could be wrong :) but IMO it's worth a quick shot.
> 
> I didn't see anything else special in the config for MS, besides what the 
> tutorial points out.
> 
> Regards,
> John Burke
> 
> On 2/21/23 9:28 AM, Daren FERREIRA wrote:
>> Hi John,
>> 
>> Everything I read, even in the opensips source code (grep_sock_info_ext 
>> function) shows it is only comparing Route headers values to its local IP 
>> addresses.
>> Whatever I set, comparison is always made with IPs not FQDN.
>> 
>> I do use domain modules for other tests and functions but according to my 
>> tests, domain module is not linked nor « consumed » by loose_route(), so 
>> that doesn’t solve my issue.
>> 
>> I wonder if the reason I face this problems is not because:
>> - I use the same IP address to talk to Microsoft as to talk to my internal 
>> devices => If IP would be different on the « WAN » and « LAN » side, maybe 
>> that would be much easier for opensips to match?
>> - I use UDP TLS with Microsoft and UDP with my internal devices => If 
>> protocol would be the same, there won’t have to switch between sockets?
>> 
>> Maybe a mix of both…
>> 
>> Or maybe most people using OpenSIPS with Teams don’t use it for 
>> multi-tenant, use it statically or have done the same « cooking » I made 
>> without complaining ;-)
>> 
>> Thank you for you reply :-)
>> 
>> 
>> 
>>> Le 21 févr. 2023 à 15:40, John Burke via Users  
>>>  a écrit :
>>> 
>>> Hey Daren,
>>> 
>>> Aliases should work I believe, however, you can also use the domain 
>>> module[1] to dynamically maintain “local” FQDNs.
>>> 
>>> [1] https://opensips.org/docs/modules/devel/domain.html
>>> 
>>> Sent from my iPhone
>>> 
 On Feb 21, 2023, at 8:33 AM, Daren FERREIRA  
  wrote:
 
 Hello,
 
 According to my understanding of OpenSIPS Route headers management with 
 loose_route function, it is only able to test matching between local 
 listening IP addresses and Route headers, not with FQDN.
 
 In other words, if FQDN are presents in Route headers, they are compared 
 to local IP addresses (well visible in logs), so, this never matches and 
 you get a "WARNING:rr:after_loose: no socket found to match 2nd RR"
 
 This has never been a limitation until I had to work with Microsoft TEAMS, 
 that requires the use of FQDN in Route headers.
 
 I tried using aliases, Route headers tags, and lots of other things, 
 without success…
 
 Even if aliases would have been a solution, that is not a scalable 
 solution when using OpenSIPS as a multi-tenant SBC for Teams (as aliases 
 changes require an OpenSIPS restart).
 
 The only workaround I found was rewritin

[OpenSIPS-Users] Carrier_ID not writing on DRouting when using partitions

[Daniel Zanutti]

Hey

I'm having a weird issue, possibly a BUG, using opensips 3.2.8.

The carrier_id_avp is not being written, when I enabled partitions or
drouting module. Everything else works, just this value is not written to
the AVP setted. Routing works fine using carriers, just the AVP is not
written.

When I disable partitions, it works fine writting to carrier_id_avp. =|

Configuration:
modparam("drouting", "carrier_id_avp", "$avp(carrier_id)")

Example of call
My dr_rule has gwlist = #651

Carrier 651
carrierid=651
gwlist=651 (yes, same id)

Applied routing with partition:
do_routing(,"F",,,$avp(gw_attrs),,"partition1")

Log:
Feb 22 01:14:51 sbc4 /usr/local/sbin/opensips[856]:
DBG:drouting:push_gw_for_usage: adding gw [651] as "sip:x...@yy.yy.yy.yy"
in order 0
Feb 22 01:14:51 sbc4 /usr/local/sbin/opensips[856]:
DBG:drouting:push_gw_for_usage: setting GW id [651] as avp
Feb 22 01:14:51 sbc4 /usr/local/sbin/opensips[856]:
DBG:drouting:push_gw_for_usage: setting GW attr [1] as avp

The gateway 651 does exist, it's the same name of Carrier but it shouldn't
be a problem.

Checking logs, $avp(carrier_id) is null:
Carrier:yy.yy.yy.yy()

Do you guys have any clues on how to solve it? Maybe a bug?

This works fine when not using partitions.

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

[OpenSIPS-Users] Push Notification - Location table has flag 0 v3.3

[HS]

Hi all.

I am starting to implement push notifications on Opensips v3.3, using an
old Linphone version that sends out parameters in the following format:

pn-type instead of pn-provider
firebase instead of fcm
app-id  instead of pn-param
pn-tok  instead of pn-prid

Location table has flag 0 (I think it should be 4). I tried adding pn-type,
app-id in pn_ct_match_params, but didn't seem to work (flag is still 0).

modparam("registrar", "pn_providers", "apns, fcm, firebase")
modparam("registrar", "pn_ct_match_params", "pn-provider, pn-prid,
pn-param, pn-type, pn-tok, app-id")

Is v3.3 incompatible with the old nomenclature or am I missing something?

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