I am currently working with your docker_open5gs setup and have successfully deployed the IMS core. I was able to establish VoLTE calls and the basic call flow is working. However, I am facing an issue where the call disconnects shortly after establishment due to DRB_LOST.
From the logs and UE traces, it appears that the dedicated bearer is created correctly, but the call is terminated after a few seconds. I suspect the issue may be related to the TFT filters or RTP flow matching for the dedicated bearer. We were sending incoming SDP params in TFT earlier. It is corrected later, but I still see the failure. Earlier it was after 8 seconds, but now after correcting the TFT, the call is dropped after 4 seconds.
My current scenario is as follows:
- Incoming call from PSTN to an IMS user.
- RTP is anchored on an RTP engine (PCMU to AMR transcoding).
- SDP offer contains the RTP engine IP and port.
- The UE returns its media IP and ports in the 200 OK.
- A dedicated bearer is created with TFT filters for RTP and RTCP.
Offer (INVITE to B) – RTPENGINE side
IP: 172.22.0.16
RTP: 49978, RTCP: 49979
Answer (200 OK from B UE) – UE side
IP: 192.168.101.17
RTP: 50016, RTCP (implicit): 50017
In the TFT, for each pair of filters:
IPv4 remote address = 172.22.0.16 → this is the RTPENGINE IP
Downlink filter (direction = DL only)
Remote port: 49978 / 49979 → RTPENGINE RTP/RTCP
Local port: 50016 / 50017 → UE RTP/RTCP
→ “from RTPENGINE(172.22.0.16:49978/49979) to UE(…:50016/50017)”
Uplink filter (direction = UL only)
Local port: 50016 / 50017 → UE RTP/RTCP
Remote port: 49978 / 49979 → RTPENGINE RTP/RTCP
→ “from UE(…:50016/50017) to RTPENGINE(172.22.0.16:49978/49979))”
So all 4 TFT filters are exactly consistent with the SIP:
UL: UE 192.168.101.17:50016/50017 → RTPENGINE 172.22.0.16:49978/49979
DL: RTPENGINE 172.22.0.16:49978/49979 → UE 192.168.101.17:50016/50017
Despite this, the UE eventually releases the bearer with a DRB_LOST indication and the call drops.
I am currently working with your docker_open5gs setup and have successfully deployed the IMS core. I was able to establish VoLTE calls and the basic call flow is working. However, I am facing an issue where the call disconnects shortly after establishment due to DRB_LOST.
From the logs and UE traces, it appears that the dedicated bearer is created correctly, but the call is terminated after a few seconds. I suspect the issue may be related to the TFT filters or RTP flow matching for the dedicated bearer. We were sending incoming SDP params in TFT earlier. It is corrected later, but I still see the failure. Earlier it was after 8 seconds, but now after correcting the TFT, the call is dropped after 4 seconds.
My current scenario is as follows:
Offer (INVITE to B) – RTPENGINE side
IP: 172.22.0.16
RTP: 49978, RTCP: 49979
Answer (200 OK from B UE) – UE side
IP: 192.168.101.17
RTP: 50016, RTCP (implicit): 50017
In the TFT, for each pair of filters:
IPv4 remote address = 172.22.0.16 → this is the RTPENGINE IP
Downlink filter (direction = DL only)
Remote port: 49978 / 49979 → RTPENGINE RTP/RTCP
Local port: 50016 / 50017 → UE RTP/RTCP
→ “from RTPENGINE(172.22.0.16:49978/49979) to UE(…:50016/50017)”
Uplink filter (direction = UL only)
Local port: 50016 / 50017 → UE RTP/RTCP
Remote port: 49978 / 49979 → RTPENGINE RTP/RTCP
→ “from UE(…:50016/50017) to RTPENGINE(172.22.0.16:49978/49979))”
So all 4 TFT filters are exactly consistent with the SIP:
UL: UE 192.168.101.17:50016/50017 → RTPENGINE 172.22.0.16:49978/49979
DL: RTPENGINE 172.22.0.16:49978/49979 → UE 192.168.101.17:50016/50017
Despite this, the UE eventually releases the bearer with a DRB_LOST indication and the call drops.