Bearer setup for unidirectional media

Question

Bearer setup for unidirectional media

srinidhikrs opened this issue 25 days ago · comments

Hi,

I am trying to test some Volte service using Volte testbed (srsenb + open5gs + kamailio IMS + proprietary application server and MRF)

Service details : 1) Volte/ViLTE call is made from A-party to B-party. 2)B-party phone starts ringing 3) Application server connects media between A-party and MRF (using SIP Update) to play early media (video+audio) to A-party. 4)When B-party answers call , Application server connects media between A-party and B-party using Sip Update.

Observations :

When Application server tries to establish unidirectional media between A-party and MRF (using a=sendonly attribute in SDP of SIP update ), open5gs fails to setup unidirectional media bearer setup with some error messages.
When Application server tries to establish bidirectional media between A-party and MRF (using a=sendrecv attribute in SDP of SIP update ), open5gs succeeds to setup bidirectional media bearer setup without error messages.

Attaching logs (enb logs + open5gs logs + tcpdump pcap ) for both the scenarious.

Please help in fixing the issue when unidirectional media from MRF to A-party is setup

Thanks
Srinidhi
bidir_media.zip
unidir_media.zip

Supreeth Herle · Answer 1 · Thu Jun 27 2024 17:25:48 GMT+0800 (China Standard Time)

Here are my observations in unidir_media.zip,

The UPDATE from MRF is having both sendrecv and sendonly, see screenshot below

I dont see any issue in open5gs since "Modify EPS bearer context accept" is received from UE

open5gs fails to setup unidirectional media bearer setup with some error messages.

what error message are you referring to here?

srinidhikrs · Answer 2 · Thu Jun 27 2024 17:47:15 GMT+0800 (China Standard Time)

The Update message from MRF has sendrecv for audio and sendonly for video (update msg from MRF and 200 OK from a-party handset attached below)
The errors which i am referring to (around same time when update and 200 OK Update happens) :

sgwc.log:

06/25 20:32:08.349: [sgwc] ERROR: [001010123456793] Error Indication(Dedicated Bearer) from SMF (../src/sgwc/sxa-handler.c:1501)

smf.log:

06/25 20:32:08.351: [pfcp] DEBUG: [11] REMOTE Commit peer [127.0.0.7]:8805 (../lib/pfcp/xact.c:470)
06/25 20:32:08.351: [smf] ERROR: [001010123456793:ims] Error Indication from SGW-C (../src/smf/n4-handler.c:1366)
06/25 20:32:08.351: [pfcp] DEBUG: [23] LOCAL Create peer [127.0.0.7]:8805 (../lib/pfcp/xact.c:110)

sgwu..log :

06/25 20:32:08.348: [core] TRACE: BUILD L#0 [Report Type] T:39 L:1 I:0 (cls:0 vsz:16) off:0x7f84c8008db8 (../lib/core/ogs-tlv-msg.c:386)
06/25 20:32:08.348: [core] TRACE: BUILD C#4 [Error Indication Report] T:99 I:0 (vsz=32) off:0x7f84c8009fe0 (../lib/core/ogs-tlv-msg.c:364)
06/25 20:32:08.348: [core] TRACE: BUILD L#0 [F-TEID] T:21 L:0 I:0 (cls:9 vsz:24) off:0x7f84c8009fe8 (../lib/core/ogs-tlv-msg.c:386)
06/25 20:32:08.348: [pfcp] DEBUG: [12] LOCAL UPD TX-56 peer [127.0.0.3]:8805 (../lib/pfcp/xact.c:192)

upf.log

06/25 20:32:08.348: [pfcp] TRACE: DST:ac1368c7 00000000 00000000 00000000/ffffffff 00000000 00000000 00000000 (../lib/pfcp/rule-match.c:187)
06/25 20:32:08.348: [upf] ERROR: [127.0.0.7] Send Error Indication [TEID:0x3c89] to [127.0.0.6] (../src/upf/gtp-path.c:474)
06/25 20:32:08.351: [upf] TRACE: PAA IPv4:10.45.0.3 (../src/upf/rule-match.c:61)
06/25 20:32:08.351: [pfcp] TRACE: PROTO:17 SRC:ac1368c7 0a2d0003 84c69c52 0028f450 (../lib/pfcp/rule-match.c:165)

