Dear Prajnananda,
I think, just like that we cannot convert the phone number to hex.We
suppose to encode it according to ASN.1 specification.For example,if the
phone number is TBCD String ,we have to encode it as follows,
Ex. + 91 9841012030 ,this number is encoded as
XX 19 89 14 10 02 03 ,where XX is Type of Number and Numbering Plan
Indicator.
regards
KB Devaraj
RPg Cellular Services Ltd
Chennai,India
GSM : +91 9841012030
> -----Original Message-----
> From: Prajnananda Tripathy, Noida [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, June 14, 2002 9:34 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [ASN.1] Question about AddressStringExtended data type
>
> Hi Gábor,
> I got the point what exactly u wanted to ask. I think u must be using
> some ASN.1 compiler for encoding and decoding .U can convert the phone
> number to hex and set it in the place of the phone number in the
> structure.
> Then u can call the encode routine to encode the
> CDR . Hope this will be of your help.
>
> Regards,
> Prajnananda
>
>
>
> -----Original Message-----
> From: Cseresnyés Gábor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 4:35 PM
> To: '[EMAIL PROTECTED]'
> Subject: FW: [ASN.1] Question about AddressStringExtended data type
>
>
> Hi Prajnananda,
>
> Thank you for your answer.
>
> The problem is that these are the details of type AddressString, but I
> meant a brandnew type: AddressStringExtended
> This has also 3 parts: TON, NPI and the phone number, but the the 3rd part
> can have 2 kind of encoding: TBCD and Character representations.
> My question is what controls that which encoding is used?
> The documentation contains only this about:
> "Subsequent octets representing address digits or characters are encoded
> as
> TBCD string or as GSM 7-bit default alphabet character depending on the
> TON
> value."
> What is the rule? How is the encoding depending on the TON value?
>
> Gábor
>
> Gábor Cseresnyés
> Allround Informatika Kft.
> www.allround.net
>
>
>
>
> -----Original Message-----
> From: Prajnananda Tripathy, Noida [mailto:[EMAIL PROTECTED]]
> Sent: 2002. június 13. 10:52
> To: [EMAIL PROTECTED]
> Subject: RE: [ASN.1] Question about AddressStringExtended data type
>
>
> Hi Cseresnyés Gábor,
> Let me know what excatly u are looking for . The AddressString in
> mobile communication can also be the TBCD type. This type (Telephony
> Binary
> Coded Decimal String) is used to
> -- represent several digits from 0 through 9, *, #, a, b, c, two
> -- digits per octet, each digit encoded 0000 to 1001 (0 to 9),
> -- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
> -- as filler when there is an odd number of digits.
>
> -- bits 8765 of octet n encoding digit 2n
> -- bits 4321 of octet n encoding digit 2(n-1) +1 which require
> diffrernt type of encoding .
>
> AddressString is composed of
> a) one octet for nature of address, and numbering plan
> indicator.
> b) digits of an address encoded as TBCD-String.
>
> a) The first octet includes a one bit extension indicator, a
> 3 bits nature of address indicator and a 4 bits
> numbering
> plan indicator, encoded as follows:
>
> bit 8: 1 (no extension)
>
> bits 765: nature of address indicator(TON)
> 000 unknown
> 001 international number
> 010 national significant number
> 011 network specific number
> 100 subscriber number
> 101 reserved
> 110 abbreviated number
> 111 reserved for extension
>
> bits 4321: numbering plan indicator (NPI)
> 0000 unknown
> 0001 ISDN/Telephony Numbering Plan (Rec CCITT E.164)
> 0010 spare
> 0011 data numbering plan (CCITT Rec X.121)
> 0100 telex numbering plan (CCITT Rec F.69)
> 0101 spare
> 0110 land mobile numbering plan (CCITT Rec E.212)
> 0111 spare
> 1000 national numbering plan
> 1001 private numbering plan
> 1111 reserved for extension
>
> all other values are reserved.
>
>
> Regards,
>
> Prajnanananda
> Prajnananda Tripathy
> Telecom Group
> HCL Technologies Ltd.
> A-5, Sector-24, NOIDA, U.P.
> INDIA - 201301
> Phone: +91-120-453-4266 Extn. 2321
> Fax : +91-120-444-0155
> Web : http://www.hcltechnologies.com
>
> Disclaimer:
> --------------------------------------------------------------------------
> -
> -
> ----------
> This document is intended for transmission to the named recipient only. If
> you are not
> that person, you should note that legal rights reside in this document and
> you are not
> authorized to access, read, disclose, copy, use or otherwise deal with it
> and any such
> actions are prohibited and may be unlawful. The views expressed in this
> document are
> not necessarily those of HCL Technologies Ltd. Notice is hereby
> given
> that no
> representation, contract or other binding obligation shall be created by
> this e-mail,
> which must be interpreted accordingly. Any representations,
> contractual
> rights or
> obligations shall be separately communicated in writing and signed in the
> original by
> a duly authorized officer of the relevant company.
> --------------------------------------------------------------------------
> -
> -
> ----------
>
>
>
>
>
> -----Original Message-----
> From: Cseresnyés Gábor [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 12, 2002 12:00 AM
> To: '[EMAIL PROTECTED]'
> Subject: [ASN.1] Question about AddressStringExtended data type
>
>
> Dear All,
>
> I am Gábor Cseresnyés from Allround Informatika Kft., from Hungary.
> We are developing CDR processing applications for the mobile
> communications
> field, so we often handle ASN.1 BER encoded files.
>
> Although we can handle a lot of ASN.1 BER standard and quasi-standard
> (vendor-specific) data types actually we have met a new one:
> AddressStringExtended which is not clear for us.
> It can have 2 kind of encoding: TBCD and Character representations.
>
> I would like to ask you whether somebody knows more about this?
> My question is what controls the used encoding? The definition made by the
> given vendor says that it is depending on the value of the TON part.
> Ok, but how?
>
> Have you got any idea?
>
> Best regards
>
> Gábor Cseresnyés
> Allround Informatika Kft.
> www.allround.net
