Kamailio ims_charging module Ro Interface User-Equipment-Info-Type AVP

[svinson1121]

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

[mtryfoss]

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?

[svinson1121]

@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.