5 Working with Subscriber Data
This chapter explains how Oracle Communications Evolved Communications Application Server (OCECAS) stores subscriber information and how applications retrieve that data. It includes a description of the default subscriber data store configuration, and explains how you can customize it for your implementation.
See ”About Managing Subscribers and Subscriber Data” for an overview of how OCECAS stores subscriber data records.
About Subscriber Data
OCECAS subscriber data can be stored in multiple sources, called data stores, which are accessed through a configurable view. The view retrieves the needed data from the data stores and federates it into a single record to return to the requesting application. The application is not aware of the actual data storage, only the format of the data returned. The view, on the other hand, is aware of the data storage location and format, the format that the application expects, and the mapping between the two.
OCECAS data stores can include an external Home Subscriber Server (HSS), the default ECAS Subscriber Server (ESS) NoSQL database, which is optional, or a data store from an external provider.
Operator's often will want to integrate an existing HSS. The OCECAS view framework provides the ability to obtain subscriber data from an HSS through the Diameter Sh interface.
Types of Subscriber Data
The types of data accessed from the OCECAS data stores include the following:
-
Subscriber profile and services data
-
Supplementary services data
-
SRVCC data
The following sections describe how these types of data are accessed.
Accessing Subscriber Profile and Services Data
You can store subscriber profile data in any of the supported OCECAS data stores.
When stored in the HSS, the profile and services data are split into separate blocks of transparent data, each with its own service-indication value. Transparent data is data for which the HSS understands the syntax but not the meaning. Table 5-1 describes the service indication values of the profile and services data:
Table 5-1 Service Indication Values for Profile and Services Data
| Service Indication | JSON Block | Description |
|---|---|---|
|
ECAS_USER_PROFILE_1 |
Profile |
Subscriber profile data |
|
ECAS_USER_SERVICES |
Services |
Subscriber services |
|
ECAS_USER_MESSAGE_ACCOUNT_1 |
MessageAccount |
Transparent data used for Message Waiting Indication Services |
In both the ESS and the HSS, each data block is stored as a JSON document. In the case of the ESS NoSQL database, they are stored as a single document; in the HSS they are stored as separate documents.
The following example shows base subscriber data in an ESS NoSQL database:
{
"Description":"IMS Subscriber",
"ServiceProviders": {
"MVNO1": {
"profile_data":{
"RegistrationExpiry": 0,
"Language": "en_GB",
"Translations":{},
},
"services":{
"REGISTRATION":"VoLTE and VoWiFi",
"VOICE":"VoLTE and VoWiFi"
}
}
}
}
Accessing Supplementary Services Data
Supplementary services data can be stored in the HSS or as part of the subscriber profile in the ESS NoSQL database or third-party data store. When it is stored in the HSS, it is stored as a separate RepositoryData entry with one of the service-indication values shown in Table 5-2.
Table 5-2 Service Indication Values for Supplementary Services
| Service-Indication Value | Description |
|---|---|
|
MMTEL-SERVICES-BINARY-1 |
Supplementary services are stored in binary format |
|
MMTEL-Services |
Supplementary services are stored in XML format |
The data returned from the HSS is converted into JSON and merged into the subscriber profile document that is returned to the application.
Accessing SRVCC Data
OCECAS generally accesses Single Radio Voice Call Continuity (SRVCC) data from the subscriber data store to support the following features:
-
To obtain the IMS Voice Over Packet-Switched-Session Support indicator, which indicates whether the subscriber is currently waiting on an IMS Voice over packet-switched-capable access.
-
To obtain or update the Session Transfer Number.
OCECAS retrieves the following non-transparent SRVCC-related fields from the HSS and merges them into the subscriber profile document:
-
TADS information
-
UE SRVCC capability
-
CSRN
-
STN SR
Federating the View
Figure 5-1 shows how OCECAS federates data from multiple data stores in a single view.
If you use the default ESS inside an OCECAS runtime domain, the views and their Groovy federation scripts are loaded each time you start the runtime domain. If you locate the ESS inside a dedicated UDR domain, the views and their federation scripts are loaded each time you start the runtime domain.
If necessary, you can change the federation instructions during runtime. See "Updating Federation Script Behavior During Runtime" for details.
The view federation script transforms the subscriber profile data, the services data, the supplementary services, and the SRVCC data into the following subscriber profile record. In an HSS, each block of subscriber data, which includes Profile, Services, and MMTelServices, represents a block of transparent data. In the default NoSQL data store, this structure is maintained.
{
"Service":{
"HomeCountry":"GBR",
"HomeNetworkIdList":["network.gb.net","ims.mnc044.mcc234.3gppnetwork.org",
"oracle.com","presence.oracle.com"],
"ServiceProviderName":"MVNO1",
"ServiceName":"VoLTE and VoWiFi",
"ControlFlowName":"Session Origination"
},
"Profile":{
"CallCount":0,
"CallFwdCompany":"",
"Language":"en_GB",
"ToNumber":"",
"Translations":{},
"VMRedirect":""
},
"MMTel": {
"OIP":{
"Active":true
},
"TIP":{
"Active":true
},
"OIR":{
"active":true,
"Default":"Restricted",
},
"TIR":{
"active":true,
"Default":"Restricted",
},
"ICB":{
"Active":true,
"Rules":[
{
"RuleDeactivated":false,
"IdentityList":["sip:notallowed@oracle.com"],
"DomainList":["notallowed.com"],
"DomainExceptList":["domain1"],
"Allow":false
},
{
"RuleDeactivated":false,
"Anonymous":true,
"Allow":false
}
]
},
"OCB":{
"Active":true,
"Rules":[
{
"RuleDeactivated":false,
"Roaming":true,
"Allow":true
},
{
"RuleDeactivated":false,
"InternationalExHC":true,
"Allow":false
}
]
}
},
"MMTelOperator": {
"OIR":{
"Mode":"Permanent",
"Restriction":"AssertedIdentity"
},
"TIR":{
"Mode":"Permanent"
}
}
}
Translating HSS Data
Transparent data in the HSS is accessed by the view and federated into a single JSON document before returning it to the application. Each block of transparent data can be in a different format. The ECAS_USER_PROFILE_1 and ECAS_USER_SERVICES_1 blocks are stored in JSON format so the translation is straight-forward. MMTEL-Services, however, can be stored in XML, binary, or some proprietary format. Consequently the view must be able to parse the data stored in the HSS and convert it into the JSON format that the application expects.
Adding a Plug-in Parser
To parse the non-JSON data stored in the HSS and convert it to JSON, and to convert it from JSON back to the HSS data types, the view allows you to add a plug-in parser. To create a parser, you must implement the Java ProfileParser interface in the OCECAS platform API. The following diagram illustrates the class structure:
Note:
The plug-in parser can also be used elsewhere. For example, you could also use a parser for XML Supplementary Services data to convert between JSON data and XML for the XCAP interfaces.You can add the parser to the view using the CSP configuration. The following example illustrates a configuration:
<csp-config>
<name>csp</name>
<pipes>
<udr-pipe>
...
<parser>
<name>SuppServXMLParser</name>
<parser-class>oracle.occas.csp.platform.parsers.SuppServXMLParser</parser-class>
</parser>
...
</udr-pipe>
</pipes>
</csp-config>
The class is loaded by the csp.xml code and made accessible through the external concept, UserProfileContext. An access method in UserProfileContext allows the Groovy script to get the parser as shown here:
ProfileParser parser = context.getProfileParser("SuppServXMLParser")
ObjectNode contextNode = parser.parse(xmlObject)
You can add additional methods to load other parsers that are defined in the configuration.
Configuring OCECAS Data Stores
The procedures in this chapter assume that you have already installed OCECAS and your ESS NoSQL database, or third-party data store, and completed the following post-installation tasks, if applicable, in these sections of Oracle Communications Evolved Communications Application Server Installation Guide:
-
Configuring Communication Between Your Runtime Domains and the UDR
-
Configuring Communication Between Your UDR Domain and the UDR
To complete the following tasks for your data store, see the associated sections of documentation:
-
To access data from an HSS, use the instructions in "Adding an HSS Subscriber Data Store".
-
To perform advanced configuration for your ESS NoSQL database, see "Advanced Configuration of Your ESS NoSQL Subscriber Data Store".
-
To replace the default ESS with another data store, see "Replacing the ESS NoSQL Database" for instructions.
-
To make changes to the ESS schema, see "Changing the Default ESS NoSQL Schema" for details.
-
To update your federation scripts without shutting down the runtime environments, see "Updating Federation Script Behavior During Runtime"
-
To provision the ESS with subscriber data using the RESTful interface, see "Configuring Subscriber Data Quickly for a Test or Demonstration System" and "Provisioning the ESS with Subscriber Data".
-
To understand the details of the default schema for the ESS subscriber store, see "The Default ESS Subscriber Store Schema".
Adding an HSS Subscriber Data Store
Skip this section if you do not access subscriber data from an HSS.
If you access subscriber data from an existing HSS, use the following instructions to make it available to OCECAS.
Configuring OCECAS to Accept Data from a Diameter Sh HSS
You configure your Diameter Sh HSS using the OCECAS Administration Console to edit the csp.xml file in each runtime environment, as described in this section.
See ”Managing the Diameter Node” in Evolved Communications Application Server Administrator's Guide for instructions on how to configure the Diameter interface.
To configure a Diameter Sh HSS:
-
Open the OCECAS administration console.
For more information, see ”About the OCECAS Administration Console” in Evolved Communications Application Server Administrator's Guide.
-
Click Lock & Edit.
-
In the Domain Structure pane, navigate to domain_name then Diameter.
The General tab appears.
-
Fill in this tab to meet the needs of your implementation.
-
Click Save.
-
Navigate to Applications by clicking the Applications tab.
-
Click New.
-
Fill in the Application Name, Class Name, and any optional parameters for the new Diameter application.
-
Click Finish.
-
Finish configuring Diameter using the Peers, Routes, and Message Debug tabs as necessary for your implementation.
-
Click Release Configuration.
-
Open the domain_home/config/custom/csp.xml file for editing.
-
If needed, change the
data-sourceparameters in the<provider>element to specify the HSS to use for read-request data source, read-response data source, update-request data source, and update response data source. -
Edit the script_HSS federation script as necessary to manipulate the HSS data to satisfy the calling application:
-
Translate the HSS data into a format that the calling application requires.
-
Federate the data with any other data stores that your implementation uses.
-
-
Save and close csp.xml.
WARNING:
After updating the csp.xml file, if you update the configuration through the WebLogic administration console, the changes made in csp.xml will be lost.
-
Restart the servers in the runtime environment.
-
Repeat this procedure for each runtime environment that uses the HSS.
Advanced Configuration of Your ESS NoSQL Subscriber Data Store
This section assumes that you have already followed the instructions in Oracle Communications Evolved Communications Application Server Installation Guide and installed your default NoSQL ESS and specified where it should connect to a runtime domain. This section takes up where that one left off.
This section requires that you know the format in which your calling applications require data, and know Groovy/Java to modify the federation scripts.
By default, the csp.xml file includes a default NoSQL ESS, defined as udr1 of type NoSQLProvicerFactory:
Also by default, an adapter is defined that specifies the ESS nosql1 connection information:
<adapters>
<no-sql-adapter>
<name>nosql1</name>
<helper-host>localhost:5000</helper-host>
<store-name>spr.data</store-name>
</no-sql-adapter>
</adapters>
You can use these default values, or change them to meet your needs.
To finish configuring your default NoSQL ESS:
-
In a runtime domain, open the domain_home/config/custom/csp.xml file for editing.
-
Optional. Edit the
<provider>element for the ESS, specifying the type of traffic it will be used for. The default ESS nosql1 is designated for all of the read, update, request, and response messages:<name>udr1</name> <provider> <name>p1</name> <type>NoSQLProviderFactory</type> <adapter>nosql1</adapter> <read-request-data-source>source_Initial</read-request-data-source> <read-response-data-source>source_Initial</read-response-data-source> <update-request-data-source>source_Initial</update-request-data-source> <update-response-data-source>source_Initial</update-response-data-source> </provider>
Change this as necessary for your implementation.
-
Change the federation scripts as necessary to modify the data from the ESS so that the calling application can accept the data. The exact configuration will be unique to your implementation.
-
Save and close the cspl.xml file.
-
Restart the domain that contains the ESS.
Adding Additional Data Sources and Formats to the View
This section explains how to change the default subscriber store configuration.
Replacing the ESS NoSQL Database
The default OCECAS subscriber data storage paradigm retrieves data stored in an HSS that you specify, and if the data changes, it is stored in the ESS NoSQL database.You replace the ESS with a different database if your implementation requires it. However this requires a strong knowledge of the database you wish to use, and significant work to change the Groovy federation scripts in the csp.xml file.
See "The Default ESS Subscriber Store Schema" for details on the default ESS data schema.
Adding a New UDR Using a New Data Type
To add a new UDR provider using a completely different data type, edit the csp.xml file, adding a new provider and adapter to specify the UDR name and location and the types of messages that can access them. Then create a new view, data-source, and federation script to translate the data.
Changing the Default ESS NoSQL Schema
You can modify some part of the OCECAS default ESS schema if your implementation requires it. However you have these restrictions:
-
Some properties can not be changed because they are specified in the UDR MBean. These include the top level property names:
-
userIdentifier
-
mapData
-
JsonData
-
-
You must correct any references to properties that you change in the data federation scripts in the csp.xml file. After correcting this file, restart the domain administration servers that use the csp.xml file to make your changes take effect.
Changing the Default ESS Schema
To change the default UDR Schema for a production pipeline:
-
Create a new change set in the test domain for changing the UdrSubscriberSchema and record the new change set ID.
-
Use the SchemaResource class operations in the RESTful API to change UdrSubscriberSchema for the new change set:
/api/change-sets/changeset_ID/schemas/UdrSubscriberSchema
Where changeset_ID is the ID of the change set you created in Step 1.
See the SchemaResource class in Evolved Communications Application Server UDR RESTful API Reference for details on the RESTful APIs.
-
Open the domain_home/config/custom/csp.xml file for editing.
-
Search the Groovy data federation script in csp.xml for any of the properties that you changed in the UdrSubscriberSchema table, and replace them with the new values you created.
-
Save and close the file.
-
Restart the domain servers.
-
Propagate the changes you made to the staging and production environments in your pipeline.
Updating Federation Script Behavior During Runtime
You can change the federation script behavior at runtime by using this WebLogic Scripting (WLST) command from the default script location in domain_name/bin:
java weblogic.WLST ./csp.py -u admin_username addsrc federation_scriptname federation_script_filename
Where:
-
admin_username is a WebLogic user with administration privileges.
-
federation_scriptname is the name of the federation script to change. The default is script_initialProfile.
-
federation_script_filename is the replacement script with the instructions you want to use.
For details on WLST, see ”Using the WebLogic Scripting Tool” in Oracle Fusion Middleware WebLogic Scripting Tool.
About the OCECAS Diameter Sh Interface
See ”3GPP_TS_29.328” in Evolved Communications Application Server Compliance Guide for a list of the supported Diameter Sh messages. If your implementation uses custom AVPs, add them to the Groovy scripts in csp.xml. See "Configuring OCECAS to Accept Data from a Diameter Sh HSS" for instructions on editing this file.
Configuring Subscriber Data Quickly for a Test or Demonstration System
If you are just creating a test and evaluation system, the fastest and easiest way to add subscriber data to OCECAS is to provision the ESS NoSQL database using the REST interface. This does not make any subscriber information from an HSS available, but it is faster. See "Provisioning the ESS with Subscriber Data" for instructions.
Provisioning the ESS with Subscriber Data
You create and manage subscribers by writing provisioning tools that use RESTful HTTP commands to interact with RESTful APIs. This allows for easy integration with external systems.
For a complete description of the OCECAS RESTful APIs, see Oracle Communications Evolved Communications Application Server SDC RESTful API Reference and Oracle Communications Evolved Communications Application Server UDR RESTful API Reference.
This section explains how to provision and manage subscriber data in your ESS, including the following tasks:
When creating or modifying subscriber data, the data must adhere to the ESS subscriber schema. See "Understanding the Default ESS Objects" for a description of the schema.
Connecting to the ESS Server
To log in to the ESS server, issue a POST command like the following one, replacing hostname and port with the host name and port number of the ESS server, and authorization_value with user credentials. The default port number of the ESS server is 6052.
POST /api/session HTTP/1.1 Host: hostname:port Authorization: Basic authorization_value== Cache-Control: no-cache
See "Logging In to the Management Domain" for information on how to obtain an authorization pass code.
Creating a New Subscriber
To create a new subscriber, issue a POST command like the one in this example, replacing hostname and port with the host name and port number of the ESS server:
POST /api/subscriber HTTP/1.1 Host: hostname:port Content-Type: application/json Cache-Control: no-cache
Include content to describe the subscriber, as shown in this example:
{
"userIdentifiers": [
{
"id": "sip:6175551002@oracle.com",
"type": "END_USER_SIP_URI"
},
{
"id": "tel:6175551002",
"type": "END_USER_SIP_URI"
},
{
"id": "sip:+6175551002@oracle.com",
"type": "END_USER_SIP_URI"
}
],
"jsonData": {
"oracle.occas.csp.app.sdc.OCECASUser": {
"Description": "subscriber: sip:6175551002@oracle.com",
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"CallCount": 0,
"CallFwdCompany": "",
"Language": "en_GB",
"ToNumber": "",
"Translations": {},
"VMRedirect": ""
},
"services": {
"REGISTRATION": "VoLTE and VoWiFi",
"VOICE": "VoLTE and VoWiFi"
}
}
}
}
}
}
In this example, the subscriber is given three IDs of type END_USER_SIP_URI and a basic profile that specifies the user's language as Great Britain English. The example also registers the user for VoLTE and VoWiFi services.
Getting Subscriber Data
To get subscriber data, issue a GET request like the one in this example, replacing hostname and port with the host name and port number of the ESS server:
GET /api/subscriber?user_id=sip:6175551002@oracle.com&type=END_USER_SIP_URI HTTP/1.1 Host: hostname:port Cache-Control: no-cache
This example request retrieves a globally unique identifier (GUID) for the subscriber with a user_id value of sip:6175551002@oracle.com, the same subscriber created in "Creating a New Subscriber".
The request returns these fields:
-
id (example: dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH)
-
userIdentifiers
-
mapData (optional)
-
jsonData
The details of userIdentifiers and jsonData depend on the schema defined for the UdrSubscriberSchema record in the SDC_SCHEMA database table. If the mapData field has no data, it is not returned.
Amending Subscriber Data
To amend subscriber data, issue a PUT command identifying the subscriber with a GUID. See "Getting Subscriber Data" for information on obtaining a GUID.
This example changes the subscriber's jsonData field. To use this example, replace hostname and port with the host name and port number of the ESS server. Replace dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH with the subscriber's GUID
PUT /api/subscriber/dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH/json/oracle.occas.csp.app.sdc.OCECASUser HTTP/1.1 Host: hostname:port Content-Type: application/json Cache-Control: no-cache
This command writes a specific jsonData field to the subscriber's service data. For example:
{
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"TIR": {
"Active": true,
"Mode": "Permanent",
"Default": "Restricted",
"Restriction": "AssertedIdentity"
}
}
}
}
}
Deleting a Subscriber
To delete a subscriber, issue a DELETE command like the one in the following example, replacing hostname and port with the host name and port number of the ESS server and identifying the subscriber with a GUID. See "Getting Subscriber Data" for information on getting a subscriber's GUID.
DELETE /api/subscriber/dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH HTTP/1.1 Host: hostname:port Cache-Control: no-cache
This example deletes the subscriber created in "Creating a New Subscriber".
Getting Subscriber Aliases
To get all aliases for a subscriber, issue a GET command like the one shown in the following example, specifying the subscriber with a GUID. Replace hostname and port with the host name and port number of the ESS server and replace dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH with the subscriber's GUID.
GET /api/subscriber/dWRyMQAAAUuht5PxqzIelnGoEY81150AAAAH/alias HTTP/1.1 Host: hostname:port Cache-Control: no-cache
This example returns all aliases for the subscriber in an array of userIdentifiers:
{
"userIdentifiers": [
{
"id": "sip:6175551002@oracle.com",
"type": "END_USER_SIP_URI"
},
{
"id": "tel:6175551002",
"type": "END_USER_SIP_URI"
},
{
"id": "sip:+6175551002@oracle.com",
"type": "END_USER_SIP_URI"
}
],
}
Updating a Subscriber Alias
To update the alias of a subscriber, issue a PUT command like the one shown in the following example, specifying the subscriber with a GUID. Replace hostname and port with the host name and port number of the ESS server and replace dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM with the subscriber's GUID.
PUT /api/subscriber/dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM/alias Host: hostname:port Content-Type: application/json Cache-Control: no-cache
Attach content to specify the subscriber's alias in a userIdentifiers array, as shown in this example:
{
"userIdentifiers" : [ {
"id" : "sip:subA@192.168.0.1:50640",
"type" : "END_USER_SIP_URI"
} ]
}
Note:
JSON data other thanuseridentifiers is ignored.A subsequent GET of the subscriber's data returns:
{
"id": "dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM",
"userIdentifiers": [
{
"id": "sip:subA@192.168.0.1:50640", <--- updated
"type": "END_USER_SIP_URI"
}
],
"jsonData": {
"oracle.occas.csp.app.sdc.OCECASUser": {
"Description": "subscriber: sip:subscriberA024652@192.168.0.1",
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"CallCount": 0,
"CallFwdCompany": "",
"Language": "en_GB",
"ToNumber": "",
"Translations": {},
"VMRedirect": ""
},
"services": {
"VOICE": "ExtractStringProfileTagOk"
}
}
}
}
}
}
Getting jsonData for a Subscriber
To retrieve specific jsonData for a subscriber, for instance the oracle.occas.csp.app.sdc.OCECASUser jsonData, issue a GET command like the one shown in the following example, specifying the subscriber with a GUID. Replace hostname and port with the host name and port number of the ESS server and replace dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM with the subscriber's GUID.
GET /api/subscriber/dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM/json/oracle.occas.csp.app.sdc.OCECASUser Host: hostname:port Cache-Control: no-cache
The response returns the following JSON data:
{
"Description": "subscriber: sip:subscriberA024652@192.168.0.1",
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"CallCount": 0,
"CallFwdCompany": "",
"Language": "en_GB",
"ToNumber": "",
"Translations": {},
"VMRedirect": ""
},
"services": {
"VOICE": "ExtractStringProfileTagOk"
}
}
}
}
Adding jsonData for a Subscriber
To add specific jsonData to a field for a subscriber, issue a PUT command like the one shown in the following example, specifying the subscriber with a GUID, and attaching content in JSON format. Replace hostname and port with the host name and port number of the ESS server and replace dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM with the subscriber's GUID.
PUT /api/subscriber/dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM/json/oracle.occas.csp.app.sdc.OCECASUser Host: hostname:port Content-Type: application/json Cache-Control: no-cache
Content:
{
"Description": "subscriber: sip:subscriberA024652@192.168.0.1",
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"CallCount": 0,
"CallFwdCompany": "",
"Language": "Chinese",
"ToNumber": "",
"Translations": {},
"VMRedirect": ""
},
"services": {
"VOICE": "ExtractStringProfileTagOk"
}
}
}
}
A subsequent GET of subscriber data then returns the following data, in which the subscriber's language has been changed to Chinese.
{
"id": "dWRyMQAAAU6pL51CsE9QWg4Z3LXrX3sAAAAM",
"userIdentifiers": [
{
"id": "sip:subA@192.168.0.1:50640",
"type": "END_USER_SIP_URI"
}
],
"jsonData": {
"oracle.occas.csp.app.sdc.OCECASUser": {
"Description": "subscriber: sip:subscriberA024652@192.168.0.1",
"ServiceProviders": {
"MVNO1": {
"profile_data": {
"CallCount": 0,
"CallFwdCompany": "",
"Language": "Chinese", <--- updated
"ToNumber": "",
"Translations": {},
"VMRedirect": ""
},
"services": {
"VOICE": "ExtractStringProfileTagOk"
}
}
}
}
}
}