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

Does open5gs-hss support sms over ims? #297

Open
lglhust opened this issue Apr 2, 2024 · 11 comments
Open

Does open5gs-hss support sms over ims? #297

lglhust opened this issue Apr 2, 2024 · 11 comments

Comments

@lglhust
Copy link

lglhust commented Apr 2, 2024

I set up volte environment to test sms over ims based on open5gs-hss without using PyHSS. When the ues register ims successfully, I send sms from mo-user to mt-user.
The kamailio-smsc received mo-sms and send RP-ACK to the mo-user,but it did not send sms to the mt-user.

The smsc log:

9(15003) ERROR: <script>: 3GPP-SMS: MESSAGE (sip:13820073901@ims.mnc001.mcc001.3gppnetwork.org (192.168.12.195:37013) to tel:+7, Y6ecbU7nE@172.10.9.1)
9(15003) ERROR: <script>: SMS for 13820073902 "901" (Valid: 0 )
9(15003) ERROR: <script>: SMS from 3GPP/VoLTE
9(15003) ERROR: <script>: -------------------------------------
9(15003) ERROR: <script>: FROM 13820073901
9(15003) ERROR: <script>: TO 13820073902
9(15003) ERROR: <script>: TEXT 901
9(15003) ERROR: <script>: DCS 0
9(15003) ERROR: <script>: SMS-Task
9(15003) ERROR: <script>: -------------------------------------
9(15003) ERROR: <script>: FROM 13820073901
9(15003) ERROR: <script>: TO 13820073902
9(15003) ERROR: <script>: TEXT 901
9(15003) ERROR: <script>: DCS 0
9(15003) ERROR: <script>: SMS to Outbound
9(15003) ERROR: <script>: -------------------------------------
9(15003) ERROR: <script>: FROM 13820073901
9(15003) ERROR: <script>: TO 13820073902
9(15003) ERROR: <script>: TEXT 901

I found there is no smsc config parameter in open5gs-hss yaml file.
How does smsc know where is the mt-user? It should to query hss to get the route info of the mt-user.

In /etc/kamailio_smsc/, there are only two files: smsc.cfg and kamailio_smsc.cfg, with no hss configuration .
Should smsc configure 'DiameterPeer' in smsc.xml just like in scscf.xml to setup diameter session with open5gs-hss?

Or smsc just submit mt-message to scscf for the mt-user by default ? what causes the smsc not to send sms to the mt-user ?

In open5gs hss.yaml: sms_over_ims: "sip:smsc.mnc001.mcc001.3gppnetwork.org:7060;transport=tcp" .
Does it need to configure in open5gs-hss for sms over ims.?

But i still cannot get the answer for the problem above, although I found the cause for not sending sms to mt-user: SIP to address: "tel:+7" . Here in file of kamailio_smsc it is considered as SMS_TO_OUTBOUND and processed unsuccessfully。

Thanks a lot.

@herlesupreeth
Copy link
Owner

open5gs HSS does support sending SMSC information upon successful IMS registration. Can you please send the pcap of the registration + sending SMS scenario? Also, are you using open5gs_hss_cx branch?

@lglhust
Copy link
Author

lglhust commented Apr 7, 2024

Hi, herlesupreeth
yes, i use open5gs_hss_cx branch and kamailio version 5.3.2 by herlesupreeth .
I found the cause is the Request-URI and to header 'tel:+7' cannot be identified by scscf and ue got 478 error. When i modify the branch of route[SMS] in kamailio_smsc.cfg, annotating the code about 'enum_pv_query("$var(enum)")', then sms works well.
I don't know why the URI of mo-sms is 'tel:+7' ? Maybe it is the default smsc address configuration of the ue.

I have 3 questions.
Question 1:
I still don't know why smsc don't query the mt-user location in HSS for there is no diameter configure between them.I think if there are multiple kamailio scscfs serving mo-user and mt-user respectively, the smsc maybe find no location of where is scscf serving the mt-user is. I haven't test the issue yet.

Question 2:
Does smsc support sms buffer when the mt-user is absent or un-registration? I found if mt-user do un-registration by airplane mode , smsc will output error logs as 'Dropping SMS [3] TO 13820073902 after 2 retries '.

Question 3:
When the ue trys another registration again with no un-registration, scscf will remain multiple port-s for the ue for every registration. The scscf try to send sms to all port-s of every registration of ue, while UE just use it's port-s with the last registration and send no response to the port-s of the registration before.
So i think pcscf should remove the port-c and port-s before when next ims registration success and noly use current ports.

In cmd.c, i saw the code:
"// Destroy privously existing IPSec tunnels but dont release proxy ports
        destroy_ipsec_tunnel(ci.received_host,
            pcontact->security_temp->data.ipsec, pcontact->contact_port, 0);"

I am not sure why not to release pcscf ports for ue of last registration here.

Thanks.

@herlesupreeth
Copy link
Owner

Please always attach a pcap to debug. Just logs is not enough. I would suggest to take a pcap of UE registration and then followed by sending SMS.

I don't know why the URI of mo-sms is 'tel:+7' ? Maybe it is the default smsc address configuration of the ue.

yep, its SMSC address programmed in the SIM

I found the cause is the Request-URI and to header 'tel:+7'

