Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bearer setup for unidirectional media #3291

Open
srinidhikrs opened this issue Jun 25, 2024 · 9 comments
Open

Bearer setup for unidirectional media #3291

srinidhikrs opened this issue Jun 25, 2024 · 9 comments
Labels
Housekeeping:ToClose Issues reviewed and closed. Old requests, issues which are not bug, feature or documentation request type:bug Open5GS bug

Comments

@srinidhikrs
Copy link

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 :

  1. 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.

  2. 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

@herlesupreeth
Copy link
Contributor

Here are my observations in unidir_media.zip,

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

image

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

image

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

what error message are you referring to here?

@srinidhikrs
Copy link
Author

  1. 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)

  2. 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.3500022;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

@herlesupreeth
Copy link
Contributor

herlesupreeth commented Jun 27, 2024

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)

image

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.

@acetcom
Copy link
Member

acetcom commented Jun 27, 2024

@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

@herlesupreeth
Copy link
Contributor

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
Copy link
Author

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

@acetcom acetcom added the type:bug Open5GS bug label Jul 8, 2024
@acetcom
Copy link
Member

acetcom commented Jul 8, 2024

@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

@herlesupreeth
Copy link
Contributor

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

Thanks @srinidhikrs for confirming the fix.

@acetcom
Copy link
Member

acetcom commented Jul 8, 2024

@herlesupreeth and @srinidhikrs

Thank you so much for your effort.
Sukchan

@acetcom acetcom added the Housekeeping:ToClose Issues reviewed and closed. Old requests, issues which are not bug, feature or documentation request label Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Housekeeping:ToClose Issues reviewed and closed. Old requests, issues which are not bug, feature or documentation request type:bug Open5GS bug
Projects
None yet
Development

No branches or pull requests

3 participants