Re: [OpenSIPS-Users] [CRASH] segfault in b2b_logic

[Bela H]

>From gdb debug:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f573bbf1bd0 in b2bl_insert_new () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/b2b_logic.so

From: Bela H
Sent: Thursday, 23 February 2023 11:47
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] [CRASH] segfault in b2b_logic

Hello,

I am playing with b2bua and OpenSIPS was working fine but suddenly stopped to 
respond.
Tried to restart it but crashes now all the time with b2b. (without that it 
starts OK).

I am using OpenSIPS:
version: opensips 3.2.10 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, 
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on  with gcc 10

on Debian 11.3

After restart I got the following error:

Feb 23 11:31:37 sbc1 /usr/sbin/opensips[7010]: CRITICAL:core:sig_usr: segfault 
in attendant (starter) process!
Feb 23 11:31:37 sbc1 kernel: [66677.326614] opensips[7010]: segfault at 968 ip 
7fdf8fd68bd0 sp 7ffe650ced00 error 4 in b2b_logic.so[7fdf8fd3d000+2d000]
Feb 23 11:31:37 sbc1 kernel: [66677.326627] Code: 41 89 84 24 e4 00 00 00 8b 44 
24 0c 41 89 44 24 04 8b 45 08 41 89 44 24 2c 8b 45 0c 41 89 44 24 30 48 85 d2 
74 2d 48 8b 04 24 <8b> 80 68 09 00 00 23 05 b4 0a 01 00 74 1b ff d2 f3 0f 6f 00 
41 0f
Feb 23 11:31:37 sbc1 opensips: INFO:core:daemonize: pre-daemon process exiting 
with -1
Feb 23 11:31:37 sbc1 systemd[1]: opensips.service: Control process exited, 
code=exited, status=255/EXCEPTION

Is this a bug? How can I check it further?

Cheers,
Bela

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

[OpenSIPS-Users] [CRASH] segfault in b2b_logic

[Bela H]

Hello,

I am playing with b2bua and OpenSIPS was working fine but suddenly stopped to 
respond.
Tried to restart it but crashes now all the time with b2b. (without that it 
starts OK).

I am using OpenSIPS:
version: opensips 3.2.10 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, 
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on  with gcc 10

on Debian 11.3

After restart I got the following error:

Feb 23 11:31:37 sbc1 /usr/sbin/opensips[7010]: CRITICAL:core:sig_usr: segfault 
in attendant (starter) process!
Feb 23 11:31:37 sbc1 kernel: [66677.326614] opensips[7010]: segfault at 968 ip 
7fdf8fd68bd0 sp 7ffe650ced00 error 4 in b2b_logic.so[7fdf8fd3d000+2d000]
Feb 23 11:31:37 sbc1 kernel: [66677.326627] Code: 41 89 84 24 e4 00 00 00 8b 44 
24 0c 41 89 44 24 04 8b 45 08 41 89 44 24 2c 8b 45 0c 41 89 44 24 30 48 85 d2 
74 2d 48 8b 04 24 <8b> 80 68 09 00 00 23 05 b4 0a 01 00 74 1b ff d2 f3 0f 6f 00 
41 0f
Feb 23 11:31:37 sbc1 opensips: INFO:core:daemonize: pre-daemon process exiting 
with -1
Feb 23 11:31:37 sbc1 systemd[1]: opensips.service: Control process exited, 
code=exited, status=255/EXCEPTION

Is this a bug? How can I check it further?

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

[OpenSIPS-Users] rtpengine_offer on REINVITE

[Callum Guy]

Hi All,

I operate OpenSIPs in front of a bank of FreeSWITCH instances and I'm
currently seeing an issue with FreeSWITCH crashing during a SRTP DTLS
renegotiation triggered by a RE-INVITE.

I've tracked this down to a WSS registrar which is issuing
rtpengine_offer(...) for the INVITE and any subsequent RE-INVITE. This
happens thousands of times a day without issue however on occasion OpenSIPs
sends that RE-INVITE request to a different rtpengine server from the pool.
This writes in the new RTP proxy IP and initiates a new ICE
negotiation, the client fails to handle this and the DTLS negotiation
breaks down - RTPEngine warns "*Received invalid STUN packet from
1.8.4.1:58184 : MESSAGE_INTEGRITY attribute missing*"
and FreeSWITCH segfaults.

Can anyone advise on what might be causing OpenSIPs to pick an unrelated
RTP instance for the dialog? Any ideas for preventing that would be
appreciated! I could conceivably save the socket after the initial offer
against the dialog and use that for additional offers but hopefully that
can be avoided. I use RTPEngine only as a proxy, perhaps I should simply
prevent RE-INVITE's from sending additional offers so I only have one
offer/answer/delete per call?

Thanks,

Callum

-- 






