Cbn Cli Know

7/24/2019 Cbn Cli Know

http://slidepdf.com/reader/full/cbn-cli-know 1/151

From: [email protected]

To: [email protected];[email protected]

CC: [email protected];[email protected];[email protected];[email protected];[email protected]

Subject: RE: INC00269022

Hi Petr,

I verified with customer MIN are based as per MSC and not SMSC from their core network team.



For Eg: When the International Subscriber is delivering SMS to Reliance CDMA Subscriber, the Source CLI is international i.e. 447771724999 which is International. Source CLI is National only when SMS is originated by any India Mobile whether CDMA or GSM Mobile and arriving on Reliance CDMA handsets.

Regards

Nitin Gupta

________________________________

From: Kolar, Petr



Sent: Friday, July 30, 2010 12:52 PM

To: Gupta, Nitin; Schimmer, Martin

Cc: Dimitrov, Viden; Randus, Jiri; internal.supportweb; Arya, Shashank; Goudakov, Edouard


Hi Nitin



Customer do not have same MIN = MDN. They have MIN based as per SMSC. Currentlyon the SMSC we do not have SMSC35_IS41_ORIG_MDN_ADDR_MODE assigned (not used).

So the last possibility how to reach required behavior failed. A code change isnecessary.

As discussed last night, we have functionality where we can define ODA in MT SMS Request in IS41 common class either to National / International. When it is set to National, we have MT SMS Request sent out from SMSC where Recipient Mobile number is 0+MDN.



What customer is looking for is that for MT-SMDPP we should be able to set the OOA in either National or International format irrespective of the ADT rules applied during submission to Source Address, if any.

I'm afraid that almost everything which is visible in the SMS traces are not the numbers which are really sent to the network. The trace which interests us is the following line in IS41 trace:

08:50:45.28|00C02A0F|is41_format_sms_delivery_point_to_point - SMS_OriginalOriginatingAddress [0x0201210d10614516523402]

Which is wrong in this case (the number is 0116546125432 - 011 is an international prefix (I have configured it as in USA, it is perhaps 00 in India), but thenthe country code is missing and follows 10 digits of the subscriber number 65461



25432).

All addresses (with exception of the Callback number which is not our matter) containing phone numbers are in the IS-41 MAP layer. The originating address is in the SMS_OriginalOriginatingAddress parameter of the SMS Delivery Point to Point (SMDPP) Invoke operation. This address has format described in TIA/EIA IS41-C section 6.5.2.123 or N.S0005-0 v 1.0 section 6.5.3.2. The address can have only 2 formats (when detaching from BCD/ASCII etc. formats): National and International. For Indian numbers the National format is <10 digits national number>, the International format is 91+<10 digits national number>. It is visible on the tcpdump attached to the incident (in the file cdma.zip).

I didn't quite clearly understand your clarification "Which format should be used in CDMA for non-Indian originator numbers?" Can you please elaborate it.

If SMs with originator outside of India can be delivered to a Reliance customerthey must contain OOA with country code. I wanted to know in which format the numbers are (either Unknown 00<country code><subscriber number> or International <country code><subscriber number>). But with my findings mentioned above the is just National and International Nature of Number in IS41 - no 0 or 00 prefixes.



With regards

Petr Kolar

SMSC Team / Developer

________________________________________



Acision. Innovation. Assured.

www.acision.com<http://www.acision.com/>

Holandska 5, 639 00 Brno

Czech Republic

T: +420 531 017 580



E: [email protected]<mailto:[email protected]>

________________________________

From: Gupta, Nitin

Sent: Friday, July 30, 2010 8:47 AM

To: Kolar, Petr; Schimmer, Martin



Cc: Dimitrov, Viden; Randus, Jiri; internal.supportweb; Arya, Shashank; Goudakov, Edouard


Hi Petr,

Customer do not have same MIN = MDN. They have MIN based as per SMSC. Currently

