Network Operations Centre Training Manual v201312

1 | P a g e

Contents

1 Introduction ......................................................................................................................... 4

1.1 Corporate Profile .......................................................................................................... 4

1.2 About the Company ..................................................................................................... 4

1.3 Mission Statement ....................................................................................................... 4

1.4 The Network ................................................................................................................ 4

1.5 Wholesale Carrier Services .......................................................................................... 4

2 Wholesale Call Traffic Flow ................................................................................................. 6

2.1 Call Flow in Detail ........................................................................................................ 6

3 Cost Table .......................................................................................................................... 8

3.1 Cost Table Navigation .................................................................................................. 8

3.1.1 Sheet 1 ................................................................................................................. 8

3.1.2 Sheet 2 ................................................................................................................. 9

3.1.3 Sheet 4 ................................................................................................................10

4 Electronic Billing System ....................................................................................................11

4.1 EBS Navigation ...........................................................................................................11

4.2 Incoming Trouble Ticket ..............................................................................................13

4.3 Creating Trouble Ticket ...............................................................................................14

5 Carrier Test ........................................................................................................................16

5.1 Quintum Equipment ....................................................................................................16

5.2 Cisco Equipment .........................................................................................................16

5.3 Carrier Test Form........................................................................................................17

5.4 Extracting CLI using DTMF Tones ..............................................................................18

6 SQL Query Browser ...........................................................................................................20

6.1 Outgoing Trouble Tickets ............................................................................................20

6.2 CDR Check .................................................................................................................22

7 SQL Query Analyzer ..........................................................................................................24

8 SQL Control Center ...........................................................................................................26

8.1 ebs Table .................................................................................................................26

8.2 ebs-ws1 Table ..........................................................................................................27

8.3 Sample Commands on using SQL CC ........................................................................27

8.3.1 Extracting the called numbers ..............................................................................27

8.3.2 Extracting traffic of specific customer and destination ..........................................28

8.3.3 Extracting the cause count of a specific carrier and destination ...........................28

8.3.4 Extracting the called number count for specific destination ..................................28

2 | P a g e

9 ASR Report File .................................................................................................................29

9.1 WS C&C ASR from Summary Table ...........................................................................29

9.2 WS Carrier ASR from Summary Table ........................................................................31

9.3 WS Customer ASR from Summary Table ...................................................................31

9.4 Hourly Statistics ..........................................................................................................32

9.5 Hourly Statistics Overflow ...........................................................................................35

9.6 Sheet 8 (Carrier Overflow Report) ...............................................................................36

9.7 Sheet 9 (Customer Overflow Report) ..........................................................................36

10 Web-based WS System .................................................................................................37

10.1 Hourly ASR Alert .........................................................................................................37

10.2 Blocked Codes List .....................................................................................................39

10.3 TT Alert .......................................................................................................................40

10.4 WS Swap ....................................................................................................................41

11 MVTS-Pro Configurations ...............................................................................................42

11.1 Carrier Interconnection ...............................................................................................42

11.2 Incoming and Outgoing GW ........................................................................................42

11.3 Standard and Premium offer for WS partner ...............................................................43

11.4 IP change of Incoming and Outgoing GW ...................................................................43

11.4.1 IP change of Incoming GW ..................................................................................44

11.4.2 IP change of Outgoing GW ..................................................................................44

11.5 Routing Update ...........................................................................................................45

11.5.1 Individual DP........................................................................................................45

11.5.2 Share DP .............................................................................................................46

11.5.3 Block DP ..............................................................................................................48

11.5.4 New breakouts (codes) adding on Existing or New route (DP) .............................49

11.5.5 General (or Global) Block list ...............................................................................50

11.5.6 DST Allow Patterns and Code Mismatch .............................................................50

12 Troubleshooting Guides .................................................................................................52

12.1 What to do and How to Respond ................................................................................52

12.1.1 Disclosing of Information to Partners ...................................................................53

12.2 Factors that Affects the Call Quality ............................................................................53

12.2.1 Media Packets .....................................................................................................53

12.2.2 Codec Negotiation ...............................................................................................53

12.2.3 Codec Incompatibility ...........................................................................................54

12.2.4 Codec Matching ...................................................................................................58

12.2.5 Multiple Codec Transcoding .................................................................................59

3 | P a g e

12.2.6 False Answer Supervision....................................................................................59

12.2.7 False Ringback Tone ...........................................................................................60

12.2.8 SIP 18x before SIP 503 Issue ..............................................................................61

12.2.9 TS, 8 - [H.323] Procedure failure..........................................................................61

12.2.10 Incorrect PDD Value .........................................................................................63

12.2.11 Loopback Call Issue .........................................................................................63

12.2.12 Firewall Issue ...................................................................................................64

12.3 MVTS Pro Issues ........................................................................................................65

12.3.1 CDR Replication stopped .....................................................................................65

12.3.2 Database Failure .................................................................................................65

12.3.3 Syntax Errors .......................................................................................................66

12.3.4 Ghost Dial Peers due to Scripting Node Bug .......................................................66

12.4 Types of Traffic ...........................................................................................................67

12.4.1 Call Center Traffic ................................................................................................67

12.5 Ring No Answer Scenarios .........................................................................................69

12.6 Look Ahead Routing (LAR) .........................................................................................69

12.6.1 How to disable LAR for specific code ...................................................................70

12.7 Post Dial Delay (PDD) ................................................................................................70

12.8 ANI Translation ...........................................................................................................70

13 Disconnect Cause Codes ...............................................................................................72

13.1 SIP Response Codes ..................................................................................................72

13.1.1 Information SIP Responses 1xx ........................................................................72

13.1.2 Successful SIP Responses 2xx .........................................................................72

13.1.3 Redirection SIP Responses 3xx ........................................................................72

13.1.4 Client Error SIP Responses 4xx ........................................................................73

13.1.5 Server Error SIP Responses 5xx ......................................................................75

13.1.6 Global Failure SIP Responses 6xx ....................................................................75

13.2 H.323 Disconnect Codes ............................................................................................77

14 Retail Works ...................................................................................................................84

14.1 Sync File .....................................................................................................................84

14.2 Export Pins .................................................................................................................89

14.3 PHCC and PPN Payment ...........................................................................................95

15 Release Notes .............................................................................................................. 100

4 | P a g e

1 Introduction

1.1 Corporate Profile

Asia Telecom is a Licensed Telecom Service Provider with its Corporate Headquarters in Hong

Kong. Incorporated in 1997, the corporation has continued to extend its footprint in Asia and the

Pacific and now has operating licenses in New Zealand, Singapore and Taiwan along with its

Business Process and Support Service Centres located in the Philippines and Indonesia. Asia

Telecom is a privately held corporation.

1.2 About the Company

Asia Telecom is a Telecommunications company incorporated in Hong Kong in 1997 with

subsidiaries in Singapore, Taiwan, New Zealand, Philippines and Indonesia. We are a licensed

telecom services provider with the PSTN Interconnect Code 1611 in Hong Kong. We provide

telecom products and value added services designed to meet the needs of consumers and

corporations at affordable prices, backed by efficient customer support services in nine regional

languages, and cutting-edge technology. For your home or for your business, we have

customized long distance plans and services that suit your communication needs and your

budget. In addition, we offer value added services such as Audio Conferencing, International

Roaming, and Global Calling Cards along with data services such as SMS Broadcasts and

Mobile SIM Recharge services. Our philosophy is echoed in our mission statement.

1.3 Mission Statement

To provide quality and affordable communication services backed by efficient customer care.

1.4 The Network

Asia Telecom's primary hub is located in Hong Kong. The company subsidiaries in New Zealand,

Taiwan and Singapore. Its Network Operation centres are located in Hong Kong and Philippines.

The network consists of voice switching retail for one platforms another for wholesale exchange,

as well as conference, short messaging systems and contact centre operations.

1.5 Wholesale Carrier Services

Asia Telecom's Wholesale Carrier Services division interconnects with the Major Tier 1 and Tier 2

carriers, within the region as well as globally, for traffic exchange. Focusing on selected countries,

we provide value to our partners by offering stable quality lines along with competitive rates and

