Problems with Volte on Openshift

[joaogro]

Dear all,

We are testing the docker open5gs + Kamailio solution on openshift. I was able to implement it using this repository, so thank you for the great work. The internet connection are working just fine, but I'm facing some problems with the calls. My envrioment is a commercial radio and eNodeB (Actually is a cu and du configuration), the eNodeB is configured in a VM that connects with the core EPC and IMS that are in a cluster Openshift. The calls are a bitty unstable, and most of the time it works only in one direction ( lets say from phone A to B for example). When I reboot the whole system, I notice that when I'm able to make a call (sometimes it just doesn't work) from phone A to B, after hung up the phone I cant make it anymore, in a problem similar to https://github.com/herlesupreeth/docker_open5gs/issues/76. But i also noticed that after doing the first call and disconnecting it, when I try to call from phone B to A, it also doesn't work, but after that if I try to call again from A to B it works. I did Two tests that I'm attaching here, the first one its just a normal call, the test2 is about the scenario that I explained earlier, with at least 4 calls made. I also put a diagram for more clear explanation of the scenario, since I'm not a native english speaker. Sorry for the long description of the issue and again, thank you guys for the amazing project. We used the iPhone 8 and iPhone 12 mini, the IPs of the services and containers are on the file IPS-svc-containeir. 16-03-pcaps.zip

[joaogro]

Hello there,

I made some more tests and installed the sms feature on my envrioment, now I don't see the sms errors on the pcap, only a 403 request timeout, 477 and 500 errors. I see also a different behavior with the dns than the one you shared on the docker open5gs volte guide. In most of this new tests I didn't experienced the strange behavior that i explained earlier, now I can make consecutive calls from Phone A to B for example, and not any from B to A. Sometimes after the phones being connected to the network for a while, they switch the one who can call, and then only phone B can call to phone A. I really dont know why it has this kind of behavior, I am new in the telecom field, so any help is appreciated. I'm attaching the pcaps, if you need anything please let me know, thank you again for the help. 22-03-pcaps.zip

[herlesupreeth]

There is NATing hapening between EPC and IMS. Kamailio IMS does not work with NAT. So following solutions you could opt for

1. Run kamailio IMS along with EPC as part of docker_open5gs that way there will be no NAT (since its between container running in same machine)
2. Complex solutio: Run point to point VPN between UPF container and P-CSCF container and bind UPF and P-CSCF to that VPN tun interfac IP (I personally would not recommend this as its a headache to configure)

[joaogro]

Thank you for the answer,

The problem is how should i approach the first solution? Because in my envrioment I have one pod to each of the kamailio and open5gs components, and in k8s (i think that this also apply to openshift) there is no NAT between pods and services. I tried a lot of different approaches, changing the IP in smf.yaml to the container IP of PCSCF instead of the service IP, using the container IP dns pod under the etc/resolv conf of the ims componentes and pcrf to point to the dns pod, using the container IPs insted of the services under the IMS_ZONE and EPC_ZONE of the dns server, but that didn't solve the problem. I'm still thinking that maybe my dns configurations pointing to the service IP can be a problem, or maybe there is indeed some kind of NATing between of of the components. I'm sending here my openshift configurations and some prints of my envrioment. Thank you for the fast response, I really appreciate it. kubernetes.zip

[herlesupreeth]

I haven't worked on openshift so unfortunately I cannot help you there. Hopefully someone else could help you.

[joaogro]

I see it, thank you for the help until now. I have some other questions, I was having some problems with your script to create the ogstun and ogstun 2 in the Openshift envrioment. Because of that I used the https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/ and made the tunnels the "old way". I'm executing the following command to create the ogstun2 iptables -t nat -A POSTROUTING -s 192.168.101.0/24 ! -o ogstun2 -j MASQUERADE. Would this be related to the NAT problem at all? Because, as I said earlier, apparently there is no NAT between pods on k8s or openshift.

[herlesupreeth]

Yes, thats the iptables rules to enable NATing

[joaogro]

Thank you very much for the fast response, I will look in to changing the way the tunnel are being created. I was able to use the script provided in this repository for tunneling in UPF, but only the internet (ogstun) worked properly, with the ogstun2 the UE wasnt able to connect to PCSCF. I see a attempt to connect with it, but there is no response on PCSCF and not even a request via UPF. Here are some of the pcaps, if you or anyone have any idea of how to manage this tunnel in k8s or openshift, it would be really helpful. Just to make it clear, when I use the NATing tunnel configuration, the UE attachs to the IMS, but I have the problem described above, and without it the scenario is the one showed in the pcaps, using the script provided. pcaps-30-03.zip

[herlesupreeth]

Alright!! I think i may have an idea whats the issue. I see the SIP REGISTER packets for the trace taken on UPF and ogstun2 but not in P-CSCF trace. Can you make sure all ports or atleast port 5060 (both TCP and UDP) are allowed from "0.0.0.0" IP in your firewall or similar concept in openshift?

Also, can you try giving the 10.254.4.27 IP of P-CSCF rather than 172.30.0.21?

[joaogro]

Sorry for the delay, I was thinking in a way to solve the tunnel problem, and I think I was able to do it (the UEs connected with the Core IMS using the script for the tunneling on UPF, without needing NAT), but now I have some other problems as well, unfortunately. So in order to use the Kamailio components and UPF in the same network structure, I used the parameter HostNetwork:True. When a pod is configured with HostNetwork:true, the applications running in such a pod can directly see the network interfaces of the host machine where the pod was started. An application that is configured to listen on all network interfaces will in turn be accessible on all network interfaces of the host machine( reference:https://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/). So I put the DNS, ICSCF, PCSCF, SCSCF, OSMOHLR, OSMOSMSC, SMSC, UPF in the Host network all of then sharing the same POD IP 192.168.120.212, using the HostPort configuration to expose the componentes. In the DNS I put the same IP for all of the IMS components, since they share the same IP. Everything connected as usual, the only strange behavior was on the FHOSS that became really slow to go up, and for users registration. The pods scenario can be seen in the image:

So with this configurations, and in all of the init.sh scripts the connections between the components arranged, I started the tests with the scrpit for the creation of the tunnels. The connection was successful but the call was not (the UE keeps trying to call and apparently don't find the endpoint), there is two tests, the first I connected the phones and then made a call from prone A to B and from B to A. I saw in that some IPs that were still there but shouldn't (PCSCF service IP, since I'm making the connections via POD IP), in the second test there is not such IP. In the second test I did the same but with only one call in the process. I'm sharing the pcaps and the configurations of my setup bellow. Sorry for the long explanation on the issue and again, thank you very much for the help until now. kubernetes.zip

[joaogro]

Apparently the pcaps are to big for uploading here, so I had upload it in here: Google drive:https://drive.google.com/file/d/1wjbRA63VZH-XyUGalhUjnyjt-T7LSiOp/view?usp=sharing

[herlesupreeth]

Closing this since this repo is not testing in openshift environment