on the SMSC we do not have SMSC35_IS41_ORIG_MDN_ADDR_MODE assigned (not used).

I didn't quite clearly understand your clarification "Which format should be used in CDMA for non-Indian originator numbers?" Can you please elaborate it.



As discussed last night, we have functionality where we can define ODA in MT SMS Request in IS41 common class either to National / International. When it is set to National, we have MT SMS Request sent out from SMSC where Recipient Mobile number is 0+MDN.

What customer is looking for is that for MT-SMDPP we should be able to set the OOA in either National or International format irrespective of the ADT rules applied during submission to Source Address, if any.

Thanks and Regards

Nitin Gupta



________________________________

From: Kolar, Petr

Sent: Friday, July 30, 2010 1:21 AM


Cc: Dimitrov, Viden; Randus, Jiri; internal.supportweb; Arya, Shashank




Hi Nitin

Well, if the customer really insists on displaying originator numbers in different formats in CDMA and GSM, the ADT solution (using a special configuration) isnot possible for multi-mode system.

If in the customer CDMA network MIN=MDN, it is possible to set IS41_COMMON /USE_ MDN_IN_SMSDELIVER=OFF (and NOT set the SMSC35_IS41_ORIG_MDN_ADDR_MODE logical).For future I recommend to extend the functionality of the SMSC35_IS41_ORIG_MDN_ADDR_MODE logical to allow forcing original originator address to the required format independently on the USE_MDN_IN_SMSDELIVER setting.



Which format should be used in CDMA for non-Indian originator numbers?

With regards

Petr Kolar




________________________________________






Czech Republic

T: +420 531 017 580


________________________________

From: Gupta, Nitin

Sent: Thursday, July 29, 2010 6:50 PM



To: Kolar, Petr; Schimmer, Martin



Hi Petr,

Right now there is no MNP for Reliance CDMA and it is in the pipeline.CurrentlyI have done the roll back for the system from dual mode to single mode. I would

test turning off the IS41_COMMON /USE_MDN_IN_SMSDELIVER to OFF and test it out separately/ The logical in question is an old logical which was developed way back and in India we are not using anymore.



Please find response to your queries below.

I am sure once we have engineering patch for this, we can have this all sorted out.

Regards

Nitin Gupta



________________________________

From: Kolar, Petr





Hi Nitin



Do Reliance India use Mobile Number Portability? If not, try setting IS41_COMMON /USE_MDN_IN_SMSDELIVER=OFF . It could change the OOA to national number.

I've also found that there is a logical SMSC35_IS41_ORIG_MDN_ADDR_MODE which (when set to INTERNATIONAL) forces the OOA to be international. Unfortunately it cannot be used to force OOA to be national. But it would be possible to make a code change which would allow forcing OOA national with this logical.

Another idea (configuration change only):



When

GSM Reliance GSM number is e.g. +91902200034

CDMA Reliance CDMA Number is e.g. 9320196304

Would it be possible to display originator CDMA number on the GSM mobile as 09320196304 or 00919320196304? If so, a solution should exist with changing ADT configuration only. If not the only possibility is a code change in IS41 entity.



Nitin Gupta : display originator CDMA number on the GSM mobile as 09320196304 is currently possible but not acceptable to Reliance as they want to have GSM Mobile to see as CLI E.164 format ( international) only.

With regards

Petr Kolar




________________________________________




Czech Republic



T: +420 531 017 580


________________________________

From: Gupta, Nitin




To: Schimmer, Martin

Cc: Kolar, Petr; Dimitrov, Viden; Randus, Jiri; internal.supportweb; Arya, Shashank


Hi Martin,

In Reliance we are seeing CBN coming properly which is 0+Mobile Number however CDMA handsets read and display Originator CLI from OOA instead of CBN. As a common practice common man just presses the dial button, handset picks the mobile number from OOA value instead of CBN value and then the call do not connect because OOA is in International format and without + sign because this(+ sign) is not n

ot supported in most of CDMA handsets.