supported by our professional and efficiently managed network operations centre.

Since Asia Telecom also manages its own retail telecom operations, it provides committed traffic

volumes to partners, allowing them to manage their network capacities in a planned manner.

5 | P a g e

For more information, you may visit our website

http://www.asiatel.com.hk/hk/index.html

6 | P a g e

2 Wholesale Call Traffic Flow

Supposed we have a call A, who wants to call to point B via VOIP.

Customer W which is apparently one of our interconnect partner carry this call (call traffic). Carrier

X and Carrier Y, are also our interconnect partners who have each route to connect to point B.

Asia Telecom, as a wholesale provider buys routes from Carrier Partners at an agreed rate, and

then offers to Customers with a minimum margin of profit.

2.1 Call Flow in Detail

As Customer W is an interconnect partner of Asia Telecom, their equipment (Switch W) is

connected to our Switch (ALOE Systems/MVTS Pro) via IPs, highlighted in orange. Customer W

gives their list of Origination IPs and is registered in our switch. In return, we also give them our

Termination IPs to setup on their side. Their Termination IPs should meet our Origination IPs in

order for their traffic to pass.

As Carrier X is also an interconnect partner of Asia Telecom, their equipment (Switch X) is

connected to our switch via the Outgoing IPs, highlighted in green. We give to them our

Origination IP list, and they will give their Termination IP list to register in our switch. Again, the

IPs should meet in order to traffic to pass.

Asia Telecom

Internet

Internet

A

Customer W

Carrier X

Carrier Y

B

7 | P a g e

Note: Origination IP is the IP where the traffic will come from while Termination IP is the IP where

the traffic will be received.

The Billing system is the one responsible for computing the price for each call and works in

tandem with our soft switch.

8 | P a g e

3 Cost Table

From our familiarization of EBS we tackled about finding particular partner and determining our

Offer rate to them. Based on the offered rate, we are going to find out which are the best Carriers

suitable to use at the same time making profit as well. From here, we can plan which carriers we

can route, based on their Carrier cost.

For a route we buy from Carrier X, we should sell to Customer with at least 0.0025 USD margin of

profit. We can put the concept into a formula as below:

Carrier Cost

9 | P a g e

3.1.2 Sheet 2

It contains all the available carriers with their respective costs.

Clear the page first to remove all unnecessary items.

To obtain the correct carrier cost, we should input the Country ID (which we can get from Sheet

1) under the Country ID column, then hit Command Button.

The following columns will show the Carrier name, next to it is the respective rate for the

particular breakout. (e.g. Titan costs 0.056; Speedflow costs 0.06, etc.)

Carriers are arranged from the cheapest carrier to the most expensive ones.

10 | P a g e

3.1.3 Sheet 4

It contains all the breakout available for each country. For example, Pakistan (92) is our main

code, but it is broken down into specific break outs (Pakistan Landline, Pakistan Islamabad,

Pakistan Telenor mobile, Pakistan Warid mobile, etc.) Each having specific codes and cost.

(E.g. The cost of Pakistan Fix is different from the cost of Pakistan Mobile)

You can input the country ID of Pakistan Teleneor mobile (1334) under Country ID column. Hit on

the Get List and it will list all the codes of Pakistan Telenor Mob (9234)

11 | P a g e

4 Electronic Billing System

Electronic Billing System (EBS) contains all Partners information, contacts and transactions. One

server is used to Retail Customers (192.168.78.15). And the other is used for Wholesale Partners

(192.168.78.16). As Wholesale support, EBS 192.168.78.16 is most commonly used. Below will

show you on how to navigate through and familiarize important areas.

From the browser, you can go to this IP 192.168.78.16 address and log in.

As a NOC member, you are given an administrator account (Username and Password). Note: Do

not grant access to unauthorized users.

4.1 EBS Navigation

Inside the EBS, at first you will see only blank at the Customer Area of the page. To extract

existing partners account information (ex. Speedflow Communications), you may need to fill up

the below parameters:

1. Please check you are is CS Tab (Purple arrow)

2. At the upper left area, you can see three pull down tabs (green circles). The default items

are:

*CustomerID* *= * *blank*

3. From the pull down menu, find the following parameters.

*customerName* *contain* *Speedflow*

Note: The typed keyword Speedflow should match with the terms in Customer Name as

entered on the EBS, otherwise it will show different items or will show nothing at all.

12 | P a g e

(E.g. Typing speed may get to similar results; but typing speed flow will show no

relevant results.)

4. Hit the Search button. From then you will find Speedflow Communications contact

information. You may observe that there are total of two relevant results shown. It is

because we only typed the keyword Speedflow. Thus EBS will show Speedflow

Communications Limited (Wholesales), and the other is Speedflow Communications

Limited (Premium) on the next page.

5. A few scrolls down, or by clicking Spec Rate tab, you may find the Special Rate

Information, which contains all the Rates we offer tour partner per destination/ country.

From the offered rate, we can decide which of our carriers we will use for them, if

available. There is a pull down tab if you want to filter an offer on a specific destination

only (ex. Bangladesh). You will find the below information:

a. Destination any country or destination which we offer to them for use

b. Currency normally in US Dollars per minute

c. Hour type peak or off peak time

d. Effective dates period of rate effect

e. User by trading support or account manager in charge

f. Last change

g. Record Status active or inactive

13 | P a g e

4.2 Incoming Trouble Ticket

Going back on top of the page, you will find the Trouble Ticket Tab. In this tab are all the trouble

tickets (Incoming) our partner sent to us. We keep records of the trouble tickets to easily identify

which are the ones attended and which ones are still pending for resolution.

For every trouble ticket received, we classify them according to which Customer/ Partner sent us

the ticket. We will then use EBS in order to log the ticket for proper documentation. This method

is proven effective as every member of the team can keep track on to which tickets are being

attended and by whose member.

14 | P a g e

4.3 Creating Trouble Ticket

To enter a new trouble ticket in to the EBS, we follow the below procedures:

1. From EBS 192.168.78.16, identify which is the complaining customer by the use of the pull

down tabs. (CustomerName, contain, *name of partner*). Make sure the proper truck is

specified (Standard or Premium Trunk)

2. Click on the Trouble Ticket Tab, to view all the tickets from the specific customer.

3. Click on New (above the ID column). You will see the below information which need to fill

up:

a. Title paste the subject of the email

b. Status Should be Open at first.

c. Managing Agent NOC member that register the ticket

d. Resolving Agent NOC member that will attend on the ticket

e. Severity it depends on the importance if the trouble ticket

15 | P a g e

f. Called Country Destination at fault

g. Trouble found Issue raised by customer

h. Carrier at Fault identified carrier which is causing issue

4. Click Save.

Note: For the member who will attend a trouble ticket, you need to change the status to

Resolving, then Awaiting confirmation when you replied to customer already. Once Customer

replied back and they retested OK, you should change it to Close status.

16 | P a g e

5 Carrier Test

Carrier test is a procedure where a NOC member will use a test phones to check if the carrier

routes are working or not. We have two equipment for testing, one the Quintum and the other is

the Cisco and both equipment have an external phone for dialing numbers.

5.1 Quintum Equipment

In using Quintum equipment, we us the dialing procedure:

Carrier test PIN + Country code + area code + telephone number + # sign

E.g. For dialing procedure to call to PH globe mobile using Acestar Premium Carrier

78049 639 17 5857138 #

Carrier Test Call Flow:

5.2 Cisco Equipment

In using Cisco equipment, we use the dialing procedure:

161100 + Country code + area code + telephone number + # sign

17 | P a g e

E.g. For dialing procedure to call to PH globe mobile using Acestar Premium Carrier

161100 639 17 5857138 # . . ..

Wait for the voice prompt please enter PIN number then enter the pin number below,

78049 1611 #

5.3 Carrier Test Form

For the routes offered to us by Carrier X, it is our duty as NOC to check and verify first whether a

route (country/ destination) is suitable for our Customer to use, or not. We perform carrier testing

to check for connectivity and voice quality issues. A route should always be FAS free (no false

charging) before offering to customers. With this, we use the Carrier test for in order to document