enb.log :

2024-06-25T15:02:08.368871 [GTPU ] [D] Received 28 bytes from S1-U interface
2024-06-25T15:02:08.368873 [GTPU ] [E] gtpu_read_header - Unhandled GTP-U Extension Header Type: 0x40
2024-06-25T15:02:08.369369 [PHY ] [D] [ 2069] Setting TTI=2069, tx_time=54:0.909569 to worker 0

Please help in identifying and fixing the problem

UPDATE sip:00000003@10.45.0.3:50003;alias=10.45.0.3~~50002~~2;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 172.19.118.233:5060;branch=z9hG4bK00000000000000000000000000000000.e4782ab0
To: sip:00000003@ims.mnc001.mcc001.3gppnetwork.org;tag=5RV4L58owWD2u3
From: tel:00000004;phone-context=ims.mnc001.mcc001.3gppnetwork.org;tag=dwSSAQ190mvFJ6
Call-ID: kavtIW23lEgc89Lq3WT
CSeq: 3 UPDATE
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0010100010019B01
Max-Forwards: 70
Route: sip:mo@172.19.104.199:6060;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr,sip:mo@172.19.104.199:6060;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr,sip:mo@172.19.104.199:6102;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr,sip:mo@172.19.104.199:6102;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr
Require: precondition
Record-Route: sip:mt@172.19.104.199:5103;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=7;did=105.9b31;lr,sip:mt@172.19.104.199;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=7;did=105.9b31;lr,sip:mt@172.19.104.199:6060;lr=on;ftag=5RV4L58owWD2u3;did=105.8471;lr,sip:mo@172.19.104.199:6060;lr=on;ftag=5RV4L58owWD2u3;did=105.7471;lr,sip:172.19.118.233:5060;lr,sip:mo@172.19.104.199:6060;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr,sip:mo@172.19.104.199:6060;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr,sip:mo@172.19.104.199:6102;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr,sip:mo@172.19.104.199:6102;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr
User-Agent: Onmobile SIP 1.0
Content-Type: application/sdp
Content-Length: 797

v=0
o=onmobilesipua 3928317704 3928317704 IN IP4 172.19.118.233
s=phone-call
c=IN IP4 172.19.118.233
t=0 0
m=audio 23002 RTP/AVP 97 98 105
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR-WB/16000/1
a=rtpmap:105 telephone-event/8000
a=sendrecv
a=fmtp:97 octet-align=0
a=fmtp:98 octet-align=0
a=ptime:20
a=content:g.3gpp.cat
a=content:g.3gpp.cat
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
m=video 26504 RTP/AVPF 114
a=rtpmap:114 H264/90000
a=sendonly
a=fmtp:114 packetization-mode=1;profile-level-id=42C01E
a=content:g.3gpp.cat
a=framerate:15
a=content:g.3gpp.cat
a=tcap:1 RTP/AVPF
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.19.118.233:5060;branch=z9hG4bK00000000000000000000000000000000.e4782ab0
To: sip:00000003@ims.mnc001.mcc001.3gppnetwork.org;tag=5RV4L58owWD2u3
From: tel:00000004;phone-context=ims.mnc001.mcc001.3gppnetwork.org;tag=dwSSAQ190mvFJ6
Call-ID: kavtIW23lEgc89Lq3WT
CSeq: 3 UPDATE
User-Agent: OPPO_CPH2553_11_C.30_240416
Contact: sip:00000003@10.45.0.3:50003;transport=tcp;+sip.instance="urn:gsma:imei:86854406-424767-0";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;audio;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting
Session-Expires: 60000;refresher=uas
Supported: 100rel, replaces, timer
Record-Route: sip:mo@172.19.104.199:6102;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr, sip:mo@172.19.104.199:6102;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=8;did=105.8b31;lr, sip:mo@172.19.104.199:6060;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr, sip:mo@172.19.104.199:6060;r2=on;lr=on;ftag=5RV4L58owWD2u3;did=105.6471;lr, sip:172.19.118.233:5060;lr, sip:mo@172.19.104.199:6060;lr=on;ftag=5RV4L58owWD2u3;did=105.7471;lr, sip:mt@172.19.104.199:6060;lr=on;ftag=5RV4L58owWD2u3;did=105.8471;lr, sip:mt@172.19.104.199;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=7;did=105.9b31;lr, sip:mt@172.19.104.199:5103;transport=tcp;r2=on;lr=on;ftag=5RV4L58owWD2u3;rm=7;did=105.9b31;lr
Require: precondition
Content-Type: application/sdp
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0010100010019B01
Content-Length: 863