Please find my response inline and thanks for striving for some workarounds.

Thanks and Regards

Nitin Gupta

________________________________

From: Schimmer, Martin




To: Gupta, Nitin

Cc: Kolar, Petr; Dimitrov, Viden; Randus, Jiri; internal.supportweb


Hello Nitin,

we had some discussion here with Petr and we have certain doubts about the whole story. Note that this does not affect the "official" path we're taking right now (i.e. Change Request), but this is something to think about.



Following points are not clear to us:

1. It's required to have originator number in international format on GSM.

This is not clear why. GSM network should be able to route voice calls to national numbers just fine.

Nitin Gupta : Indeed GSM network should be able to route voice calls to national numbers, but its not only Reliance GSM network, it would be any India GSM network whose subscribers would see SOURCE CLI in National format against that of International E.164 format and this is something which is not acceptable to customer.



2. It's required to have originator number in national format on CDMA. This is also not clear why. While it's known that common CDMA networks cannot route voice calls to international numbers and require national number, there's special "call-back number" field in the CDMA message which should be used by CDMA handset for calls back to the originator and this number is readily formatted in national format by SMSC (as confirmed by traces from Reliance) so there should beno issue with this.

Nitin Gupta : Already mentioned above

From CDMA standard (3GPP2 C.S0015-B):

1 4.5.15 Call-Back Number

2 The Call-Back Number subparameter indicates the number to be dialed in reply to a



3 received SMS message.

So I think that CDMA handset should use this number in your scenario. Should ituse it, the whole thing would work correctly. The fact that handset does not use call-back number for calls back seems like violation of CDMA standard.

Best Regards!

Martin



From: Gupta, Nitin

Sent: Thursday, July 29, 2010 9:14 AM

To: Broughan, Michael; Martinez Puig, Juan; Goudakov, Edouard

Cc: Rodrigues, Kevin; internal.supportweb; Keeling, David; Randus, Jiri; Arya, Shashank

Subject: RE: INC00269022 RE: Reliance india - mt source address formatting



Hi Michael,

We either test the configurations now or we don't till the launch. There is nothing like later on, this is because all CDMA traffic would be treated like GSM traffic and thus there would be any CDMA traffic to be routed as CDMA.

Dear All : I have commenced the roll back for the configurations and its very disappointing.

Regards



Nitin Gupta

________________________________

From: Broughan, Michael


To: Gupta, Nitin; Martinez Puig, Juan; Schimmer, Martin; Goudakov, Edouard

Cc: Rodrigues, Kevin; internal.supportweb; Keeling, David; Randus, Jiri; Dimitrov, Viden




As discussed,

Crazy as it may be, the least worst option is to continue with our roll -back config work as this is the only guarantee to preserve a Saturday night go live. If however, someone can guarantee me that the "tips" received from Brazil (by theway, many thanks for these) are bullet -proof correct, we can only pursue these later.

Thanks a lot,



Michael B.

________________________________________

Michael Broughan,

Programme Manager - Acision SWA

+44 7771 724 999 (UK)

+91 9320 054 008 (India)



________________________________

From: Gupta, Nitin

Sent: 29 July 2010 12:12

To: Martinez Puig, Juan; Schimmer, Martin; Broughan, Michael; Goudakov, Edouard

Cc: Rodrigues, Kevin; internal.supportweb; Keeling, David; Randus, Jiri; Dimitrov, Viden




Hi Juan,

We have got ultimatum from Customer for go live on 31st July. If we are not able to solve this issue, Customer has agreed to configure all CDMA traffic as GSM traffic itself. In order to do that I need to work for at least 12 to 16 hours to roll back from existing configuration from Dual Stack to Single Stack and thenfelicitate testing.



Michael / Edward: We need to have someone to inform me by taking this request as Business Call whether we spend time in trying the configurations suggested by Brazil or we move ahead as per Customer agreement.

