[kamailio/kamailio] Kamailio ims_charging module Ro Interface User-Equipment-Info-Type AVP (Issue #3807)
The Kamailio ims_charging module Ro interface is sending:
AVP: User-Equipment-Info(458) -> AVP: User-Equipment-Info-Type(459) l=12 f=-M- val=MAC (1) see attached Ro.pcapng packet #7.
but (unless I'm not understanding correctly) according to TS 132 299 this AVP should be of type IMEISV and not MAC for the Ro charging interface. also, the MAC is not encoded correctly. again, see the attached pcap at packet #7
from TS 132 299: "User-Equipment-Info-Type This field determines the type of the identifier. The used value is 0 for the international mobile equipment identifier and software version according to TS 23.003[224]. User-Equipment-Info-Value This field contains the user IMEI."
"For PS charging, when the User-Equipment-Info-Type AVP (AVP code 459) is set to IMEISV (0), the value within the User-Equipment-Info-Value AVP (AVP code 460) is of type OctetString and shall be a UTF-8 encoded hexadecimal. The composition of the IMEISV follows the definition in TS 23.003 [224] . If only IMEI is received a filler ‘F’ is used to make it 16 digits."
"For IMS charging, when the User-Equipment-Info-Type AVP (AVP code 459) is set to IMEISV (0), the value within the User-Equipment-Info-Value AVP (AVP code 460) is of type OctetString and shall be a UTF-8 encoded decimal. The composition of the IMEISV follows the definition in TS 23.003 [224]. If only IMEI is received the number of digits are truncated to 15."
I have tested and found this in the following versions: version: kamailio 5.9.0-dev0 (x86_64/linux) 4fb8ac version: kamailio 5.3.2 (x86_64/linux) 87e8a1
Thank you so much for your help with this issue,
[Ro.zip](https://github.com/kamailio/kamailio/files/14924042/Ro.zip)
I'm not the author of this module, but this fall I made a lot of changes to it to make it compatible to a charging server from Nokia.
If I don't remember wrong, the charging expert I consulted with also mentioned something about the MAC - but it was not a blocker for us so we didn't do any change. Mostly to not alter current behaviour if anyone relies on that way.
Maybe some other may explain a use case for how it works currently.
Is this just an observation from your side, or do you have a specific use case not working as intended?
@mtryfoss HI Morten,
This was just an observation. I noticed the errors in Wireshark while looking over a few pcaps. it's not having any negative impact on my OCS as I'm not collecting data from that AVP. just thought I should raise the issue, but I understand your point on not altering the current behavior without good reason.
Thank you for the reply.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3807 as not planned.
Thanks for rasing this. If somebody else like to change and/or improve the ims_charging module, just create a PR with referring to this discussion.
-
github-actions[bot] -
Henning Westerholt
-
Morten Tryfoss
-
svinson1121