all our findings. Below is an example of Carrier test of Bangladesh mobiles via Call Foreign

(Carrier)

The below information should be clearly and completely filled up for proper reference:

Tested by member who conducted the test

Test Time Actual time the test was performed (note: should be in GMT+8 time zone)

Destination- Country or Specific breakout (landline and/or mobile)

Carrier Name should indicate Carrier Name and if Standard or Premium prefix

Dialed numbers should be correct and working number

18 | P a g e

PDD (Post Dial Delay) time between last dialed character (# sign) and time the ring back tone

is heard. It is measured in seconds.

For Standard routes PDD should not exceed 13 seconds, for Premium routes PDD should not

exceed 9 seconds.

SS results results in using Quintum equipment

Cisco results results using Cisco equipment. In some cases Cisco results are needed to

double check for FAS issues, False ringback tone or no ringback tone issues, and voice quality

issues.

Other carrier results what you get when you dial via other available carriers. This is used to

check if number is a valid number and connecting fine.

Quality rate if voice quality is poor, good, or excellent

Comments other notable comments

Recommendation OK for WS routing or NOT OK for WS routing

General Test if tested only using Quintum or using Cisco also

5.4 Extracting CLI using DTMF Tones

19 | P a g e

We have a list of CLI test numbers using DTMF. It is shared under wholesale server together with

test schedule \wholesales\Carrier Test\DTMF Test numbers for CLI checking.xls. If you have

other test numbers like this or when you got new test numbers in the future, you may add it on the

list.

Steps on testing:

1. Dial the number with which has DTMF tone responses.

2. Wait until you hear the DTMF tones after the RBT then put the test phone speaker close to

DTMF extracting device to capture the tones and decode those to number format. DTMF

extractor is a free application only on smartphones. PhoneToneExtractor for android phones

and DTMF Decoder for iOS phones

3. Finally, the app will show you the converted DTF tones to numbers and it representwhat CLI

is shown on the other end.

20 | P a g e

6 SQL Query Browser

We use this database to check for outgoing trouble tickets to carrier partner. In here we can see

all closed tickets for reference; and pending trouble tickets for us follow up.

To log in, you may need to check the following information:

Server Host:

Use IP 192.168.78.15 this is mainly used by Retail, but this is where our Retail and WS trouble

tickets are located as well.

Use IP 192.168.78.16 this is use for Wholesale, for checking WS CDRs (CDR Check)

Username: root

Password: leave it blank

Default Schema: EBS

6.1 Outgoing Trouble Tickets

Use Server Host: 192.168.78.15

Once login is successful, you may scroll down the directory on the right, until you find TTLog.

Double click to select.

21 | P a g e

After clicking you will observe that the command line on top is filled up.

This is where your command filters are being executed:

The command above reads as:

SELECT * FROM TTlog where status like %open%

The query means that you want to display all trouble tickets with status Open from the TTlog

directory. The results will be shown at the screen as below:

22 | P a g e

If you want to edit a particular ticket, you may click the Edit button at the bottom of the page,

select an area to edit. Then click Apply Changes to save.

You may want to double check if the changes took effect by rerunning the command at the top:

SELECT * FROM TTlog where status like %open%

You can apply any command filters you want by changing other defined parameters. The

parameters are based on the title of each column, highlighted in blue.

Ex. You can view all open trouble tickets to Acestar Premium for Philippines Smart mobile,

specifically

The command will be :

SELECT * FROM TTlog where status like %open% and destination like %Philippines Smart%

and problemcarrier like %Acestar P%

Note: The command line is syntax sensitive, so you may want to double check the spelling of the

parameters. Common errors occur is mistyped commands.

6.2 CDR Check

For night shift member, one must do CDR check at night (around 9 10 PM). This is to verify that

the billing system has imported all WS CDRs in an hourly manner. This is also to check if there

are missing CDR. Use Server Host: 192.168.78.16

1. Make sure you are log in to server 192.168.78.16

23 | P a g e

2. You should input two commands, one at a time. On the command line above, please type

the first command:

select distinct srcfile from cdr201211 where startdate>=curdate()

Note: cdr201211 indicates year (2012) and current month (11). You may change the month

according to current month.

3. Execute command. Results should show the hourly CDRs,

select distinct srcfile from cdr201211 where startdate>=curdate()

+-----------------------------+

| srcfile |

+-----------------------------+

| 20121110_230000.mvtspro.txt |

| 20121111_000000.mvtspro.txt |

| 20121111_010000.mvtspro.txt |

| 20121111_020000.mvtspro.txt |

| 20121111_030000.mvtspro.txt |

| 20121111_040000.mvtspro.txt |

| 20121111_050000.mvtspro.txt |

| 20121111_060000.mvtspro.txt |

| 20121111_070000.mvtspro.txt |

| 20121111_080000.mvtspro.txt |

| 20121111_090000.mvtspro.txt |

| 20121111_100000.mvtspro.txt |

| 20121111_110000.mvtspro.txt |

| 20121111_120000.mvtspro.txt |

| 20121111_130000.mvtspro.txt |

| 20121111_150000.mvtspro.txt |

| 20121111_160000.mvtspro.txt |

| 20121111_170000.mvtspro.txt |

| 20121111_180000.mvtspro.txt |

| 20121111_190000.mvtspro.txt |

4. You may observe that 20121111_140000.mvtspro.txt is missing in the series. In this case you

may need to contact HK team to check and they may reimport the missing CDR, if any.

5. You may now enter the next command on the command line. Please note again the current

month on CDR date.

select distinct srcfile from cdr201211 where startdate=(curdate) and duration>0 and

countryid=0

6. Execute command. This time there should be no records shown on the result area. Should

there be any records shown, kindly please contact HK team via phone or email, so they can

check.

24 | P a g e

7 SQL Query Analyzer

During carrier testing, we may need to look after the CDR of our test calls to check if that call was

connected to FAS (got ringing but charge). There are two practical ways in order to check for the

CDRs.

First is by checking the CDR in our MVTS-Pro using Last Hour CDR filters. Second, is by

checking the CDRs using SQL command. This tool is useful particularly when testing is done via

Cisco equipment.

Based on the Cisco equipment test call flow, there is no way to see the CDR on our soft switch

using last hour filter, unless we use Cisco 10 second PIN. The below procedure enable us to

locate the CDR from the Cisco equipment if normal Cisco test Pin is used.

1. Open SQL Server Query Analyzer. If prompt for password: type atl

2. You will be carried on to the environment as shown below

3. You may find a pull down Tab as shown, choose Reseller2 platform

4. The white space below is the command line. With this you may enter the command below.

*Note that you may want to change the date parameters to current date and pincode of the carrier

tested. (highlighted in red)

** The filters with dashes at the beginning of the line are considered disabled. If you want to

enable the filter, remove the dashes. (highlighted in violet)

25 | P a g e

select --* -- If durationnetwork is equal to 10, then it means 10 sec timeout

destination, finaldestination, datetime, trunknameout, durationconnection, setuptime,

durationnetwork, durationtotalcall, cause, channelout, clip, pincode ,computername,

othercomputername

from cdr where

(datetime >= '2011-02-11 09:00:00.000')

and pincode='770311611'

order by datetime

5. Hit Crtl+Enter key or click Execute button (looks like play key). A new window may appear at

the bottom of the screen together with the results of the query.

6. You may look at the durationconnection parameter to verify if your test call is with charging or

not. If there is duration but you got only ringing, its a sign of FAS on the route.

26 | P a g e

8 SQL Control Center

SQL Control Center (SQL CC) is also a tool which you can use on searching or

extracting traffic or test calls CDRs on billing. This is an essential tool for

troubleshooting. Initially we have created two servers which are the ebs and the ebs-

ws1 as shown on below figure.

8.1 ebs Table

ebs is also our .15 billing (Retail)

This is where you can extract the CDR of your test calls

This is where you can extract also the test calls of a new carrier partner which are

not yet having a record on our billing (normally those for interconnection test stage

yet)

27 | P a g e

The CDR from MVTS-Pro will be imported to our billing on every 40th minute per

hours

8.2 ebs-ws1 Table

ebs-ws1 is also our .16 billing (WS)

This is where you can extract the CDR of our existing WS customer traffic or test

calls.

The CDR from MVTS-Pro will be imported to our billing on every 40th minute per

hours

8.3 Sample Commands on using SQL CC

Choose which table you want to search the CDR and click the SQL button above and a

new window will appear which where you will put your command as shown on below

figure. You can use any command you want depending on what information you need to

extract but below are sample commands commonly used.

8.3.1 Extracting the called numbers

SELECT customerId, trunkNameIn, callednum, finaldestination, cause, starttime,

startdate, callingNum, szMasterPinCode, duration, szPinCliAttached

FROM `cdr201212` where callednum in ('6323879433',6326379889) and startdate >=

'2012-12-02'

28 | P a g e

8.3.2 Extracting traffic of specific customer and destination

SELECT customerId, trunkNameIn, callednum, finaldestination, cause, starttime,

startdate, callingNum, szMasterPinCode, duration, szPinCliAttached

FROM `cdr201212` where customerid=132060 and countryid=1131 and startdate >=

'2012-12-02'

8.3.3 Extracting the cause count of a specific carrier and destination

This is use to check the disconnect codes the carrier is giving us.

select cause, (count(cause)) from cdr200902 where startdate>='20090204' and

countryId=250 and carrierName like '%rudra%' group by cause

8.3.4 Extracting the called number count for specific destination

This is use to check if we are receiving too many repeated numbers from customers and

tell us how many attempts per numbers

select callednum, (count(callednum))

FROM `cdr201208` where countryid=775 and startdate >= '2012-08-27 group by

callednum

29 | P a g e

9 ASR Report File

9.1 WS C&C ASR from Summary Table

This report is to show the traffic volume and the statistics of each customers traffic sent to each

carriers on their routing which can be use also for monitoring and troubleshooting as well.

It contains the summary of the customers traffic on a given carrier for a specific period of time.

The time is usually for a single cycle day or complete 24 hours (as above from: 9/18/2013 8:00

To: 9/19/2013 8:00 GMT+8). This summary table includes the carrier and customer names, the

customer ID, the country ID (appears to be ID as above), the country name in its specific

breakout (appears to be Contshort_name as above).

E.g. Myanmar Mobile, sold to customer International Access (Standard) using the carrier

508comms.

ID. The said country breakouts ID is 681 which can be found on the cost compare sheet (table).

The customer ID in which for this example is International Access Standard is 121888, which can

be found on EBS.

E.g. 508comms sold to us Myanmar Mobile and we sold it to International Access.

R(S>0).The one highlighted in yellow (R(S>0)) shows the numerical value in decimal point of the

Answer Seizure Ratio (ASR). This is the percentage of calls which are connected and have

durations greater than zero.

ASR= Connected Call/ Call attempts

E.g. International Access traffic to Myanmar Mob has 0.33 ASR or 33%, which means that out of

100 calls, 33 calls were connected.

Illustration:

Call attempts = (>=0)

Connected Call = (S>0)

Answer Seizure Ratio (ASR) = (R(S>0))

Customer: International Access

Carrier: 508comms

Destination: Myanmar Mob

Call Attempts: 3531

30 | P a g e

Connected Call: 1162

ASR= Connected Call/ Call attempts

ASR=1162/3531

ASR= 0.33 or 33%

33% is the ASR achieved by International Access while sending Myanmar Mobile traffic to our Carrier 508comms

(R(S>30).The one highlighted in red (R(S>30)), is the computation of ASR with call which got

connected but with more than 30 seconds duration.

ASR (s>30) = Connected call(s>30)/Call attempts

E.g.

Customer: International Access

Carrier: 508comms

Destination: Myanmar Mob

Call Attempts: 3531

Connected Call(s>30): 671

ASR (s>30) =Connected call(s>30)/Call attempts

ASR (s>30) =671/3531

ASR (s>30) =0.19 or 19%

Total time. The next column is the Total time. It is the total time the specific customer consumed

or used a specific route in a particular destination in minutes.

ACD. Included in this table is ACD (the one highlighted in green) or the Average Call Duration is

the average length of phone calls.

ACD = Total time/Connected calls(S>0)

E.g.

Customer: International Access

Carrier: 508comms

Destination: Myanmar Mob

Total time: 3091.45

Connected calls(S>0): 1162

31 | P a g e

ACD = 3091.45/1162 = 2.66 minutes

Therefore, International Access has consumed 3091 minutes which will be then paid depending

on the amount or price offered to them regarding this destination.

9.2 WS Carrier ASR from Summary Table

This table has the same concept as that of Wholesale carrier and customer summary table

however this only includes the summary of carriers on each country breakout.

It shows the total amount of traffic that we send to each carrier for each country breakout.

E.g.

Myanmar Mobile via 508comms. In that particular day, we have attempted to send 9574 calls

which we have received from different customers. And the ASR for this specific sample is 21% as

shown above as 1966 calls got connected out of 9574 attempts. This ASR is the general or

collective ASR from different customers that have sent traffic to our Myanmar Mobile via

508comms.

The ASR where connected calls are more than 30 seconds of duration, highlighted in red, is

R(S>30)=10%, which is the quotient of calls connected with more than 30 seconds divided by the

total attempts.

The same concept goes for ACD, in this table, we will see the total collective ACD for each

customers that have sent traffic to our carrier for specific destination. E.g. Myanmar Mobile via

508comms, the ACD appeared above is the average ACD from all customers ACD.

The total time is the summary of all the total time in minutes from all the customers who have sent

traffic for a specific destination using a specific carrier.

9.3 WS Customer ASR from Summary Table

This table is same as the wholesale carrier summary however this time, the summary shows that

of the customer traffic statistics summary regardless what carrier has been used. This is mainly

used to easily have a look on what a specific customer statistics achieved on a period of time on

a given destination whatever carrier has been used.

E.g.

32 | P a g e

Above, is the overall traffic statistic of International Access Standard on Myanmar Mobile.

Illustration:

Call attempts=8095

Connected calls=2671

Connected calls with S>30=1679

Total Time=7050.02

Using the same formula to get the parameters needed:

Approximately,

ASR(s>0) = 30%

ASR(s>30) = 19%

ACD=2.64 minutes

9.4 Hourly Statistics

To analyze the traffic statistics more, the ASR file also shows the hourly statistics of a customers

traffic. The statistics that will appear will depend on the parameters that are set by us which are;

1. Date = input the date in DD/MM/YYYY format 2. Carrier = input the carrier name or can be set as ALL if all we want to show the statistics for

all carriers used. E.g. Carrier = ALL

33 | P a g e

E.g. Carrier = 508comms

3. Customer ID = input the customer ID or can be set as 0 if we want to show the statistics for all customers for a specific carrier.

34 | P a g e

4. Country ID = input the country ID for the destination you want to view. You can set the collective statistics of different country ID just put comma (,) then space in a group of country ID that you want to view and it will show the combined hourly statistic for all breakouts included.

E.g.

Bangladesh Mobiles, we have 7 different breakouts for mobiles and if we want to see the total

statistics for those breakouts (or some of those breakouts) we need to input its country ID as

follows

622 BANGLAD_MOB

1659 BANGLAD_CITYCELL_MOB

1079 BANGLAD_TELETALKMOB

1651 BANGLAD_WARID_MOB

761 BANGLAD_GRAMEENMOB

1081 BANGLAD_AKTELMOB

1082 BANGLAD_SHEBATELECOMMOB

Country ID = 622, 1659, 1079, 1651, 761, 1081, 1082 (or whatever breakouts summary we

want to see)

35 | P a g e

After completing the parameters we need to input, we will just click the COMMAND BUTTON1,

then it will show the hourly statistic of the traffic that we want to see. Every hour statistics for ASR

and ACD appear which corresponds to the number of call attempts hourly.

In this table we have two types of call attempts, the 1st call attempt is the one that excludes the

overflow, and the 2nd

call attempt is the one that includes it. Overflow, is part of the total calls that

the customer attempts to send us but our switch ports (or our suppliers ports) during a period of

time especially at peak time, are full and cannot accommodate calls anymore.

Thus, we have to types of ASR in this table, the 1st one with overflow and the other without the

overflow. This helps us more to analyze the amount of calls we receive each hour for a specific

customer and its statistics (ASR and ACD).

9.5 Hourly Statistics Overflow

In this table, we will see the amount of calls our suppliers are rejecting and likewise the

customers traffic that are being rejected hourly based on how you set the parameters. The

parameters needed to be filled in this table are the same with the parameters on hourly statistics.

36 | P a g e

After setting the parameters we will click the COMMAND BUTTON1 and the table will show the

amount of calls we receive from customers and how much of calls our supplier is accepting and

how much they are rejecting. In this table it shows the numerical amount of calls rejected and in

its percentage value (usually there are a lot calls rejected during peak time).

9.6 Sheet 8 (Carrier Overflow Report)

This table shows the carriers overall overflow report for each destination combined for all

customers traffic. E.g. below, we will see the amount of calls 508comms rejected for all of our

customers who is routed to 508comms on Myanmar Mobile. And 508comms for this particular

sample rejected 2458 calls.

9.7 Sheet 9 (Customer Overflow Report)

This table shows the general customer overflow reports. It is the total amount of calls from our

customer which we have rejected for the whole day. E.g. below we will see the amount of

overflow call, for all of the carriers used, in Myanmar Mob for International Access standard. A

total of 2170 calls were rejected for the whole day.

37 | P a g e

10 Web-based WS System

From the start of this year, our Web team has designed and a Web based portal for better

accessing and logging Wholesale works. Instead of opening and filling in multiple spreadsheets, it

can all be located and done in one site. The portal can be accessed in address 192.168.8.253

For new User, one must create an Account using Create Log-in, and will be prompted for a new

username and password. Once finished, you can log in to the portal.

Once in, you may find the above menus; to navigate, simply click one of the items:

Home will take you to the Asia Telecom Website and company profile page

(www.asiatel.com.hk)

10.1 Hourly ASR Alert

This will show all the WS ASR Hourly Alerts Page. In here contain the destinations which need

critical monitoring, by setting ASR and ACD threshold with a number of calls. An email alert will

be sent to NOC once the stats are below the given threshold in that particular hour. NOC

member can check that route if there is a problem and act as necessary.

38 | P a g e

To add up a new alert, click on the New Alert button. User may need to complete the desired

parameters.

Status choose Active for new alert. Choose Inactive if you want to disable the alert

Carrier input the Carrier name you want to monitor.

Customer ID input the Customer ID of the Partner. You may find the Customer ID on EBS. 16

Short Name a drop down menu is displayed with Name of destination or breakout you want to

monitor. Short Name is based from the daily ASR report (ex. Malaysia Cellcom mobile is

MALAYSIA_CELLMOB short name)

Country ID a number corresponds to a destination or country breakout. Is based on daily ASR

report (MALAYSIA_CELLMOB is country ID 773)

ASR Level % put in the desired ASR threshold, should be in decimal number (20% ASR = .20).

ASR alert should be realistic, but then should depend on the traffic source. Retail or WS traffic

should be considered. WS traffic usually we put lower ASR alert (~ 20%). Premium traffic should

have higher ASR provided it is not CC traffic (above 20%). Once we get clear picture of the traffic

(we get from the ASR report) we can adjust the parameters accordingly, or upon request of AM.

ACD Level put in the desired ACD threshold in minutes (ex. 2.50 minutes ACD) should be

realistic, but also depend on traffic source. We can adjust accordingly once we study traffic

profile.

Call Sample Size enter the minimum number of call samples, per hour, for ASR and ACD alert

computation. Normally we put 100 call samples per hour. If there is little traffic, we can lower to

50 samples per hour.

39 | P a g e

Consec error before alert put in number of consecutive errors before sending an email alert.

Number may vary depending on traffic profile. Normally we put 3 consecutive errors before

sending an email alert.

Description put in a short description for the alert for reference (New carrier, or Retail traffic etc)

10.2 Blocked Codes List

This menu we keep records of all the codes blocked in SS due to codes unsupported by carrier,

codes have higher rate/cost, special services codes, or code mismatches. Rates Team sends us

the codes which are to be blocked. Codes can be unblocked also in the future so we keep

records on this database to easily keep on track.

To add new blocked Codes click on New Blocked Codes button, than fill in the parameters.

Status choose either Blocked or Unblocked

Date Blocked enter the date of effect of the blocked codes.

Carrier - a drop down menu where in to put the carrier affected.

Destination drop down menu where in to choose the Destination/Country affected.

40 | P a g e

Code indicate all the codes affected

Action Taken indicate Blocked or Unblocked on Dial Peers or in Pre-routing translation on SS

Reason indicate the reason the codes are blocked (code mismatched etc.)

10.3 TT Alert

This is where we keep record all the Outgoing trouble tickets to carrier partners. We keep on

track the tickets which still not resolved. To create new trouble ticket, click on New TT Alert

button, then fill up the following fields:

Status choose either Open or Close trouble ticket

Type choose either Retail TT or Wholesale TT

Date enter date when ticket is first opened

Destination enter the destination of breakout which is affected

Problem Carrier indicate the Carrier which is having issues

Carrier Email indicate the email address of the carrier for sending auto alert

Description put in the body of the message

Action taken indicate what action was taken (ex, blocked on SS or any particular customer)

Remarks indicate: received time and time replied for retest

41 | P a g e

For the new trouble ticket alerts, follow-up emails are sent after 48 hours of no reply. If Carrier

has no reply for two consecutive follow-ups, it will automatically refer to the Account Managers,

whether to test once more or drop the route.

For existing trouble tickets with carriers reply for retest, we are only allowed to retest the route

two more times at most, from the first time ticket was set. If still failed after two retests, the ticket

is referred to the Accounts Manager whether to give one more chance, or to drop the route

permanently. Will then closed the trouble ticket as cannot fix.

10.4 WS Swap

In this tab, you can see all the active swap with our customers and vendors. You can refer to this

to know which routes or traffic should be monitored on higher priority.

42 | P a g e

11 MVTS-Pro Configurations

11.1 Carrier Interconnection

For Inter-connection with WS partner (as Customer or Carrier), we configure as a static route, point-to-point connection between MVTS-Pro and Switch of Carrier partner. MVTS-Pro use Equipment as Virtual GW for building up inter-connection with Carrier partner.

11.2 Incoming and Outgoing GW

In Equipment, Incoming and Outgoing GW is created as Virtual GW that include GW IP, Protocol, and Codec etc. of WS partner for building up inter-connection,

When we create Incoming and Outgoing GW, please always check these 5 fields for verifying setting of Incoming and Outgoing GW correct,

1. Allow origination and Allow termination define as Incoming GW or Outgoing GW

even we can enable both, we never set this for better Port restriction and Billing purpose

2. Orig. IP address list and Term. IP address point to the correct IP or Subnet of WS

partner

3. Protocol select the correct protocol (i.e. H.323 or SIP) which agree with WS partner

4. Orig. groups use in Incoming GW only, define a name for connecting Incoming GW and DPs which are created for the GW (i.e. the customer)

5. Orig. DST number translation use in Incoming GW only, define Tech prefix which agree with WS partner

generally we define Tech prefix as Customer ID (i.e. ATL no.) and negotiate with the customer

format: (Customer ID)([0-9]*)/\2, e.g. (131939)([0-9]*)/\2 for Quantum traffic

If we observe unsatisfied traffic performance globally (i.e. Low ASR, ACD on different destinations even using White route), you may adjust these 3 fields for improving traffic performance, 6. Orig. codec group and Term. codec group define acceptable Codec for Incoming or

Outgoing traffic

currently, Codec group 1 and 13 (by default) include ALL available Codec with/without VAD (Voice Auto Detection) respectively

we may select other group to narrow down available Codec e.g. use Codec group 6 to filter out g.711 Codec (some carrier may not connect well with g.711 Codec)

but if we narrow down available Codec, we should notice that Incoming traffic with unacceptable will be rejected

7. Orig. start H.245 after and Term. start H.245 after define the stage to establish H.245 tunnelling

Test calls or Live traffic possible cannot connect with Disconnect code TS-8 [H.323] Procedure failure, it possible represents the carrier require Connect stage, not Alerting/Progres stage

43 | P a g e

8. Orig. proxy mode and Term. proxy mode define Proxy mode/Non-proxy mode for Incoming or Outgoing traffic Proxy mode (by default) represent Signaling message and Media stream both pass

through SS Non-proxy mode represent only Signaling message pass through SS, Media

stream establish between Customer and Carrier directly

By the way, Non-proxy mode provide better traffic performance in special case only, we still have no evidence how it work up to now

For point 6, 7, 8, please always consult with senior NOC before we adjust, for avoiding traffic performance turning worse.

11.3 Standard and Premium offer for WS partner

For providing route offer for WS partner, we possible provide 2 route offers, Standard Lower rate, Wholesale, non-CLI, Grey Routes Premium Higher rate, Retail, CLI, White Routes

However, if we assign the same IP to 2 different Incoming GWs, we will confuse configuration of SS, finally SS will disable both GWs and reject Incoming traffic from the IP without a trace

When we require to configure the above situation, please always check this field for guiding SS how to recognize Incoming traffic from the IP,

1. Orig. allowed DST prefixes and Orig. disallowed DST prefixes define Tech prefix which is accepted and rejected by Incoming GW, so SS able to classify Incoming traffic and point to proper Incoming GW

You may check Incoming GW of Sunpage traffic as an example for those configurations.

11.4 IP change of Incoming and Outgoing GW WS partner occasionally request to change IP for maintenance or moving location, we require to verify their message and test the new IP before we confirm to change IP

44 | P a g e

11.4.1 IP change of Incoming GW We require to verify their message for Security issue (to avoid receiving Incoming traffic from unknown IP) once we receive their request 1. confirm the message with Account manager of WS partner, by our e-mail alias, or, 2. request a copy with Company stamp, this is an example from Luxor,

3. Once we confirm OK on point 1 or 2, we can process IP change of Incoming GW

11.4.2 IP change of Outgoing GW

1. We require to verify their message for Security issue also 2. Meanwhile, we require to configure 1 more Outgoing GW and Test pin pointing to the new IP 3. Based on Live traffic, we select at least 2 destinations, test and compare Test result on the

new IP and existing IP 4. If Test result is difference, please co-operate with NOC of WS partner until Test result is

acceptable

45 | P a g e

You may check Outgoing GW and Test pin of carrier Quantum as an example for those

configurations.

11.5 Routing Update

For Route offer to WS partner, we configure a set of Dialpeers (DPs) in sequence per destination that point to proper Outgoing GW for terminating Incoming traffic. SS use Dial peers as Virtual route to re-direct Incoming traffic to proper Outgoing GW (i.e.

Carrier).

11.5.1 Individual DP

Routing order is Customer-basic currently, we setup Individual routing order (i.e. DPs for different countries) for each customer When we create a Individual DP for providing a Route offer per destination, please always check these 4 fields for verifying Setting of DP correct, 1. Allowed SRC groups point to a name of Orig. groups which belong to the customer

to connect Incoming GW and DPs, for Incoming traffic to lookup proper DPs for the customer

2. Equipment list and DST number translation point to proper Outgoing GW with Carrier prefix which belong to the carrier

3. Precedence assign a suitable value to arrange a set of DPs pointing to the same destination in a correct sequence

This is an example on route to Mexico mob for TVI traffic, carrier Luxor -> Speedflow ->

SmartComTech -> Alrus

46 | P a g e

11.5.2 Share DP

Share DP is similar to Individual DP, but it support Incoming traffic from multiple customers. This is good for central control and for reducing Routing complexity. Carrier sometimes offers a lower-cost route that support full or part of breakouts of a destination (for example, carrier Sill-V offers a route that support Breakout 632432, Breakout 632432 is part of breakouts of Philippines Manila fix). Since Carrier cost is attractive, we can offer to ALL or most of customers in advance of other carriers, without concerning Carrier cost. Share DP, therefore, is created as Virtual route for Incoming traffic from multiple customers.

There are 2 formats for setting up a Share DP,

a. Allowed SRC groups => blank, Disallowed SRC groups => customers who are rejected by Share DP (i.e. not open for them)

for this format, Share DP open for ALL customers by default, do not open for Carrier (for avoiding Loop back issue) and customers who Account managers ask for (because of Quality issue)

however, this format is not recommended because we possible open a route (or a destination) for ALL customers in accident

this format is used on route to Philippines fix only (passing through carrier Sill-V, Bulink, ECC), this is because Carrier cost is very low and Route offer is stable, we possible open for ALL customers always (expect customers who request White route or High quality)

This is an example of Share DP with setting of point a

b. Allowed SRC groups => customers who are accepted by Share DP (i.e. open for them), Disallowed SRC groups => blank

for this format, Share DP open for customers 1-by-1 according to Account managers advice

this format is recommended because we never open a route (or a destination) out of Account managers expectation, on the other hand, we still can manage a route based on Carriers request, e.g. Route down Disable, Capacity change, GW change.. etc. (please always co-operate with Account managers for including customers on Share DP)

this format is used on route to Uzbekistan mob (passing through Speedflow), Philippines mob (passing through Sill-V), or others in coming future

47 | P a g e

This is an example of Share DP with setting of point b

When we create a Share DP, please always check these 5 fields for verifying Setting of DP correct,

1. Allowed SRC groups and Disallowed SRC groups configure in format a. or b.

2. Equipment list and DST number translation point to proper Outgoing GW with Carrier prefix which belong to the carrier

3. Precedence assign a value that is high enough, to place in advance of other carriers (i.e. Individual DPs, as Overflow carriers) - We suggest Precedence>3000 for route to mob, Precedence>1500

-1800 for route to fix on Share DP because we usually assign Precedence=>1500-1800 for route to mob, Precedence=>800-1000 for route to fix on Individual DP,

4. Name please always write DP name as DP_xxxxxx_share so NOC can search Share DP by keyword share

Refer to the previous discussion, Carrier sometimes offers a route that support full or part of breakouts of a destination, we can define,

Full of breakouts follow Breakouts list from our Billing Part of breakouts follow Breakouts list from Carriers advice (i.e. Breakout list

from their Billing)

Please always confirm Breakout list with Account managers or even NOC of Carrier, you may

check the following folders for finding the existing Breakout list,

\\File-server\share\Tech folder\carrier route detail

\\File-server\share\Tech folder\sill-v routes detail

\\192.168.78.12\share\wholesales\Codes

48 | P a g e

This is an example of Share DP that follow Breakout list from Carriers advice

11.5.3 Block DP

Block DP, as Blocker or Terminator, is used to stop Incoming traffic looking up route (i.e. DP) after a defined Precedence

Once SS receive Incoming traffic, it first filter a set of DP based on Orig. groups, it then filter a set of DPs according to Destination no., and finally, it look up each of the rest according to sequence of Precedence

However, Account managers may request to remove Overflow carrier on sub-breakouts due to Rate issue (e.g. Offer rate is lower than Carrier cost of Overflow carrier)

For example on route to to Philippines fix, generally Incoming traffic passes through Share DP (via Sill-V, Bulink, ECC) first, and passes through Individual DP (via Asia NetCom, Phonetime, as Overflow carrier) then. Individual DP open whole Breakouts list of route to Phil. fix, not part Breakouts list (i.e. Sub-breakouts).

Therefore, we can create Block DP pointing to Sub-breakouts between Share DP and Individual DP, for blocking Incoming traffic to pass through Individual DP (i.e. Overflow carrier)

When we create Block DP, please always check these 5 fields for verifying Setting of DP correct,

1. Allowed SRC groups point to a name of Orig. groups which belong to the

customer 2. Equipment list point to proper Outgoing GW (i.e. NULL_GW),

Equipment list field can not be blank, so we create Outgoing GW NULL_GW for terminating Incoming traffic with proper Overflow signal cc. 34

For Test result that return Overflow signal cc. 34 for Incoming traffic, you may refer to the description of Outgoing GW NULL_GW

3. Precedence assign a suitable value that Block DP place between Share DP and

Individual DP (i.e. Overflow carrier) which should not pass through

49 | P a g e

4. Stop route hunting after this DP enable this option to stop Incoming traffic looking up the rest of available DPs based on Precedence

5. Name please always write DP name as BLOCK_NULLGW_xx_xx so NOC can search Block DP by keyword BLOCK or NULLGW

This is an example of Block DP which block iBasis traffic to pass through Overflow

carrier on route to Philippines Visayas (Globe) fix

11.5.4 New breakouts (codes) adding on Existing or New route (DP)

Close carriers (e.g. Sill-V, Numedia.. etc.) sometimes offer us New breakout (e.g. Breakout 62821) which is available on Existing route (e.g. Indonesia Telkomsel mob) or New route, by e-mail. You may take the following steps as reference, 1. check (or confirm) Terminating GW IP and Carrier prefix with NOC of the carrier 2. check Outgoing GW and Test pin and lookup the match one according to Terminating GW IP

and Carrier prefix, for testing New breakouts if it is working properly 3. if Test is Fail, please follow up with NOC of the carrier 4. if Test is OK, please cross-check on SS and our billing record,

a. On SS, if we create Existing route (i.e. DP) already, please add New breakout in the related DPs,

If we have not created a route yet, please create New route (i.e. DP) and check

with Account managers who customers we open for,

b. On our billing record, if we find New breakout grouping into the correct destination (or Country ID), please remain it unchanged,

If we dont find new breakout, please forward to Rate team for Code update in

necessary

50 | P a g e

11.5.5 General (or Global) Block list

We possible stop to receive Incoming traffic on some breakouts, no matter from ANY customer

(due to Rate issue or Invalid breakouts.. etc)

SS use Pre-routing translations as Firewall to stop receiving Incoming traffic on specified

breakouts from ALL customers

When we create General Block list, please always check these 3 fields for verifying Setting of

General Block list correct,

1. Allowed DST numbers pattern specify a list of breakouts that we reject on Incoming traffic

2. Disallowed SRC groups point to Orig. groups as VIP for avoiding Test calls to be blocked

3. Action and Quit with disconnect code configure as Stop and H.323, 34 - No

circuit/channel available respectively, to reject Incoming traffic with Overflow signal cc. 34 for customers

This is an example of General Block list on route to Sri Lanka mob from ALL customers

Please always co-operate with Account managers and provide evidence to prove that is Invalid

breakouts if we plan to create General Block list.

11.5.6 DST Allow Patterns and Code Mismatch

Please note that MVTS is checking first the DST-prefix patterns before it checks the precedence

in finding where the traffic should go first.

51 | P a g e

1. It is checking first the DST allow patterns. The longer the codes, the higher the priority. E.g. we

have two DP for Vietnam Mobile, the 1st DP has DST allow pattern of 841.* and the 2nd DP has

DST allow pattern 84121.*. The call will go first on the 2nd DP even if the 1st DP has higher

precedence than the 2nd DP.

2. If the DST allow pattern on all DP are the same, MVTS will then check the precedence to find

where the traffic should go first.

Therefore, all routing should have the same DST prefix allow patterns on each destination so that

the routing sequence will be based on precedence only.

For code mismatch, we should always block the unsupported codes instead of opening the

supported codes to keep the DST Allow Patterns uniform on all DPs for each destination.

52 | P a g e

12 Troubleshooting Guides

12.1 What to do and How to Respond

1. You should always extract the CDRs of their given sample numbers to understand why the calls did not complete. (Request CDR from them if not given)

2. If you found an issue on the carrier, you need to block the faulty carrier and raised TT to them. If no other carrier on the routing, try to replace it with a working one which is within the rate offer. Then inform customer as follows:

We thank you for bringing this into our attention. We observed a temporary issue and now it is resolved. (you can add real time stats or test calls to show that the route is working fine)

If no carrier for replacement, we should tell customer as follows:

We thank you for bringing this into our attention. We have duplicated this problem and we already raised the issue with our carrier partner. We will get back to you at the earliest.

3. If you didnt found an issue on the carrier, you need to check for other possible reason why their calls failed:

a. Congestion issue if their sample numbers fell under peak hours period and all carriers are full already during that time. Try to add working carrier if possible or ask our vendors if they can add more capacity.

If we have added more capacity already you should inform customer as follows:

We thank you for bringing this into our attention. We have experienced temporary congestion and now we have added more capacity for your traffic.

If we cant add capacity at the moment we should inform them as follows:

We thank you for bringing this into our attention. The route is very popular and may experience congestion especially during peak hours. We are returning other calls with proper overflow signal for you to enable to route advance to your next available carrier. We will inform you once we have more capacity already for your traffic

b Routing issue if you found error on routing, prefix, port restriction, etc, correct it and respond to customer as follows:

We thank you for bringing this into our attention. We observed a routing error only and we have corrected it already.

4. If you didnt found an issue on the carrier and no other issue found, you should invite them

for live testing and respond as follows:

We thank you for bringing this into our attention. We have checked the route and didnt duplicate the issue. May we request you to retest and you may ping us on msn for live testing if you still encounter the issue.

Notes:

1. Spend more time on high potential customers which has volumes and try to get to the bottom of their problems and see if these can be resolved then we can expect stable volumes

2. We need to address the main issue and understand why they are raising it instead of just telling them our test calls are fine. (remember our tests would be at a different time

53 | P a g e

than when they faced the problem so more reason to understand the problem)

3. Give them supporting details which shows our routes are working well.

Most important to remember

1. think clearly, read the email correctly to understand the exact problem raised by carrier and use simple but sound logic when doing trouble shooting

2. For problems we raise to carriers, be very clear in your TT so carrier easily understands the problem and try and follow up after a short via MSN or phone especially for those routes which we send good volume of traffic to as well as those where we do not have sufficient backup routes

12.1.1 Disclosing of Information to Partners

There have been instances wherein carriers reveal us their condition about their termination

carriers. These maybe unreliable and does not describe whole picture of the route. Most of this

information are discussed internally only, and suggested not to be shared such information to our

ingress partner/ customer. This sensitive information mentioned such as Carrier Name, IP

Addresses, NOC or Accounts Manager Names, Contact numbers, etc. should be taken for

internal references only.

If Customer is asking for update we can reply to them as general as possible

1. If the issue is between our carrier and their supplier only, we will just inform our customer

that we have temp capacity issue only, etc.

2. If the issue is general, e.g. all routes including CLI routes as well are down due to cable

cut, bad weather, political, etc. then we can tell to our customers those information.

12.2 Factors that Affects the Call Quality

12.2.1 Media Packets

Regarding to Media packets missing on live traffic, there are two possible directions (main

reasons) causing the issue.

a. Codec negotiation issue

b. Firewall issue

12.2.2 Codec Negotiation

If live traffic send us with a kind of Codec that we do not support, live traffic is possible connect

but do not negotiate a proper Codec on SS. CDRs will show Media packets missing (the incoming

and outgoing codec legs are incomplete)

E.g. WS customer AsiaTel showing "blank", AsiaTel Carrier showing "g.729"),

To avoid the issue, we choose Codec group 1 that included most of available Codec (i.e.

we accept Live traffic with any Codec)

54 | P a g e

If in case live traffic cannot connect well with a kind of Codec, we can choose other Codec group

which narrow down kind of available Codec,

"Always discard non-matching codecs" option (on Incoming GW) should be enabled in order to

reject Live traffic using un-supported Codec with returning Busy tone cc. 34 (i.e. Overflow signal),

E.g. Incoming GW of Joint Power traffic as an example (for Joint test, they connect well using

g.729 only, point to Codec group 14 and reject the rest)

12.2.3 Codec Incompatibility

There are some situations which one may encounter tickets from customers pushing us to

improve the route Statistics (ASR and/ or ACD). There are many approaches in order to check

and improve at our end, but will share some basic understanding regarding codec compatibility,

and how it helps to improve stats.

One should check on the CDRs, and identify if there are some codec incompatibility, between

Incoming traffic and SS equipment, or between Incoming traffic and carrier partner. Take last

hour stats, or last 1000 samples of the traffic. Or if they are complaining for past records, we may

use Last 24 hours CDR or the latest ASR report. Commonly, we can see in the CDRs that there

may be calls which failed due to Incompatible Codecs.

If there is still traffic going in, we may need to acquire sample trace or log file of the failed calls.

We can obtain log by going to Equipment-> Customer Incoming Equipment-> then put a check

mark on Origination Logging. We can run the logging for a short period of time only, or until we

capture 3-5 failed samples. We can check if we had captured calls already by going to

Debugging-> Debug calls. Never forget to turn the logging off, to avoid wasting of valuable

resources. Once we have acquired the debug calls we can investigate further as to which codecs

they are sending, and if our switch are able to match with the settings we put to them initially

(during the interconnection process).

From the debug log, we can observe the codecs they are sending by looking on the INVTE, if the

interconnection is SIP. Or in OUT CallBegin, if interconnection is H323. Below is sample of SIP

Log. From the log below, we can see the codecs in the rtpmap and fmtp parameters. Payload

type (red font) will indicate with rtpmap and fmtp are together.

v=0

o=- 1364827029 1364827029 IN IP4 218.189.19.2

s=-

c=IN IP4 218.189.19.2

t=0 0

m=audio 24544 RTP/AVP 18 96 97 98 101 4 99

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=yes

a=rtpmap:96 G729/8000

a=fmtp:96 annexb=yes

a=rtpmap:97 G729/8000

a=fmtp:97 annexb=no

a=rtpmap:98 G729/8000

a=fmtp:98 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:4 G723/8000

a=fmtp:4 annexa=yes

a=rtpmap:99 G723/8000

a=fmtp:99 annexa=no

55 | P a g e

a=sendrecv

Below is sample Log from H323. The codecs can be found on fmt and vad parameters, under srcMedia };