*0333 332   |  x-on.co.uk   |   ** 
    
   **  |  **Practice Index Reviews 
*

*Our new office address: 22 Riduna 
Park, Melton IP12 1QT.*

X-on
is a trading name of Storacall Technology Ltd 
a limited company registered in
England and Wales.

Registered Office : 
Glebe Farm, Down Street, Dummer, Basingstoke, Hampshire, England RG25 2AD. 
Company Registration No. 2578478.

The information in this e-mail is 
confidential and for use by the addressee(s)
only. If you are not the 
intended recipient, please notify X-on immediately on +44(0)333 332  
and delete the
message from your computer. If you are not a named addressee 
you must not use,
disclose, disseminate, distribute, copy, print or reply 
to this email. Views
or opinions expressed by an individual
within this 
email may not necessarily
reflect the views of X-on or its associated 
companies. Although X-on routinely
screens for viruses, addressees should 
scan this email and any attachments
for
viruses. X-on makes no 
representation or warranty as to the absence of viruses
in this email or 
any attachments.








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

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

[Daniel Zanutti]

That solved! Don't know how I missed it.

Thank you Ben

On Wed, Feb 22, 2023 at 12:50 PM Ben Newlin  wrote:

> Daniel,
>
>
>
> I haven’t used the drouting module with partitions, but it looks like when
> you do that the name of the AVP no longer comes from the modparam setting
> but from the dr_partitions table. Do you have the carrier_id_avp value set
> for this partition in that table?
>
>
>
>
> https://opensips.org/docs/modules/3.2.x/drouting.html#param_db_partitions_table
>
>
> https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-PARTITIONS
>
>
>
>
>
> Ben Newlin
>
>
>
> *From: *Users  on behalf of Daniel
> Zanutti 
> *Date: *Tuesday, February 21, 2023 at 9:47 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *[OpenSIPS-Users] Carrier_ID not writing on DRouting when using
> partitions
>
> * EXTERNAL EMAIL - Please use caution with links and attachments *
>
>
> --
>
> 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
>
___
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,

I use the same record_route_preset() commands on my setup.

After more searches about my issue I found threads pointing invalid RURI and 
the cause to be Contact patching that should be done only for OPTIONS.

I made some more tests, removed contact patching on initial requests (also 
removed all my socket and destination uri rewriting routines) since then, all 
requests are forwarded like a charm.

If I well understood, because of contact patching, RURI was misleading / 
invalid, openSIPS had to find more parameters to be able to forward the 
requests.
So, it tried to use Route headers to find the socket and destination URI to use 
to forward the requests.

- It successfully did for the first route header, because it found the FQDN 
through domain module => that was the TLS part - useless to reach the 
destination.
- It didn’t succeed for the second route header, because it doesn’t try anymore 
to find FQDN through domain module => that was the SIP part, needed to know how 
to reach the destination but ignored because considered as "non local"

With incorrect contact, and so incorrect RURI, not being to solve socket and 
destination URI was a problem.

Now RURI is correct, it is used as is, and requests are forwarded to the next 
hop.

 « no socket found to match 2nd RR » warnings are still there in logs despite 
FQDN should match as it is present in domain module database.
The matching failure is no more a (real) issue for things to work.

There are probably things to do to improve the routines in order the warning 
not to appear anymore but
I’m far from an OpenSIPS specialist to know if that would really be beneficent 
if that was changed nor if that wouldn’t lead to other regressions or side 
effects. 

Anyway, thank you John for trying to help me solve my issue.

Regards

Daren


 




> Le 22 févr. 2023 à 17:31, John Burke  a écrit :
> 
> Hey Daren,
> 
> You can use any combo of interface / protocol that you want and 
> RR/loose-routing should handle it.  I have deployed SBCs in a similar 
> topology as you describe (no Topology Hiding).
> 
> In such a case, you should see a couple RR headers added by OpenSIPS: 1 for 
> the TLS leg to MS and 1 for the UDP leg.  The TLS leg should have the FQDN 
> that MS requires and you should have this stored in the domain module. The 
> UDP will contain the local socket for the UDP listener.
> 
> Have you confirmed the RR headers look good?  I dug up a snippet from an SBC 
> that handled both MS and non-MS traffic, where I was manually providing the 
> RR headers in the TLS/UDP case.
> 
> /*
> NAME:   HANDLE_RECORD_ROUTE
> DESIGN: Properly applies Record-Route headers to request. For Microsoft 
> Teams, it is
> a requirement to use FQDN in Route header. Therefore, if the 
> request is identified
> to be Microsoft Teams then use FQDN otherwise use IP.
> */
> route[HANDLE_RECORD_ROUTE] {
> xlog("L_INFO", "HANDLE_RECORD_ROUTE:INFO\n");
> 
> if (route(IS_MSTEAMS)) {
> if (route(IS_REQUEST_FROM_MSTEAMS))
> 
> record_route_preset("MY_IP:5060;r2=on","$rd:5061;transport=tls;r2=on");
> else
> 
> record_route_preset("$fd:5061;transport=tls;r2=on","MY_IP:5060;r2=on");
> return(1);
> }
> 
> record_route();
> }
> 
> 
> John
> 
> On 2/21/23 11:04 AM, Daren FERREIRA wrote:
>> 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 

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

