search

herlesupreeth / Kamailio_IMS_Config

Fixed version of Kamailio IMS configuration files for basic calling
45 stars 36 forks source link

200OK/REGISTER for deregistration procedure is not ESP encapsulated #4

Closed riccardv closed 3 years ago

riccardv commented 3 years ago

Hi Supreeth,

congratulations for the jobs, it is not easy the setup of an IMS test bed.

I'm not using the docker installation but directly the Kamailio sources and your IMS_Config with few modification reflecting my environment where I'm using a UE simulator VoLTE capable.

I observe that during the de-registration phase the 200OK/REGISTER reply from P-CSCF is not ESP encapsulated because the S-CSCF send NOTIFY to P-CSCF with terminated reg-state before the 200OK/REGISTER and then P-CSCF destroy the IPsec SA too early. The 200OK is not accepted to UE because IPsec layer discard this message because is not protected and the De-registration fails after some retransmissions.

I don't know if it is a Kamailio IMS modules problem or it may solved with tuning configuration files, so I would like ask if you observe the same behaviour.

Note: I'm not using contact alias and not pinging because UE are not under NAT, this is a real VoLTE IMS configuration like (no VoWiFI).

herlesupreeth commented 3 years ago

I observe that during the de-registration phase the 200OK/REGISTER reply from P-CSCF is not ESP encapsulated because the S-CSCF send NOTIFY to P-CSCF with terminated reg-state before the 200OK/REGISTER and then P-CSCF destroy the IPsec SA too early. The 200OK is not accepted to UE because IPsec layer discard this message because is not protected and the De-registration fails after some retransmissions.

I don't know if it is a Kamailio IMS modules problem or it may solved with tuning configuration files, so I would like ask if you observe the same behaviour.

Internal mechanism is more or less like that in Kamailio source code, there is no mechanism in place for a delayed deletion of IPSec tunnels. This cannot be solved by tuning config files unfortunately

sajem2020 commented 3 years ago

hi could you help me for installing UE simulator for testing VoLTE? thank you

herlesupreeth commented 3 years ago

@sajem2020 Please stop spamming under unrelated issues. This repository does NOT provide a UE simulator to test VoLTE

herlesupreeth commented 3 years ago

@riccardv Please use the latest changes in kamailio source code (from my forked kamailio repo) and configuration file from Kamailio_IMS_Config repo, this issue has been fixed. Let me know if you still face this issue

riccardv commented 3 years ago

Hi @herlesupreeth , The patch solve the issue thanks! Also the NOTIFY to indicate the termination of reg event arrives correctly over ESP.

Enabling the REGINFO flag anyway the issue is still present. Feel free to add my pull request on kamailio project on your branch.

thanks

herlesupreeth commented 3 years ago

I have now fixed this issue in the latest commit even in the case of REGINFO flag enabled. Let me know if that works for you. Thanks a lot

riccardv commented 3 years ago

Hi @herlesupreeth , last fix solve also the case of REGINFO flag enabled.

Out ot topic: A comment regarding SA5 to SA8 ( Fix for some broken In-Dialog routing), it seams broke the Requests iniziated by terminated UE. For example BYE from MT is not forwarded to MO, removing SA5-8 it works correctly. Also other messages in-dialog initiated by MT (example call hold/resume) is affected and removing SA5-8 solve it. Do you prefer a new issue?

Another issue observed: in case of IPv6 the NOTIFY over TCP is sent using wrong originated port (the ps instead of pc). No problem for IPv4. Do you have same idea on how to fix it?

Regards

herlesupreeth commented 3 years ago

Out ot topic: A comment regarding SA5 to SA8 ( Fix for some broken In-Dialog routing), it seams broke the Requests iniziated by terminated UE. For example BYE from MT is not forwarded to MO, removing SA5-8 it works correctly. Also other messages in-dialog initiated by MT (example call hold/resume) is affected and removing SA5-8 solve it. Do you prefer a new issue?

Can you please open another issue and append the pcap as well?

Another issue observed: in case of IPv6 the NOTIFY over TCP is sent using wrong originated port (the ps instead of pc). No problem for IPv4. Do you have same idea on how to fix it?

I was trying to fix exactly this but unfortunately I am unable to reproduce this scenario at my end to fix this. Can you post the pcap for this as well?