[BUG] 3.1.1: outgoing-expires argument not honored by mid_registrar_save()

[gmaruzz]

OpenSIPS version you are running

version: opensips 3.1.1 (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 6.3.0

Describe the bug
outgoing-expires argument not honored by mid_registrar_save()

To Reproduce
mid_registrar_save("location", "c1f",,1234567,"service");

results in using the outgoing_expires set in module parameter, eg same as if function argument is not used

Expected behavior
argument to mid_registrar_save override value set by module parameter

Relevant System Logs

OS/environment information

• Operating System: Debian 9
• OpenSIPS installation: debs
• other relevant information:

Additional context

[liviuchircu]

My apologies for the long wait, @gmaruzz! And thank you for the accurate report! 🎉🎉

[gmaruzz]

seems the problem is still there...

using latest nightly

3.1.1~20210113~2c1492bd5-1

opensips -V
version: opensips 3.1.1 (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.
git revision: 2c1492b
main.c compiled on with gcc 6.3.0

[gmaruzz]

for config and logs, see:

#2351

[liviuchircu]

@gmaruzz, I used the exact settings and function calling convention posted in #2351, in the following scenario, on latest 3.1 (71b0aa5):

      UAC
      | ^
      v |
(mid-reg active) -----> (mid-reg backup)
      | ^
      v |
 (main registrar)

Here is the REGISTER flow:

2021/01/15 17:48:48.210953 192.168.0.199:7000 -> 192.168.0.240:5060
REGISTER sip:192.168.0.240 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.199:7000;branch=z9hG4bK-22440-1-0
From: sipp <sip:sipp@192.168.0.199>;tag=1
To: <sip:sipp@192.168.0.240>
Call-ID: 1-22440@192.168.0.199
CSeq: 1 REGISTER
Contact: sip:sipp@192.168.0.199:7000
Max-Forwards: 5
Expires: 15
User-Agent: SIPp/Linux
Content-Length: 0

2021/01/15 17:48:48.213700 192.168.0.240:5060 -> 192.168.0.199:5070
REGISTER sip:192.168.0.199:5070 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.240:5060;branch=z9hG4bKd798.3c4e52f1.0
Via: SIP/2.0/UDP 192.168.0.199:7000;branch=z9hG4bK-22440-1-0
From: sipp <sip:sipp@192.168.0.199>;tag=1
To: <sip:sipp@192.168.0.240>
Call-ID: 1-22440@192.168.0.199
CSeq: 1 REGISTER
Contact: <sip:sipp@192.168.0.240:5060>
Max-Forwards: 4
Expires: 12345
User-Agent: SIPp/Linux
Content-Length: 0

... so the 12345 expires is honored! Could please post a .pcap of what's happening in your case? If I were to give a wild guess, I'd say your startup script is broken and your opensips doesn't get restarted properly after rebuilding your binaries. Could you do a opensips-cli -x mi uptime, just to infirm this for me quickly? Thank you!

[liviuchircu]

Wait, I think I got something. It seems that when I use a Contact with ";expires=15" header param, the 12345 expires is not honored anymore. Digging deeper...

[liviuchircu]

Just submitted a fix for the above, @gmaruzz. Let me know if it fixes your scenario.

[gmaruzz]

this one will go in the nightly deb build?

or, maybe it is better if I build the debs myself from the 3.1 branch?

[gmaruzz]

(opensips-cli): mi uptime
{
"Now": "Fri Jan 15 17:33:57 2021",
"Up since": "Fri Jan 15 09:51:09 2021",
"Up time": "27768 [sec]"
}
(opensips-cli):

[liviuchircu]

Yes, it will go in nightly build. Proceed as it suits you best -- I am more than OK to review the results later ;)

[gmaruzz]

have a nice weekend!
I will organize the package build, so in future I'll be more efficient!
:)

[gmaruzz]

(btw, maybe there is some interaction with the "pn" module parameters. like they change the code path? We'll see... anyway, as soon as I build the packages I'll be able to be more quick)

[liviuchircu]

You were right, in a way. Your PN contact was using a "7 day" expiration (a good adjustment to RFC 8599, btw!), which confused mid-registrar (since it's larger than your "outgoing_expires": 12345). Regardless, the outgoing expiration should still be 12345, and not 604800. All should be good now.

[gmaruzz]

I will give feedback when tested

[gmaruzz]

outgoing-expires works!