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

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

Open
lglhust opened this issue May 22, 2024 · 15 comments
Open

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

lglhust opened this issue May 22, 2024 · 15 comments

Comments

@lglhust
Copy link

lglhust commented May 22, 2024

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

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

lglhust commented May 24, 2024

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

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

lglhust commented May 27, 2024

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

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

lglhust commented May 29, 2024

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

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

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

Test-VoNR-17_min_DROP.pcap.gz
PFA

@ASHWIN990
Copy link

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

@herlesupreeth
Copy link
Owner

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

@ASHWIN990
Copy link

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

@herlesupreeth
Copy link
Owner

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

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

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants