Network Operations Centre Training Manual

Network Operations Centre Training Manual v201312

Contents 1

2

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

Wholesale Call Traffic Flow ................................................................................................. 6 2.1

3

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

4

5

6

Call Flow in Detail ........................................................................................................ 6 Cost Table Navigation.................................................................................................. 8

3.1.1

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

3.1.2

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

3.1.3

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

Electronic Billing System ....................................................................................................11 4.1

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

4.2

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

4.3

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

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

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

1|Page

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 12.2

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

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

2|Page

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 14

H.323 Disconnect Codes ............................................................................................77 Retail Works ...................................................................................................................84

14.1

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

14.2

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

14.3

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

15

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

3|Page

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.

4|Page

For more information, you may visit our website http://www.asiatel.com.hk/hk/index.html

5|Page

2

Wholesale Call Traffic Flow Supposed we have a call A, who wants to call to point B via VOIP.

Internet A

Customer W

Asia Telecom

Carrier X Carrier Y

Internet B

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.

6|Page

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.

7|Page

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 =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.

23 | 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)

24 | 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, it’s a sign of FAS on the route.

25 | 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 “ebsws1” 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)

26 | P a g e



8.2

”ebs-ws1” Table   

8.3

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

“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

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'

27 | 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

28 | 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 customer’s 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 customer’s 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 breakout’s 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

29 | 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

30 | 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.

31 | 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 customer’s 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

32 | 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.

33 | 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)

34 | 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. st

In this table we have two types of call attempts, the 1 call attempt is the one that excludes the nd overflow, and the 2 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 supplier’s ports) during a period of time especially at peak time, are full and cannot accommodate calls anymore. st

Thus, we have to types of ASR in this table, the 1 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 customer’s 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.

35 | 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 carrier’s overall overflow report for each destination combined for all customer’s 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.

36 | 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.

37 | 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.

38 | 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.

39 | 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

40 | 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.

41 | 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

42 | 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

43 | 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

44 | 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

45 | 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 manager’s advice  this format is recommended because we never open a route (or a destination) out of Account manager’s expectation, on the other hand, we still can manage a route based on Carrier’s 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

46 | 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 Carrier’s 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

47 | P a g e

This is an example of Share DP that follow Breakout list from Carrier’s 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

48 | 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 email. 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 don’t find new breakout, please forward to Rate team for Code update in necessary

49 | 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.

50 | 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.

51 | 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 didn’t 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 hour’s 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 can’t 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.” If you didn’t found an issue on the carrier and no other issue found, you should invite them for live testing and respond as follows:

4. 

“We thank you for bringing this into our attention. We have checked the route and didn’t 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

52 | 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. 2.

think clearly, read the email correctly to understand the exact problem raised by carrier and use simple but sound logic when doing trouble shooting 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)

53 | 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

54 | 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";

55 | 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

56 | 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 information’s 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.

57 | 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.

58 | 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 answered by the calling party (frequently due to a switch misconfiguration — accidental or intentional). The Impact of FAS Across the Value Chain FAS is a fraud perpetrated against consumers, who are billed for minutes they did not use, or calls that were never completed. Consumer complaints about incorrect billing charges impose financial costs on retail carriers, who must allocate customer service resources to resolve billing issues. Additionally, FAS can damage brand perception, as well as lead to lowered customer satisfaction. Meanwhile, carriers must compete against artificially lowered prices on routes from suppliers who are engaging in FAS, who use their fraudulent profits to subsidize below cost-perminute rates.

59 | P a g e

12.2.7 False Ringback Tone False Ring Tone (FRT) occurs when providers terminate calls with artificial ring tones. Signs of FRT are very short PDD and when you hear unusual ring back tones. You can confirm if it is genuine by testing the same number with a premium carrier.

60 | P a g e

12.2.8 SIP 18x before SIP 503 Issue This is related to alerting setting of the carrier (we didn’t set this on our side). If the carrier has fake RBT setting, they will send alerting signal (SIP 180) in advance (before it reached their dialpeer) so if their route (DP) is congested, SIP 503 will be sent to customer after the SIP 180 (Alerting) already. This could be from carrier's supplier and so on, so it’s hard to fix completely. As of now, only Vodacode is complaining about this issue, and seems their switch is not capable or routing this type of calls to their next carrier but most switches can overflow even there's a bit delay as long as they are getting overflow signal. What we can do only for now is to raise the issue to carrier and if carrier cannot fix it then we will try to find another carrier for them. To check if the carrier is giving overflow properly, you can enable the origination logging on Quintum Phil GW to check if you test call will have this issue. Below is a sample good overflow call via H323, after 'CallProceeding', the cc34 was sent immediately after it. If there was 'Alerting' before cc34 then it has problem mentioned above. Same also with SIP calls. Debug Log:

12.2.9 TS, 8 - [H.323] Procedure failure There are some cases when test calls cannot connect due to codec or some parameter incompatibility between switches. In this situation, we encountered calls failing due to our switch is returning with TS, 8 - [H.323] Procedure failure cause code.

From further investigation, we found that our switch SIP OPTIONS parameter is enabled at our end, which our carrier switch cannot fully support. Below is trace log from carrier switch:

61 | P a g e

Format:

[CallIndex][TransactionIndex]

A => 202.67.196.84 B => 61.120.156.228

1 11:21:47.537798[ 0][ 0] 2 11:21:47.538520[ 0][ 0] 3 11:21:52.391001[ 0][ 0] 4 11:22:08.559958[ 0][ 0] 5 11:22:08.610511[ 0][ 4] 6 11:22:08.814733[ 0][ 5] 7 11:22:09.317850[ 0][ 5] 8 11:22:10.317850[ 0][ 5] 9 11:22:12.318046[ 0][ 5] 10 11:22:12.934639[ 0][ 6] 11 11:22:12.935876[ 0][ 6]

A B | | |INVITE 77090821068843644 |-------------->| |100 Trying (INVITE) || |OPTIONS | |-------------->| |OPTIONS | |-------------->| |BYE | |-------------->| | 200 OK (BYE)| |