[John Burke via Users]

Hey Daren,

You can use any combo of interface / protocol that you want and 
RR/loose-routing should handle it.  I have deployed SBCs in a similar 
topology as you describe (no Topology Hiding).


In such a case, you should see a couple RR headers added by OpenSIPS: 1 
for the TLS leg to MS and 1 for the UDP leg.  The TLS leg should have 
the FQDN that MS requires and you should have this stored in the domain 
module. The UDP will contain the local socket for the UDP listener.


Have you confirmed the RR headers look good?  I dug up a snippet from an 
SBC that handled both MS and non-MS traffic, where I was manually 
providing the RR headers in the TLS/UDP case.


/*
    NAME:   HANDLE_RECORD_ROUTE
    DESIGN: Properly applies Record-Route headers to request. For 
Microsoft Teams, it is
    a requirement to use FQDN in Route header. Therefore, if 
the request is identified

    to be Microsoft Teams then use FQDN otherwise use IP.
*/
route[HANDLE_RECORD_ROUTE] {
    xlog("L_INFO", "HANDLE_RECORD_ROUTE:INFO\n");

    if (route(IS_MSTEAMS)) {
    if (route(IS_REQUEST_FROM_MSTEAMS))
record_route_preset("MY_IP:5060;r2=on","$rd:5061;transport=tls;r2=on");
    else
record_route_preset("$fd:5061;transport=tls;r2=on","MY_IP:5060;r2=on");
    return(1);
    }

    record_route();
}


John

On 2/21/23 11:04 AM, Daren FERREIRA wrote:

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] 

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

[Ben Newlin]

Daniel,

I haven’t used the drouting module with partitions, but it looks like when you 
do that the name of the AVP no longer comes from the modparam setting but from 
the dr_partitions table. Do you have the carrier_id_avp value set for this 
partition in that table?

https://opensips.org/docs/modules/3.2.x/drouting.html#param_db_partitions_table
https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-PARTITIONS


Ben Newlin

From: Users  on behalf of Daniel Zanutti 

Date: Tuesday, February 21, 2023 at 9:47 PM
To: OpenSIPS users mailling list 
Subject: [OpenSIPS-Users] Carrier_ID not writing on DRouting when using 
partitions
 EXTERNAL EMAIL - Please use caution with links and attachments


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

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

[Sugar]

The opensip register module states the following:1.3.23. pn_providers (string)
A list of supported Push Notification providers.  While only 
three
possible values are defined by RFC 8599 ("apns", "fcm" and 
"webpush"),
non-standard values may be specified as well.


Default value is NULL
(not set).    1.3.24. 
pn_ct_match_params (string)
The minimally required list of RFC 8599 parameters 
(custom ones are
accepted as well) which must be present in a Contact 
URI and
identically match an existing binding in order for the 
binding
to be refreshed during a SIP re-REGISTER.  If at least 
one such
parameter is missing from a Contact header field URI, 
the module
will fall back to performing regular contact matching.

Note that if all above PN Contact URI parameters match 
an existing
binding, the match is considered to be successful 
regardless if
other parts of the SIP URI do not match (e.g. hostname, 
port,
other URI parameters, etc.).

After calling lookup() or
pn_process_purr(), the above PN-related
parameters will be automatically stripped from the 
resulting
Request and Contact URI event parameter, respectively.


Default value is 
"pn-provider, pn-prid, 
pn-param".    https://opensips.org/docs/modules/3.3.x/registrar.htmlLinphone, 
depending how far back you go, is not rfc 8599 compliant. It uses a nonstandard 
way of supporting push notifications using their own proxy flexisip.The 4.56 
version does support the rfc 8599 but it does not do the re-register event that 
is required in order to be fully compliant with the rfc and opensips. You will 
actually have to compile linphone changing three lines of code to make it do 
the REGISTER request. I found that on Google about a year ago (will look for 
and send later if you need it). Linphone doesn't support +sip.pnsreg feature so 
you will rely on the pn_trigger_interval in opensips (read module link I sent 
above regarding it).
 Original message From: HS  Date: 2/22/23  
1:56 AM  (GMT-06:00) To: OpenSIPS users mailling list 
 Subject: [OpenSIPS-Users] Push Notification - 
Location table has flag 0 v3.3 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-providerfirebase 
instead of fcmapp-id 
instead of

 pn-parampn-tok 
instead of

 pn-pridLocation 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