Pros: If we are successful meeting the customer requirement, it would save our efforts of roll back



Cons: If testing fails, we drift further from our go live date which is 31st July,2010.

Please let me know your opinions.



Regards

Nitin Gupta



-----Original Message-----

From: Martinez Puig, Juan



Cc: Rodrigues, Kevin; Broughan, Michael; internal.supportweb; Keeling, David; Randus, Jiri; Dimitrov, Viden; Goudakov, Edouard




Hi Nitin,



No answer from PM yet. We have got some tips from the Brazil office I have justpassed to you. Depending on that outcome I will chase for feedback from PM on apossible delivery date, althouhg if a CR is required this can take some time toget.

Regards,



Juan

________________________________________



From: Gupta, Nitin


To: Schimmer, Martin; Martinez Puig, Juan



Cc: Rodrigues, Kevin; Broughan, Michael; internal.supportweb; Keeling, David; Randus, Jiri; Dimitrov, Viden; Goudakov, Edouard


Hi Juan,



Do we have any response from PU on this? What is the final update we on this...Reliance is looking for update from our side.

Regards,



Nitin Gupta

________________________________

From: Gupta, Nitin



Sent: Tuesday, July 27, 2010 2:40 PM

To: Schimmer, Martin; Martinez Puig, Juan

Cc: Rodrigues, Kevin; Broughan, Michael; internal.supportweb; Keeling, David; Ra

ndus, Jiri; Dimitrov, Viden




Hi Martin,

Thanks for the information.



Juan: May I request you to take this up with PU.



Regards

Nitin Gupta

________________________________

From: Schimmer, Martin




To: Gupta, Nitin; Dimitrov, Viden; Martinez Puig, Juan

Cc: Rodrigues, Kevin; Broughan, Michael; internal.supportweb; Keeling, David; Randus, Jiri




Nitin,



frankly, I don't know how to achieve what you need. Unfortunately our knowledgeof CDMA is rather low comparing the GSM, obviously due to the fact that majority of the incidents reaching Sustaining are GSM related. Quick check of availabledocumentation didn't show any configuration option which would affect format ofOriginator address in CDMA MT message. That does not mean it's not there, it's just that we in Sustaining are not aware of it. As Viden pointed out before, the

switch recommended by PM affects ODA as opposed to OOA.

Regards!



Martin

From: Gupta, Nitin



Sent: Tuesday, July 27, 2010 10:03 AM

To: Dimitrov, Viden; Martinez Puig, Juan

Cc: Rodrigues, Kevin; Broughan, Michael; SupportWeb - Acision; Keeling, David; Randus, Jiri; Schimmer, Martin




Hi Viden,

Sustaining engineer who is assigned to this incident just need to let us know if there is configuration using which this can be achieved as you are right the parameter suggested by PU is ODA and we need OOA to be appearing as National Format irrespective of the Presentation address. Applied using ADT.



Thanks and Regards

Nitin Gupta



________________________________

From: Dimitrov, Viden




To: Martinez Puig, Juan

Cc: Rodrigues, Kevin; Gupta, Nitin; Broughan, Michael; SupportWeb - Acision; Keeling, David; Randus, Jiri; Schimmer, Martin




Hello Juan,

After an extended time spent on clarifying the details we managed to figure out that your team is trying to modify OOA - Originator Originator Address number

. If you take a closer look at the release note provided by PM, you would see that it talks about ODA - Originator Destination address number. With this said Sustaining answer to your question is that the applied functionality does NOT match the intended one and we are not aware that the wanted one exists.



I would recommend you to walk back the road from customer proposal to solutionrelease and trace either at which stage the missing functionality was created or what is the release note refereeing to it.



P.S. In order to speed incident handling please make sure that the attached Sustaining Escalation checklist is went through by 2nd line engineers before Sustaining help is requested.

Thank you!



Best Regards

Viden




Sent: 26 July 2010 13:41



To: Dimitrov, Viden

