search

herlesupreeth / docker_open5gs

Docker files to run open5gs + IMS + eNB + gNB + NR-UE in a docker
BSD 2-Clause "Simplified" License
279 stars 156 forks source link

Call dropped by rtp timeout and no response for sip bye #323

Open lglhust opened 1 month ago

lglhust commented 1 month ago

Dear herlesupreeth, I made a call from UE A to UE B, the call dropped after about 1 min. UE A send bye(cause: rtp timeout) to UE B. Before PCSCF forwarded it to UE B, UE A sent bye to pcscf. Thus two transaction for sip bye existed in pcscf, UE A and UE B. But none of them could receive reply from the other side. I checked the tcp port and esp spi, found no problem. I didn't get the reason of the two questions:

    1 . Why UE A send bye with cause rtp timeout;  i saw the rtp packet  was continuous.
    2.  Why pcscf and UE A/B could not receive response from each other.

    The attachment is the packet capture and ims log.
    Thanks.

log.zip

herlesupreeth commented 1 month ago

Can you please send me the pcap without any filter and on 'any' interface. Also, are you running EPC on a separate machine than the IMS?

lglhust commented 1 month ago

I tried twice.

First try: UE A and B registered, and made a call . After about 70s, call dropped . After about 9s, i made a call again and it failed.

Second try: Letting UE A and UE B into airplane mode and re-registered. when registration finished, i made a call .After about 70s, call dropped . And then i made a call again and it seemed the subsequent call couldn't work unless to register again.

I found in first drop, UE sent sip bye. And in second drop, UE sent rtcp good bye at first. Only two UEs access to base station and the core, i think rtp-timeout may not caused by radio link quality.

The twice logs and packets capture is continuous without interrupt. The environment configuration: ubuntu version is 22.04; kamailio is from docker; rtpengine Version: 10.4.1.7 iptables: Chain INPUT (policy ACCEPT) target prot opt source destination rtpengine udp -- anywhere anywhere

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Chain rtpengine (1 references) target prot opt source destination RTPENGINE udp -- anywhere anywhere RTPENGINE id:0

The core, IMS and rtpengine are in the same machine with no NAT device exists. ims-drop.zip

Thanks a lot.

herlesupreeth commented 1 month ago

First try: UE A and B registered, and made a call . After about 70s, call dropped . After about 9s, i made a call again and it failed.

Can you tell me which eNB are you using? I checked the diameter signalling and RTP ports in ims-1.pcap and all are correct. Still I see UE replying "RTP timeout" which doesnt make any sense.

image

Can you elaborate on where you are running EPC + IMS, like a VM in openstack etc? also, check whether RTP ports are allowed on that machine and router?

I dont see S1AP signalling in your pcap, is it possible to post that as well?

lglhust commented 1 month ago

I restarted the core and tried again. One UE was 172.60.1.61, another one was 172.60.1.81 this time. The eNB is a Indoor small cell station. I just run the core and ims on physical machine, RTP ports is allowed. Thanks. ims.zip

herlesupreeth commented 1 month ago

@lglhust I see in the above pcap that call is successful and RTP is flowing correctly between UEs.

And the call ended because eNB notified something to Core Network (I cant know what happened because its commercial small cell), which makes MME trigger Delete Session Request towards SGW-C --> PGW-C (SMF)

image

I would check the logs/traces on the eNB to know what eNB is sending to MME

lglhust commented 1 month ago

image

It seemed as another ue to be detached from capture packet 125360, not any one on th call, and the call was in progress in later time. But i cannot found the corresponding s1ap packet.

herlesupreeth commented 1 month ago

My bad, you are right. That Delete Session Request was for someother UE.

Then, I have no idea why UE is sending RTP Timeout. I see RTP flowing just fine and dedicated bearers are setup correctly

image

ASHWIN990 commented 3 weeks ago

Same Issue I'm also facing but the call is dropping after 17 min and 40 sec, as one UE is sending BYE and CAUSE is RTP Timeout

ASHWIN990 commented 3 weeks ago

Test-VoNR-17_min_DROP.pcap.gz PFA

ASHWIN990 commented 3 weeks ago

Hi @herlesupreeth let me know if you need some logs..

herlesupreeth commented 3 weeks ago

Hey, if you are testing VoNR it wont work as there is no mechanism to provide QoS parameters from P-CSCF to PCF.

ASHWIN990 commented 3 weeks ago

Hi sir, @herlesupreeth I'm testing the sa-vonr-deploy.yaml setup with your yesterday's push, still has the same issue.

herlesupreeth commented 3 weeks ago

Hey, as mentioned above if you are trying to place a call between UEs over 5G RAN (i.e. using sa-vonr-deploy.yaml), then it wont work since the SBI interface between P-CSCF and PCF to provide QoS information is not implemented in kamailio yet. As a result, the call will be disconnected by the UE since there is no dedicated bearer created for RTP traffic to flow.

driesken commented 1 week ago

Hey, as mentioned above if you are trying to place a call between UEs over 5G RAN (i.e. using sa-vonr-deploy.yaml), then it wont work since the SBI interface between P-CSCF and PCF to provide QoS information is not implemented in kamailio yet. As a result, the call will be disconnected by the UE since there is no dedicated bearer created for RTP traffic to flow.

Hi @herlesupreeth , do you think it will be a possibility in the near future though? It looks like Elena-Ramona Modroiu has shown VoNR in a demo at Kamailio World, but unfortunately, no specific details were published.

herlesupreeth commented 1 week ago

Hi @herlesupreeth , do you think it will be a possibility in the near future though?

Definitely, the kamailio cfg files enabling VoNR is expected to be public in couple of months (dont know the exact date though)