srcVendor "TS-v4.5.0-08ae";

srcMedia {

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "18";

fmt_ "g729";

vad_ "enable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "96";

fmt_ "g729";

vad_ "enable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "97";

fmt_ "g729";

vad_ "disable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "98";

fmt_ "g729";

vad_ "disable";

rate_ "8000";

frames_per_packet_ "0";

56 | P a g e

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "101";

fmt_ "rfc2833";

vad_ "not applicable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "4";

fmt_ "g723";

vad_ "enable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

{

-Type- "mvoip::Codec";

mediaFormat {

-Type- "mvoip::VoipMediaFormat";

payload_type_ "99";

fmt_ "g723";

vad_ "disable";

rate_ "8000";

frames_per_packet_ "0";

flags_ "0";

techFlags_ "0";

};

parameters {};

};

We only need at least one incoming codec to be matched with equipment or carrier codec

settings.

If none of the codecs list were set in Customer Incoming Equipment, then the result is No

Compatible codecs in the CDR. As a solution, the Incoming Equipment codec group is set to

Codec Group1 as default. If there is still not compatible codecs occur on calls, then we can

choose Codec Group13 (Codec Group 1 with and without VAD)

There are also special cases in which the terminating carrier has limited codec support (ex carrier

support G729 only for the particular destination). In this case our switch can support codec

57 | P a g e

transcoding, just make sure we open the supported codecs on customer traffic towards our

switch, then opening the supported codecs from our switch towards termination carrier. MVTS

can do convert the traffic to the supported codecs allowed by the carrier end. There will be some

implications, or quality may change due to the conversion process itself, but this is better option

than calls will fail due to incompatible codecs. We can take the case related to this item as below:

E.g. Worldhub traffic to BTglobal I checked your test DP via BTglobal and I noticed you are trying to use

the codecs which Worldhub is currently sending.

First, the concept of matching customers codec is advisable only on

Origination GW not termination GW because vendor may not support all

codec which our customer is sending to us. If customer is sending codec

other than our vendor can support, MVTS is doing codec transcoding or

codec conversion to be able to pass customer's traffic to vendor side.

On your test below, BTS is not supporting G729AB,G.729_vad and

G.729A_vad that's why calls encountered "no compatible codec"

issue. This is not related to Worldhub traffic as we are the one

forcing to send those codec to them.

I study your debug sample as well and I found on their INVITE, the

useful informations below when matching customer's their codec.

Highlighted in blue are the rtpmap, fmtp are in green and the payload

types are in red. The payload type can also be your indication on which

rtpmap and fmtp are together. then you can set it on "codec group

setup" table.

INVITE - from debug call log of Worldhub incoming

v=0

o=- 1364827029 1364827029 IN IP4 218.189.19.2

s=-

c=IN IP4 218.189.19.2

t=0 0

m=audio 24544 RTP/AVP 18 96 97 98 101 4 99

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=yes

a=rtpmap:96 G729/8000

a=fmtp:96 annexb=yes

a=rtpmap:97 G729/8000

a=fmtp:97 annexb=no

a=rtpmap:98 G729/8000

a=fmtp:98 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:4 G723/8000

a=fmtp:4 annexa=yes

a=rtpmap:99 G723/8000

a=fmtp:99 annexa=no

a=sendrecv

Current codec setting for Worldhub P is already match to us otherwise,

their traffic will get "No compatible codec" issue.

58 | P a g e

But at this point, we cannot match worldhub codec with btglobal codec

due to carrier limitation.

Codec transcoding is helping on matching codec but quality may reduced

depending on how many times the codec was converted. The more the codec

transcoding, the lower the quality will be. That's the reason why other

customers are just passing their customer's traffic without changing

the codec but the drawback of this is, it is more prone to codec

compatibility issue. As a result, doing codec transcoding is still

better.

12.2.4 Codec Matching

You may go through the following steps. 1. Enable the origination logging to find the exact codec they are using (because each codec may have different settings) 2. Under 'INVITE' section, you will see for e.g. G729a on their call.

v=0 o=SYN-UK-SBC-1-1 10518101 10518101 IN IP4 188.244.114.23 s=sip call c=IN IP4 188.244.115.12 t=0 0 m=audio 18068 RTP/AVP 18 101 a=rtpmap:18 G729a/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20

3. To get more detail about their codec, you can check it under 'mvoip::CallBegin' section and check the srcMedia part, you can also see that vad is disabled which is not shown on the INVITE.

srcMedia { { -Type- "mvoip::Codec"; mediaFormat { -Type- "mvoip::VoipMediaFormat"; payload_type_ "18"; fmt_ "g729"; vad_ "disable"; rate_ "8000"; frames_per_packet_ "0"; flags_ "0"; techFlags_ "4"; }; parameters { { -Type- "mvoip::CodecParam"; type "cptReadSdpRtpmap"; value "G729a";

4. Now you can add that codec on the codec group list. You can clone default g729 codec (vad disabled) and just add their codec (G729a) on the rtpmap as follows.

59 | P a g e

Note: You will notice also that we have G.729A already on the list but their call is still fail failing. It is because their rtpmap is G729a and not G.729A. rtpmap should be perfectly match with their's.

5. Now their g729 call should connect successfully now.

12.2.5 Multiple Codec Transcoding

I we use codec group 1, it will minimize the codec transcoding as we will just pass customer

traffic to supplier without converting it to specific codec only. This is applicable only if supplier

support all the codecs and customer is sending diff codecs which probably means they are not

doing codec transcoding also. When the call do multiple transcoding, the ACD will drop

considerably and it will affect the call quality because a lot of clipping will be done on it. Below are

example experiment.

customer G729 to carrier G729 = ACD is 90 secs

customer G729 to carrier G723 = ACD is 30 secs

12.2.6 False Answer Supervision

False Answer Supervision (FAS) occurs when providers terminate calls fraudulently, resulting in the calling party being overcharged for calls, or charged for calls that were never completed.

Types of FAS

FAS can occur in one of three ways: Calls that are not successfully completed but that are billed anyway Deliberate rerouting of calls to an automated messaging platform designed to trick the customer into staying on the line Premature billing during Post Dial Delay (PDD) or ringing time prior to when the call is answere