Cc: Rodrigues, Kevin; Gupta, Nitin; Broughan, Michael; SupportWeb - Acision




Hi Viden,

We have already configured the system according to the information provided.



The result is not as expected.

Therefore I don't understand why this is a configuration activity.



Regards,

Juan



________________________________


Sent: 26 July 2010 13:32




Cc: Rodrigues, Kevin; Gupta, Nitin; Broughan, Michael; SupportWeb - Acision

Subject: INC00269022 RE: Reliance india - mt source address formatting



Juan,

This is NOT an issue report but request for system configuration. As indicated in my previous email, this needs to be treated via Resource Request. The incident does NOT qualify neither as issue report nor as Sustaining escalation ( mandatory documents missing ) thus it will be rejected. For your convenience, Sustaining Resource request process communication, distributed March 17 2010 is provided below. The form is ttached.



All,



this is to inform you that the method to request Sustaining resources for activities that extend beyond day-to-day Sustaining operations (project assignments, for instance) has been now formalized and is now similar to process that is currently in use for requesting CSI resources. In order to raise resource request with Sustaining, please use the form attached, provide all requested information and send the request back to following mailbox: [email protected]<mailto:[email protected]> (or search for SustainingResource Request in company address book).

Note that from now on, this is the only way for resource requests to be accepted. Requests addressed to resource request mailbox will be processed in next 3 business days.



Best Regards



Viden




Sent: 26 July 2010 13:18

To: Dimitrov, Viden

Cc: Rodrigues, Kevin; Gupta, Nitin; Broughan, Michael



Subject: RE: Reliance india - mt source address formatting

Importance: High

Hi Viden,



We have created an incident INC00269022 for this issue.



Deployment engineers (Nitin Gupta) and PU engineers haven't been able to figureout what is wrong.

Can someone from your team have a look ASAP?



Regards,

Juan



________________________________


Sent: 23 July 2010 16:36



Juan,

The need is well understood and the correct path is the one I've already indicated. If your project resource is not sufficient then another one needs to be requested.




Sent: 23 July 2010 15:36



To: Dimitrov, Viden





Hi Viden,

The systems are in Nikita, however the regional team hasn't created the right users. I have already raised this.



We need some SMSc expert that checks if the configuration that we have applied according to the documentation provided by PM is correct, and if correct then toknow if the designed result is achievable. Depending on the outcome we can fix the problem, or raise a CR or a PR.



So currently, it seems to be a configuration issue but the deployment engineer doesn't have the required in-depth knowledge to figure out what might be going wrong, if it is an issue.

Regards,



Juan

________________________________




Sent: 23 July 2010 15:20






Hi Juan,



Two comments on your request. It's very strange that system that is about to become live is not yet in Nikita?! This is quite big project which is most probably going for months so why support is not planned and arranged ?!



Your request is not support one but requiring solution design - project one. If regional solution designers and 2nd line resources are not sufficient, resource request should be placed towards CSI and Sustaining if needed.

Best Regards



Viden


Sent: 23 July 2010 13:31



To: Dimitrov, Viden


Subject: Reliance india - mt source address formatting



Importance: High

Hi Viden,



We are about to go live in Reliance India Mumbai site for SMSc. However we havefound a requirements that the region is struggling with.

Currently we can't create incidents (I'm already chasing this to be fixed by the

region), so I would like to see if one of your guys could provide some urgent feedback on the issue below.



Basically we have CDMA and GSM networks linked to the SMSc.

It is required that the number format that appears on the sms at the recipient side is shown depending on the recipient network.

For CDMA it should be national format (0xxxxx)



For GSM it should be E.164 format (+91xxxx).

Product management provided the attached information and we applied them.



However we can't reproduce the behavior desired.

Below I have added all the information until now.



Is there anyone from your SMSc team that could help us out?

The engineer to contact is Nitin Gupta (on cc)



Regards,

Juan



DETAILED SCENARIO:

We have SMSC in Reliance deployed as Dual mode wherein we have default PLMN type as GSM.



Reliance SMSC Configuration : Configured for SMS MO and SMS MT for both Reliance GSM as well as their CDMA Subscribers. We are doing the swapping of their existing home developed SMSC.



Existing SMSC in Reliance :

1. Any MT SMS for Reliance CDMA subscribers have Source Address appearing as National format i.e 0+< Mobile Number of Originator>.



Originator (Source Address) can be subscriber either of Reliance GSM , Any India GSM Mobile , Any India CDMA Mobile other than Reliance and even Reliance CDMA.

2. Any MT SMS for Reliance GSM Subscriber must have Source Address appearing asE.164 Format i.e +91< Mobile Number of Originator>



3. All their CDMA handsets read Source Address from Original Originating Address instead of Call back number.



Challenge A :

Originator : Reliance GSM Number +91902200034



Recipient : Reliance CDMA Number 9320196304

It is observed that when Acision SMSC is terminating the SMS for any Reliance CDMA subscriber originated by any Reliance GSM, Souce CLI is appearing on CDMA han

dset as 919022000034, which is not correct



format. However GSM to any India GSM Source Address comes with correct E.164 format which is +91 + OrigMSISDN



Challenge B :

Originator : Reliance CDMA Number 9320196304



Recipient : Reliance GSM Number +91902200034

However when any Reliance CDMA subscriber originates SMS to any GSM Mobile ( either Reliance or any other operator) we see Source Address as 0+CDMA MDN, which i

s again not correct format. However when any



Reliance CDMA to CDMA Subscriber sends message with each other, they see correct Source CLI for i.e 0+MDN.

Using ADT on SIWCDMA if I translate the presentation address in International Format for Source Addresses, I see that I am able to overcome Challenge B, however then I see issue with Reliance CDMA to CDMA i.e



we see Source Address as 91+<MDN>, which is same as Challenge A observation.

We have SIGTRAN connectivity between Reliance STP and our SMSC. We have options

in IS41 Common Class to define how MDN format to be used wheather National or International in MT SMS Request but there is no

option/ configuration where in its possible to define Ortiginal Originating Address representation in MT SMDPP.



With this kind of an issue, I see we have hit road block. Requests your expert views on the same.



------------------------------------------------------------------------------------------------------------------------------------------------



REQUIRED STEPS: Attached mail from product management.



------------------------------------------------------------------------------------------------------------------------------------------------



CURRENT SETUP: (From Nitin Gupta)

I have just concluded the testing with following IS41 common class configurations.



PML> sh cl is41/ver

Response from IS41_12

Version: V05.21N



PML> sh cl siwcdm/ver

Response from SIWCDMA_12

Version: V05.21R



PML> sh cl diwcdma/ver

Response from DIWCDMA_12

Version: V05.21R



PML> sh cl is41_/all



Maximum number of simultaneous active sessions: 10000

/MAXSESSIONS

Accept IS-41 messages containing SMS Subaddress



information: YES

/ACCEPT_SUBADDR

Accept SMS Charge Indicator value



'No charge': NO

/ACCEPT_NO_CHARGE


'Charge original originator': NO



/ACCEPT_CHARGE_ORIG


'Charge original destination': YES



/ACCEPT_CHARGE_DEST

Enable indirect routing: NO

/ENA_INDIRECT_ROUTING



Time-out value for SMSRequest INVOKE: 15 seconds

/SMSREQUEST_TO

Time-out value for SMSDeliveryPointToPoint INVOKE: 45 seconds

/SMSDELIVERY_TO



Use MIN Map: OFF

/USE_MIN_MAP

Use MobileDirectoryNumber in SMSRequest: ON



/USE_MDN_IN_SMSREQUEST

Use MIN in the SMSRequest: OFF

/USE_MIN_IN_SMSREQUEST



MDN in the SMSRequest in NAT/INTERNAT mode: NATIONAL

