200OK/REGISTER for deregistration procedure is not ESP encapsulated
riccardv opened this issue · 8 comments
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).
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
hi
could you help me for installing UE simulator for testing VoLTE?
thank you
@sajem2020 Please stop spamming under unrelated issues. This repository does NOT provide a UE simulator to test VoLTE
@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
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
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
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
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?