VoNR Calls with latest version of "test" branch are failing because of commit 3468d50ef

[NUCLEAR-WAR]

Issue Description

VoNR Calls are failing when using the latest version in "test" branch, creating PDUSession is failing.
Calls were working before, so, I did a search for the offending commit, I found the one that causes the issue 3468d50ef
Using the latest version from "Test" branch and reverting the changes done in the mentioned commit solves the issue.

Setup Details

srsRAN from Test branch
UHD Driver 4.7.0
Ubuntu 24.04.01
SDR : B210mini with GPSDO
IMS+5GC from docker_open5gs repo branch "exp_5g_ims_pyhss"

Expected Behavior

the call shall be successful -- creating/modifying PDUSession shall success

Actual Behaviour

PDU Session modification command is not completed as expected.

Steps to reproduce the problem

using the setup mentioned above attach two devices to the network and do a voice call.
The call will fail.

Additional Information

I attached log files from two test one with commit "3468d50ef" and and without it using the latest version of "Test" branch.
PCAPs and logs with Info log-level.

with_commit_3468d50ef.zip
without_commit_3468d50ef.zip

[robertfalkenberg]

In the logs "with commit" the SRB reaches max-retx

2024-12-25T22:21:28.182640 [RLC     ] [W] du=0 ue=0 SRB1 DL: Reached maximum number of RETX. sn=6 retx_count=8
2024-12-25T22:21:28.182646 [DU-MNG  ] [W] ue=0: RLF detected with cause="RLC max ReTxs reached". Timer of 4000 msec to release UE started...
2024-12-25T22:21:28.182653 [DU-MNG  ] [I] ue=0: DRB traffic stopped

after sending this message (from MAC PCAP):

569	22:21:27,778095			NR RRC/NAS-5GS	208		6			RRC Reconfiguration, DL NAS transport, PDU session modification command  [134-bytes]  (Padding 38 bytes) 

It looks like the UE didn't like that message and silently jumped off from the cell (eventually reaching max-retx).

I compared the content of this message (No. 569) with the version "without commit" (No. 668), and found the following difference:

Version with:

Version without:

The difference is that the unmodified version adds this field:

cipheringDisabled: true (0)

Are you using a custom QoS config?

[NUCLEAR-WAR]

Hi @robertfalkenberg,
I used the qos.yml from "test" branch :
https://github.com/srsran/srsRAN_Project/blob/test/configs/qos.yml

[robertfalkenberg]

Thanks for the feedback,

I wonder the logs reflect different QoS values, e.g.

2024-12-25T22:20:58.117707 [CONFIG  ] [I] Input configuration (only non-default values): 
qos:
...
  - five_qi: 9
...
    pdcp:
...
      rx:
        sn: 12
        t_reordering: 80

but from qos.yml:

qos:
...
  -
    five_qi: 9 # E.g. Buffered video streaming, TCP-based traffic
    pdcp:
...
      rx:
        sn: 18
        t_reordering: 220

Can you please share the following:

• Full command line of how the gNB is started.
• Content of involved config files.

Which core are you using?

[NUCLEAR-WAR]

here are the logs/pcaps/configs from new test:

new_test.zip

also the 5qi=9 you are showing is for internet, not sure why srsRAN is reading the value wrong, the one that is used during the call is 5qi=1 for RTP and 5 for signaling, thos 5qi are being reflected correctly in the log

I use open5gs as 5GC and Kamailio for IMS.

gnb is being started with this command :

./gnb -c gnb_testplmn.yml -c qos.yml

[robertfalkenberg]

Thanks for the feedback and the new logs.

Since I do not have a Kamailio IMS setup at hand, I have to guess here.
According to your bissection to the problematic commit and the extra field cipheringDisabled appeared in the pcaps, I suspect the issue being somewhere there. I assume the IMS doesn't like to disable ciphering.

The gNB's built-in default QoS settings still set the following fields explicitly:

    pdcp_cfg.ciphering_required            = true;
    pdcp_cfg.integrity_protection_required = false;

but when loading from qos.yml they are not set (anymore) after that commit.
Although the value shouldn't matter because they will be overwritten at creation of the DRB, it's still worth to double-check:

Can you please check if your experiment works and succeeds without -c qos.yml which will use the built-in defaults.
Regardless of the outcome, please share the set of logs here.

[NUCLEAR-WAR]

I ran a new text without qos.yml, It worked fine, I got first a weird issue, when attaching the second device the first one disconnected, but the issue disappeared, run a few test after it and it was not happening any more.

Here are the new pcap/logs

test_wthout_qos-yml.zip