Actually MO-SMS in SMS over IMS is not routed based on Request-URI rather the MSISDN in the payload. So the modification you did in my opinion is not needed

Question 2:
Does smsc support sms buffer when the mt-user is absent or un-registration? I found if mt-user do un-registration by airplane mode , smsc will output error logs as 'Dropping SMS [3] TO 13820073902 after 2 retries '.

There is no buffering mechanism if the recipient UE is not registered or in airplane mode. It tries to deliver for 2 times and then drops

Question 3:
When the ue trys another registration again with no un-registration, scscf will remain multiple port-s for the ue for every registration. The scscf try to send sms to all port-s of every registration of ue, while UE just use it's port-s with the last registration and send no response to the port-s of the registration before.
So i think pcscf should remove the port-c and port-s before when next ims registration success and noly use current ports.

There is mechanism to remove old IPSec ports in P-CSCF after a delay. P-CSCF takes care of directing the SIP packets to correct IPSec ports so no need to worry about that even if there are multiple IPSec ports for the same IMPI/IMPU

@lglhust
Copy link
Author

lglhust commented Apr 9, 2024

In kamailio_smsc.cfg
route[SMS_FROM_SIP] {
... ...
$avp(to) = $tU;
Here avp(to) is not from message payload, so it goes into the branch of '[SMS_TO_OUTBOUND]'.

There is the log:
One pcap file is for mt-sms delivery fail , another is for multi registration that pcscf sends sms to all port for every registration while the ue sends no response for previous ports.

sms.zip

Do you have the plan to add sms buffering mechanism ?

Thanks.

@herlesupreeth
Copy link
Owner

Do you have the plan to add sms buffering mechanism ?

Unfortunately no. I no longer actively work on IMS.

@herlesupreeth
Copy link
Owner

image

First of all, I am not sure what modification you have done in your kamailio_smsc.cfg. Second, I dont see the UE with MSISDN 10658112210002 registered in the pcap. If the UE is not registered SMSC wont be able to deliver the SMS

@lglhust
Copy link
Author

lglhust commented Apr 11, 2024

sorry, it's my fault, i didn't put the right pcap file.

I mode no modification to kamailio_smsc.cfg. If i do not annotate the code of below:
"if (!enum_pv_query("$var(enum)")) {
route(SMS_TO_OUTBOUND);
return $retcode;
}"
For the second sms delivery of the mo-user, the mt user will not receive sms because enum_pv_query() fails here.
mt-fail.zip

Another question:
I want to test sms when user is offline. I think when smsc get notification of reg-status-changed of mt-user, it can decide to send buffered sms.

I saw ’reginfo_subscribe("$var(uri)", "SUBSCRIBE_EXPIRE");‘ in kamailio_smsc.cfg and SUBSCRIBE_EXPIRE is 7200s. MO-user send one sms but mt-user is offline, smsc will send subscribe req to scscf via icscf. Then scscf sends notify of 'state="terminated" 'to smsc . I observed the subscribe-notify information exchange from the capture packets .

When mt-user registered again , it's reg state changed but no NOTIFY info could be received from scscf.
I don't know why. Does reginfo_subscribe() works only one time?
Does it need "presence_reginfo" module in kamailio_scscf to send NOTIFY message for every reg status modification of the ue ?

Thanks a lot.

@herlesupreeth
Copy link
Owner

When mt-user registered again , it's reg state changed but no NOTIFY info could be received from scscf.
I don't know why. Does reginfo_subscribe() works only one time?
Does it need "presence_reginfo" module in kamailio_scscf to send NOTIFY message for every reg status modification of the ue ?

Change the below settings in kamailio_scscf.cfg i.e. set it to 1. Then reg status will then be published to watchers

modparam("pua_reginfo", "publish_reginfo", 1)

@herlesupreeth
Copy link
Owner

Can you please let me know whether the above change fix your issue?

@lglhust
Copy link
Author

lglhust commented Apr 18, 2024

Sorry for reply late.
I changed kamailio_smsc.cfg as belows:
modparam("pua_reginfo", "default_domain", "DOMAIN")
modparam("pua_reginfo", "publish_reginfo", 1)

I saw smsc received state-change-notification only when ue turned into offline ,that is terminated state. When UE became online again, smsc didn't receive notification.
Here is the pcap file.
state.zip

kamailio version i used is 'https://github.com/herlesupreeth/kamailio/tree/5.3/', not same as the version from docker_open5gs/ims_base/Dockerfile/branch 5.3. The two versions are very different. The former one works well basically and i haven't tried the one in docker_open5gs.
I am not sure which version is more suitable. Could you tell me which version is the most reliable?

Thanks.

@herlesupreeth
Copy link
Owner

I saw smsc received state-change-notification only when ue turned into offline ,that is terminated state. When UE became online again, smsc didn't receive notification.
Here is the pcap file.

The only explanation I can think of is that the contact has changed, for example in the NOTIFY to SMSC (packet 19544), I see UE having contact - sip:460080120073571@172.10.0.144:31949;alias=172.10.0.144315191 but when it registers again the contact is sip:460080120073571@172.10.0.144:31891;alias=172.10.0.144316351

Notice that ports have changed even though the IMPI/IMPU has remained same

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

2 participants