Technical GuideNumber Information Services

Version 1.7

Sophisticated Simplicity In Mobile InteractionSophisticated Simplicity In Mobile Interaction

Table of Contents

1. Introduction to Number Information Services 3

2. Technical Overview 32.1. Interface Information

3. Communication Process (per Interface) 33.1. SIP Protocol3.1.1. SIP-Service using MCC+MNC3.1.1.1. Successful Query 3.1.1.2. Unsuccessful Query3.2. H.225 Protocol3.2.1. Successful Query3.2.2. Unsuccessful Query3.3. ENUM Protocol3.3.1. Successful Query3.3.1.1 Global Number Portability3.3.1.2 Global Number Verification3.3.2. Unsuccessful Query

4. Additional Features 94.1. MSRN Stop4.2. Result Adjustment

5. Glossary of Terms 10

6. Contact Information 10

Page

3

1. Introduction to Number Information Services

tyntec’s Number Information Services enable companies to perform number portability resolution, subscriber database cleaning, compile statistical data, implement anti-fraud procedures and ID verification. These services provide network information from databases, from the mobile network and from other sources. In the Number Information Services family, tyntec offers two products: Global Number Portability and Global Number Verification.

Figure 1. The Number Lookup Communication Process

2. Technical Overview

2.1. Interface Information

Currently the following protocols are offered for the Number Information Services: SOAP, SIP, H.225 and ENUM. This document describes SIP, H.225 and ENUM. Separate documents are available for the SOAP protocol. The following is important for SIP, H.225 and ENUM:

• There is no username or password that have to be transmitted• Authentication is based on the IP of the customer• There is no unique identifier, a.k.a. the message id known from other tyntec products. Identification of

individual queries is based on the mobile MSISDN queried, the IP the query came from and the exact time when the number was queried

• tyntec can customize the maximum time used before a result is given back.

3. Communication Process (per Interface)

3.1. SIP Protocol

The SIP protocol is a text (ASCII) based protocol similar to HTTP (but not compatible). It is based on UDP communication, which in general means that there is no guarantee from the protocol stack that packets arrive at their destination. The following are the characteristics for the communication:

Customer

Step 1 – Sending check request (number)

Step 2 – Delivering result (number portability information)

4

(1) Request type is INVITE(2) Standard IP for the customer to connect to is 78.110.226.165(3) Standard port for the customer to connect to is 5060 (4) Queried MSISDN needs to be placed in the To-Header(5) Result (MNC+MCC or CC+NDC) will be placed in the response Contact-header

Address formats

The tyntec SIP service supports two address formats in the request and response: sip- and tel-addresses.

• sip address: +3330314 <sip:wol@localhost:5060>• tel address: <tel:+3330314>

Customers can arbitrarily choose between the two formats. tyntec will always use the chosen format in the response.

Result formats

tyntec is able to return the result in two ways. The result can be returned as either MCC+MNC or as a routing number according to RFC 4694 consisting of CC + NDC. Both result formats can be combined with all supported address formats. The result format can be set by Customer Relations according to the customer’s choice.Please refer the following URL for information about RFC 4694: http://www.rfc-archive.org/getrfc.php?rfc=4694

3.1.1. SIP-Service using MCC+MNC

The most important parameters for each request are the call ID, which is used as the reference for the response and the MSISDN which is queried. The MSISDN is given in the To header as a sip address or as a tel address. E.g. for MSISDN +3330314 the To-header using sip address would be: To: +3330314 <sip:wol@localhost>tag=423535.

An example for a request would be the following:

INVITE sip:wol@localhost SIP/2.0Via: SIP/2.0/UDP 192.168.178.20:5061;rport;branch=z9hG4bKD56261D1EE4B411FAA665C7229C09094From: User <sip:304@localhost:5061>To: +3330314 <sip:wol@localhost>tag= 423535Contact: <sip:304@192.168.178.20:5061>Call-ID: 33B45093-BD7B-42F2-B08A-CAF313838177@192.168.178.20CSeq: 61239 INVITEMax-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite? release 1103mContent-Length: 249v=0 o=304 59598390 59598734 IN IP4 192.168.178.20 s=X-Lite c=IN IP4192.168.178.20 t=0 0 m=audio 8000 RTP/AVP 0 98 97 101 a=rtpmap:0 pcmu/8000a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101telephone-event/8000 a=fmtp:101 0-15

Using the tel address format the To-header would be: To: <tel:+3330314>. An example for a request would be the following:

INVITE tel:+3330314 SIP/2.0 Contact: <sip:8147779903@200.13.24.51:5060> Via: SIP/2.0/UDP 65.203.166.40:50:60;branch=z9hG4bK0eB4d09093cc8cea6 From: <sip:8147779903@200.13.24.51:5060;bgid=1234;bgt=private> To: <tel:+3330314>