v=0
o=- 43 44 IN IP4 10.45.0.3
s=mtk voice call
c=IN IP4 172.19.104.199
b=AS:445
b=RS:5562
b=RR:7087
t=0 0
m=audio 33980 RTP/AVP 97 105
b=AS:29
b=RS:362
b=RR:1087
a=maxptime:240
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR/8000/1
a=rtpmap:105 telephone-event/8000
a=fmtp:97 mode-change-capability=1;octet-align=0;max-red=0
a=fmtp:105 0-15
a=sendrecv
a=rtcp:33981
a=ptime:20
m=video 34002 RTP/AVPF 114
b=AS:416
b=RS:5200
b=RR:6000
a=tcap:1 RTP/AVPF
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:114 H264/90000
a=fmtp:114 profile-level-id=42C01E;packetization-mode=1;sprop-parameter-sets=Z0LAHo2NQPAo01BQICB4RCKc,aMpDyA==
a=recvonly
a=rtcp:34003

Thanks
Srinidhi

Supreeth Herle · Answer 3 · Thu Jun 27 2024 19:45:06 GMT+0800 (China Standard Time)

I think I found where the issue is, its in the open5gs

After "Update Bearer Request" (packets 462-465) and then sending "Modify EPS Bearer Contest Request", the PFCP session PDRs should have been updated but rather its been deleted resulting in GTP Error Indication (packet 576)

I am not sure Suckhan has the spare time to fix this. I can take a look later in the day to see whether I can fix this or not.

Sukchan Lee · Answer 4 · Thu Jun 27 2024 19:48:44 GMT+0800 (China Standard Time)

@herlesupreeth and @srinidhikrs

All of my time is currently being spent on fixing the ogs_pool_cycle() issue, so I haven't gotten around to looking at the other issues yet.

I'll be working on them in order, and I'll be looking into these issues at that point.

Thanks a lot!
Sukchan

Supreeth Herle · Answer 5 · Mon Jul 08 2024 01:45:32 GMT+0800 (China Standard Time)

Hey @srinidhikrs please give this branch (https://github.com/herlesupreeth/open5gs/tree/fix_bearer_update) a try. I have tried to fix the issue with unidirectional audio. Let me know if fixes your issue. Please attach a pcap eitherway

srinidhikrs · Answer 6 · Mon Jul 08 2024 15:24:11 GMT+0800 (China Standard Time)

Hi,

I also included the fix provided in issues3240 branch (for smf crash) (main...issues3240)

It seems to be fine and no GTP errors were seen during the VoLTE call. I have attached the pcap file. Please validate once.

Thanks
Srinidhi

volte_test_update_bearer.zip

Sukchan Lee · Answer 7 · Mon Jul 08 2024 15:30:30 GMT+0800 (China Standard Time)

@srinidhikrs and @herlesupreeth

I've merged issues3240 branch to the main branch.

If @herlesupreeth do a pull request with fix_bearer_update branch, I'll merge it.

Thanks you so much!
Sukchan

Supreeth Herle · Answer 8 · Mon Jul 08 2024 16:32:48 GMT+0800 (China Standard Time)

Thank you @acetcom for the gtp xact fix. I have issued the pull request.

Thanks @srinidhikrs for confirming the fix.

Sukchan Lee · Answer 9 · Mon Jul 08 2024 16:35:10 GMT+0800 (China Standard Time)

@herlesupreeth and @srinidhikrs

Thank you so much for your effort.
Sukchan