/MDN_SMSREQ_ADDR_MODE

Use MobileDirectoryNumber in SMSDeliver: ON

/USE_MDN_IN_SMSDELIVER



MDN in the SMSDelivery in NAT/INTERNAT mode: NATIONAL

/MDN_SMSDEL_ADDR_MODE

Originating MDN numbering plan: DEFAULT



/ORIG_MDN_NUM_PLAN

Charge Indicator for mobile-terminated messages: NONE

/CHARGE_IND



Notification Indicator for SMSRequest messages: DEFAULT

/SMSREQUEST_NOTIF_IND

Notification Indicator for SMSDeliver messages: DEFAULT

/SMSDELIVER_NOTIF_IND



Use Address Matching to determine NON: OFF

/NON_REPLACEMENT

Default Global Title GTI value: 4



/GT_GTI_DEFAULT

Optional SMS_Teleservice in a SMSRequest: OFF

/USE_TSID_IN_SMSREQUEST



Type of Digits in the OOA in a SMSDeliver: 0

/OOA_TYPE_OF_DIGITS

Force the numbering plan to Telephony: ON

/SUBMIT_NUM_PLAN



Include PC: OFF

/PC_INCLUDE

Note : I did restart SIW,DIW and IS41 entities to be sure that all configuration done in Common class are effective.



The outcome of the testing is that I have made use of ADT i.e modified siwcdma_adt.cnf to translate Source Address into International Format so that any SMS originated from CDMA handset towards another CDMA handset should come with 0+MDN and Source Address towards any GSM Mobile should be displayed as +91+MSISDN.



I can see that I am able to see Originator Address as +91+MSISDN on GSM handsetfor SMS originated from CDMA Handset, however towards another CDMA handset, I still see the Source Address as 91+MDN instead of 0+MDN.

Please see the IS41 trace for CDMA 2 CDMA scenario.



20:21:47.74|04803628|ADT: Using POAD instead of MOAD

20:21:47.74|04803628|idi_addr_set_addr_and_pref: e164: cc=91 ip=00 tp=0 tc=10 lp= ; x121: cc= ip=

20:21:47.74|04803628|idi_addr_pad_telem_enc: Start address: '919324140452' npi:NPI_TELEPHONE ton:TON_INTERNATIONAL pid: PID_PLMN



20:21:47.74|04803628|idi_addr_pad_telem_enc: action chosen: K_ACTION_E164

20:21:47.74|04803628|idi_addr_encode_raw: Encoding address: '919324140452' npi:NPI_TELEPHONE ton:TON_INTERNATIONAL pid: PID_PLMN

20:21:47.74|04803628|idi_addr_encode_raw: Encoded address 0x000C91193942414025FFFFFFFF



20:21:47.74|04803628|idi_addr_pad_telem_enc: Encoded address 0x000C91193942414025FFFFFFFF

20:21:47.74|04803628|ADT: Using PRAD instead of MRAD

20:21:47.74|04803628|dcdma_copy_idi_info_to_context: Number of Voice Messages is

[0] [x00].

20:21:47.74|04803628|T|11001|-0001|Old State:CLOSED , Event:DELIVER -> action:deliver



20:21:47.74|04803628|dcdma_convert_user_data: OENC: 5, DCS_INTERPRET: 0xF000 gives IDI encoding 5, CDMA encoding 2

20:21:47.74|04803628|Message contents has 8-bit data encoding

20:21:47.74|04803628|length of message contents is 1



20:21:47.74|04803628|dcdma_convert_user_data: CDMA encoding 2 gives new OENC 5

20:21:47.74|04803628|Resulting CDMA encoding 2, MLEN 1, octets 1

20:21:47.74|04803628|Use numeric OA as CBN for teleservice WEMT,CMT, VMN or CPT.



20:21:47.74|04803628|idi_addr_format_address: Decoded address '0x000C91193942414025FFFF

Cbn Cli Know

Documents

Transcript of Cbn Cli Know