5

Call-ID: 929473_4305@200.13.24.51 CSeq: 1551 INVITE Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,INFO,SUBSCRIBE,NOTIFTY,UPDATE,OPTIONS Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay P-Prefered-Identity: <sip:8147779903@200.13.24.51:5060>

Supported: timer,100relSession-Expires: 1800 Content-Length: 0The possible responses to such requests will be explained in the following sections.

3.1.1.1. Successful Query

In the case of success a REDIRECT Moved Temporarily (302) will be sent, with the result delivered in the Contact header. The address format of the response will be the same format the MSISDN was sent in. In case of a sip address the response will be in the following format: <sip:MCC+MNC+MSISDN+TTID@IP of the To header in the INVITE request>. The TTID represents tyntec‘s operator ID.

The following is an example for a successful response using a sip address:

SIP/2.0 302 Moved TemporarilyCSeq: 1 INVITEVia: SIP/2.0/UDP 194.221.102.170:5060Call-ID: 33B45093-BD7B-42F2-B08A-CAF313838177@192.168.178.20From: „User“ <sip:304@localhost:5061>To: „+3330314“ <sip:wol@localhost>Server: oSIP-registrar/0.0.1Contact: <sip:03333333031436@localhost>Max-Forwards: 70Content-Length: 0

In case of a tel address the response will be in the following format: <tel:MCC+MNC+MSISDN+TTID >. TTID represents tyntec‘s operator ID.

The following is an example for a successful response using a tel address:

SIP/2.0 302 Moved TemporarilyContact: <tel:03333333031436>;expires=0To: <tel:+3330314>From: <sip:8147779903@200.13.24.51:5060;bgid=1234;bgt=private>Via: SIP/2.0/UDP 194.221.102.170:5060CSeq: 1 INVITECall-ID: 929473_4305@200.13.24.51Max-Forwards: 70Server: oSIP-registrar/0.0.1Content-Length: 0

3.1.1.2. Unsuccessful Query

There are five cases in which no result can be returned. The following list shows these cases accompanied by the returned response code:

6

• The request is not parseable: BAD REQUEST (400) • The request could not be authenticated: NOT AUTHORIZED (401) • The system handling the request is not able to handle the request at this time: BUSY HERE (486) • The Request could not be processed in time: SERVER TIMEOUT (504)• The number does not exist or is not a callable MSISDN (e.g. it is a Global Title): DOES NOT EXIST ANYWHERE

(604) • SIP-Responses from the Number Information Services have to be acknowledged with a SIP-ACK.

3.2. H.225 Protocol

The H.225 protocol is a binary protocol and a subset of H.323. Like SIP it is based on UDP communication, which in general means that there is no guaranteed package delivery as well. The following are the parameters for the communication:

• Request type is LocationRequest• Standard IP for the customer to connect to is 78.110.226.165• Standard port for the customer to connect to is 1719

The most important parameters for each request are the unique requestSeqNum, which is used as the reference for the response and the MSISDN which is queried. The MSISDN is given in the destinationInfo as aliasAddress in the form of dialedDigits, e.g.:

destinationInfo { aliasAddress: dialedDigits: 0333031412151}. An example for such a request would be the following (parsed output):RasMessage ::= locationRequest :{ requestSeqNum 39, destinationInfo: Sequence of 1 Item(s): { aliasAddress: dialledDigits: 0333031412151 }, replyAddress: TransportAddress: { ip ‚0a030412‘H port 33743 }, sourceInfo: Sequence of 0 Item(s): { }, canMapAlias: false, canMapSrcAlias: false,}The possible responses to such a request will be explained in the following sections.

3.2.1. Successful Query

In this paragraph the example needs to replaced by the following:

RasMessage ::= locationConfirm :{ requestSeqNum 39,

7

callSignalAddress TransportAddress: { ip ‚0a030412‘H port 332059 }, rasAddress TransportAddress: { ip ‚00000000‘H port 0 }, destinationInfo Sequence of 1 Item(s): { aliasAddress: dialledDigits: 033330333031412151 },}

3.2.2. Unsuccessful Query

In case of the system not being able to return a result for the query a LocationReject with an error description in the rejectReasonString element (in form of an IA5String) is returned, e.g.:

RasMessage ::= locationReject :{ requestSeqNum 39, locationRejectReason rejectReasonString ‚requestDenied‘H,} There are five cases in which no result can be returned. The following list shows these cases accompanied by the returned rejectReasonString::

The request is not parseable: requestDeniedThe request could not be authenticated: invalidPermissionThe system handling the request is not able to handle the request at this time: undefinedReasonThe number does not exist or is not a callable MSISDN (e.g. it is a Global Title): noRouteToDestinationThe Request could not be processed in time: undefinedReason

3.3. ENUM Protocol

ENUM is a protocol that uses the Internet DNS system to translate E.164 (i.e. ordinary) telephone numbers into IP addressing schemes (like SIP, H323 or Email). Like SIP and H.225 it is based on UDP communication, which in general means that there is no guaranteed package delivery as well. The following are the parameters for the communication:

• Record-Type is NAPTR• Domain is e164.arpa• Standard IP for the customer to connect to is 78.110.226.165• Standard port for the customer to connect to is 53

If you use multiple ENUM Number Information Services accounts (for example, one for Global Number Portability and one for Global Number Verification), you will need to originate your traffic to each such account from a distinct IP address.

The most important parameters for each request are the unique id, which is used as the reference for the response and the MSISDN which is queried. The MSISDN needs to be transformed using the following steps:

8

1. See that the E.164 number is written in its full form, including the country code IDDD. Example: +1-51-458682912. Remove all non-digit characters with the exception of the leading ‚+‘. Example: +151458682913. Remove all characters with the exception of the digits. Example: 151458682914. Put dots („.“) between each digit. Example: 1.5.1.4.5.8.6.8.2.9.15. Reverse the order of the digits. Example: 1.9.2.8.6.8.5.4.1.5.16. Append the string „.e164.arpa“ to the end. Example:1.9.2.8.6.8.5.4.1.5.1.e164.arpa .

An example for such a request can be sent using e.g. the dig command:dig @195.162.239.181 IN NAPTR 1.9.2.8.6.8.5.4.1.5.1.e164.arpa

and would look like this:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43692;; flags: rd ; qd: 1 an: 0 au: 0 ad: 0;; QUESTIONS:;; 1.9.2.8.6.8.5.4.1.5.1.e164.arpa., type = NAPTR, class = IN;; ANSWERS:;; AUTHORITY RECORDS:;; ADDITIONAL RECORDS:

The possible responses to such a request will be explained in the following sections.

3.3.1. Successful Query

3.3.1.1 Global Number Portability

In case of success a NAPTR-Record will be returned, with the result being in the answer-section as an tel-uri in the format tel:+msisdnThe following is an example for a successful response:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43692;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; WARNING: recursion requested but not available;; QUESTION SECTION:;1.9.2.8.6.8.5.4.1.5.1.e164.arpa. IN NAPTR;; ANSWER SECTION:1.9.2.8.6.8.5.4.1.5.1.e164.arpa. 60 IN NAPTR 10 100 “u“ “E2U+tel“ “!^.*!tel:+15145868291\;mcc=11\;mnc=103 \;ttid=4345\;e=0!“;; Query time: 321 msec

Here is the explanation of the parameters:

mcc: Subscription network Mobile Country Codemnc: Subscription network Mobile Network Codettid: tyntec operator IDe: SS7 network error code. This value provided if it is available to tyntec. A value different than zero does not indicate a failed query. The error code parameter can be interpreted according to the error code documentation supplied by tyntec.

9

3.3.1.2 Global Number Verification

In case of success a NAPTR-Record will be returned, with the result being in the answer-section as an tel-uri in the format tel:+msisdn. The ENUM protocol permits maximum 255 bytes in the ANSWER section. If the Global Number Verification response contains more information than can fit in 255 bytes, it will use two ANSWER sections.

The following is an example for a successful response:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43692;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; WARNING: recursion requested but not available;; QUESTION SECTION:;1.9.2.8.6.8.5.4.1.5.1.e164.arpa. IN NAPTR;; ANSWER SECTION:1.9.2.8.6.8.5.4.1.5.1.e164.arpa. 60 IN NAPTR 10 100 “u“ “E2U+tel“ “!^.*!tel:+15145868291\;nrh_mcc=11\;nrh_mnc=103\;nrh_c=USA\;nrh_ttid=4345\;hlr_mcc=11\;hlr_mnc=103\;hlr_c=USA\;hlr_ttid=4345\;imsi_mcc=11\;imsi_mnc=103\;imsi_c=USA\;imsi_ttid=4345\;msc_mcc=11\;msc_mnc=103\;msc_c=USA\;msc_ttid=4345\;port=0\;roam=0\;pres=1!”.1.9.2.8.6.8.5.4.1.5.1.e164.arpa. 60 IN NAPTR 10 100 “u“ “E2U+tel“ “!^.*!tel:+15145868291\;e=0!“ ;; Query time: 321 msec

Here is the explanation of the parameters:

nrh_mcc: Number Range Holder Mobile Country Codenrh_mnc: Number Range Holder Mobile Network Codenrh_c: Number Range Holder Mobile Network Codenrh_ttid: Number Range Holder operator IDhlr_mcc: Subscription network Mobile Country Code (based on answering HLR)hlr_mnc: Subscription network Mobile Network Code (based on answering HLR)hlr_c: Subscription network country (based on answering HLR)hlr_ttid: Subscription network operator ID (based on answering HLR)imsi_mcc: Subscription network Mobile Country Code (based on IMSI)imsi_mnc: Subscription network Mobile Network Code (based on IMSI)imsi_c: Subscription network country (based on IMSI)imsi_ttid: Subscription network operator ID (based on IMSI)msc_mcc: Servicing (roaming) network Mobile Country Codemsc_mnc: Servicing (roaming) network Mobile Network Codemsc_c: Servicing (roaming) network countrymsc_ttid: Servicing (roaming) network operator IDport: porting flag (1 = number ported; 0 = number not ported)roam: roaming flag (1 = number roaming; 0 = number not roaming)pres: presence flag (1 = handset turned on; 0 = handset turned off)e: SS7 network error code. A value different than zero does not indicate a failed query. The error code parameter can be interpreted according to the error code documentation supplied by tyntec.

3.3.2. Unsuccessful Query

In case of the system not being able to return a result for the query a NAPTR-Record is not returned. Instead the request is returned with an error code in the status element is returned, e.g.:

10

;; ->>HEADER<<- opcode: QUERY, status: NOTZONE, id: 43692;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0;; WARNING: recursion requested but not available;; QUESTION SECTION:;1.9.2.8.6.8.5.4.1.5.1.e164.arpa. IN NAPTR;; Query time: 352 msec

There are cases in which no result can be returned. The following list shows these cases accompanied by the returned status:

• The msisdn format is invalid: REFUSED• The request could not be authenticated: NOTAUTH• The number does not exist or is not a callable MSISDN (e.g. it is a Global Title): NOTZONE• The request could not be processed in time: BADTIME

4. Additional Features

4.1. MSRN Stop

tyntec is able to filter Mobile Station Roaming Numbers (MSRNs). MSRN-Filtering can be enabled by Customer Relations according to the customer’s choice.

4.2. Result Adjustment

tyntec is able to adjust the results by adding additional “0” when the query gives out a 5-digit result, and hence have only 6-digit results. This feature can be enabled by customer relations according to customer’s choice.

5. Glossary of Terms

• ASCII: American Standard Code for Information Interchange (ASCII) is a character encoding based on the English alphabet.

• CC: The Country Code (CC) according to ITU-T recommendation E.164 is a code of 1-3 digits which identifies a specific country the integrated numbering plan, e.g. country code for the UK is 44.

• ENUM: ENUM is a protocol that uses the Internet DNS system to translate E.164 telephone numbers into IP addressing schemes (like SIP, H323 or email).

• H.225: The H.225 protocol is a binary protocol and is a member of H.323 family of protocols.• HTTP: Hyper text transfer protocol.• MCC: This is a list of Mobile Country Codes (MCCs) defined in „Land Mobile Numbering Plan“ for use in

identifying mobile stations in wireless telephone networks, particularly GSM. This consists of 3 digits, e.g. 234 for UK.

• MNC: Mobile Network Code is a number identifying a mobile network operator in a specific mobile country consisting of 2 or 3 digits, e.g. 58 for Manx Telecom.

• MNP: Mobile Number Portability is a facility which allows mobile subscribers to retain their mobile number when moving between mobile networks.

11

• MSISDN: Mobile Subscriber ISDN Number.

• MSRN: The Mobile Station Roaming Number is an E.164 defined telephone number used to route telephone calls in a mobile network.

• NDC: The National Destination Code (NDC) is a nationally optional code field, within the E.164 number plan, which identifies a telephone network or telephone operator.

• SIP: Session Initiation Protocol is an application-layer control (signaling) protocol. It is based on a text (ASCII) based protocol similar to HTTP.

• UDP: User Datagram Protocol is one of the core protocols of the Internet protocol suite.

6. Contact InformationPlease contact tyntec’s Customer Relations for the enabling of features and for commercial conditions:

Email: customer-relations@tyntec.comPhone: +49 700 TYNTECBIZ or +49 89 202 451 200Fax: +49 89 202 451 101

Munich +49 (89) 202 451 100 – London +44 (207) 436 0283 – Singapore +65 6478 3020 – San Fransisco +1.415.608.6127E-Mail sales@tyntec.com www.tyntec.com

Sophisticated Simplicity In Mobile Interaction