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 <= 0.0025 + Offer Rate to Customer To easily find suitable carriers for routing, the Cost table is an important tool for it contains all the Carriers available and their respective costs for each destination/ country. We obtain the rates after a successful carrier testing. Rates Team is responsible for inputting the rates, and checking each supported codes and breakouts which the Carrier covers.
3.1
Cost Table Navigation From the concept above, will show how to navigate through and familiarize the function of each sheet. As a NOC Member, you will be provided a copy of latest version of Cost Table, which is an Excel file and the sheets you will going to use are Sheets 1, 2, and 4 only.
3.1.1 Sheet 1 It contains the list of all the Countries A-Z (means from Afghanistan to Zimbabwe). The page is classified into the following Columns: Country – a pull down menu in which you can choose to display a specific country only. ID (Country ID) – this is for billing system reference. Specific breakouts (specific codes) have their own carrier cost and is used by billing system to compute for the correct price for each call. Code (Country code) – displays the country code of each country (ex, Philippines – 63, etc.) Short Code – displays the name of the country or specific breakout (PH Smart Mob, PH Globe Mob, etc.) The Command Button found on top of the sheet is used to keep the File in sync with system with regards to latest Codes and Carrier cost.
8|Page
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.
9|Page
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)
10 | 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.
11 | 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
12 | 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.
13 | 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
14 | 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.
15 | 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
16 | 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
17 | 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
18 | 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.
19 | 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.
20 | 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:
21 | 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
22 | 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.
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) |<--------------| |180 Ringing (INVITE) |<--------------| |200 OK (INVITE)| |<--------------| |ACK | |-------------->| |OPTIONS | |-------------->| |OPTIONS | |-------------->| |OPTIONS | |-------------->| |OPTIONS | |-------------->| |BYE | |-------------->| | 200 OK (BYE)| |<--------------|
Below is the guide on how to tweak such settings in our switch. Below is one case as an example together with defined terms for better understanding: 1. Check on the Termination equipment and the SIP Query gateway parameter is not checked but still our calls are sending OPTIONS to partner by default. SIP Query gateway – select the checkbox to allow MVTS Pro to monitor the serviceability of SIP gateways by periodically sending them the OPTIONS request as long as the gateways are handling calls. The parameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field. 2. Force all the termination GW (NTT outgoing) to disable the OPTIONS permanently. Flags – this parameter allows configuration of the gateway functional peculiarities. The parameter value is a bit mask defined by a hexadecimal number. Possible values include: - 0x4000 - disable dispatch of SIP OPTIONS as TCS to the remote equipment 3. Put 0x4000 under Flags setting and MVTS-Pro is automatically changing it to 0x004000 once you click OK.
62 | P a g e
Then MVTS will not send SIP OPTIONS now to carrier and the Procedure Failure issue will be solved.
12.2.10
Incorrect PDD Value
PDD is the time between SETUP time and SIP 180 ALERTING time while, SCD is the time between SETUP time and CONNECT time. If there is no SIP 180 alerting response on a call, MVTS will count the PDD from SETUP time to CONNECT time, therefore the value will be the same as SCD. By debugging some sample calls with incorrect PDD value, instead of SIP 180, the call has RESPONSE: 183 after 5-10 seconds from INVITE which should be the true PDD of the calls. To solve this problem, we should enabled the parameter that will use SIP 183 instead as the alerting time. Please refer to the latest MVTS-Pro manual for more info
12.2.11
Loopback Call Issue
Loopback refers to as calls or data streams unintentionally being transmitted back to original equipment. This method is primarily used for testing network infrastructure. However, we should avoid or eliminate loopback in normal operation as much as possible. In commercial VoIP service, there have been instances wherein we observe calls looping back either to us, to customer or carrier. The call in loopback will be sent around to the originator in an endless manner until it finds a different route to terminate it. This means one call will occupy two or more resources (ports) in particular equipment until the call is terminated. There is some equipment which can detect and drop the call automatically if it is looped back to them. Most of the time, the call will just go through the carrier which it is routed, regardless if it is originators traffic or not. In case of our equipment, the MVTS Pro does not support loop detection feature yet, but can be included in future versions.
In order to detect loop calls, the NOC member should manually test a carrier, and observe in CDR if the call is looped. Above screenshot is an example of a loop call. Our side engages the call, then pass through the carrier. Then eventually the carrier routed the call back to us, resulted a loop back. The call completes because our side routed the call to another provider. You can observe that the disconnect time are the same and durations are almost the same, with one second difference depending on how many carriers it went through.
63 | P a g e
In this case the termination carrier is alerted and blocked. We cannot use them in routing until they remove us in their routing, or find another provider to complete the call. There is another case wherein customers complain their originating calls are going back to them. In this situation we are unable to detect it by manual testing, but instead requesting the customer to provide sample CDR of the looped calls. NOC member will then check the CDR on our records to which carrier did the call went to. In this case we are to alert the termination carrier to check if they or their onward carrier is routing the call back to the original sender.
12.2.12
Firewall Issue
For Voice traffic, we can roughly separate it into Signal path and Media stream, we possible use Single GW (e.g. SS MVTS-Pro) or Multiple GWs (e.g. Signaling GW + Media GW) to handle it, however, if IP address or Port (i.e. Service) of Media GW is blocked, CDRs of Live traffic show Media packets missing. If IP address or Port of Signaling GW is blocked, we should not receive live traffic that CDRs do not exist
For characteristics of SS MVTS-Pro, it control IP of Signaling GW and allow ANY IP of Media GW actually, so, if Live traffic show the issue, we should cross-check and do Joint test with WS customers first, a. b.
provide them CDRs of the problem no., for tracing Traffic source test with them, to verify Inter-connection from WS customers to us (to confirm if Test call can connect)
Proxy mode - we receive both Signal path and Media stream, Non-proxy mode - we receive Signal path only, bypass Media steam that WS customer and Carrier connect directly, so, Non-proxy mode of Incoming GW may help, but, a. b.
we do not know Inter-connection between WS customers and their customers SS MVTS allow ANY IP of Media GW (that we discussed before)
Note: If IP address or Port of Media GW is blocked on WS customers, Proxy or Non-proxy mode should not help any,
64 | P a g e
12.3 MVTS Pro Issues 12.3.1 CDR Replication stopped There are some situation where we experience CDR replication from main server to the backup server is stopped. Possible reasons were: -
Due to very high server loading, server hang up (input one command while another is still in progress) Due to server clocks were not in sync
Possible symptoms you may observe: When making test calls, the CDR shows in main server but does not appear in backup server Last 1000 CDRs or last hour CDRs in backup server are not the same as, or not in sync as with the main server If ever one notices such events, we must check the following: 1. Check if main server is generating CDRS. Check Last 1000 CDR or last Hour CDR. Check concurrent calls (should be above 1000 TS concurrent calls). This is to ensure normal operation is not interrupted. 2. Check in backup server the time of the last records of the CDR before replication has stopped – we may check it under last 1000 CDRs or last hour CDRs. We may need this additional information when coordinating with Mera Support 3. Check the active nodes. Some nodes may have restarted or missing; there should be 28 active nodes to this current writing. 4. Inform switch vendor ASAP (
[email protected]). For such urgent cases, Mera support should be the first point of contact for resolution. Alerting HK Team can be second priority, or we may keep them in the email loop for reference. 5. Whenever have the chance, contact Mera Support online (Skype or MSN) for faster resolution. Currently we may have limited online support from Mera, but for such cases buzzing them on Skype can help to check our concerns on priority. 6. To confirm if issue is resolved, check items 1,2 and 3. Constantly follow up if ever there are still issues.
12.3.2 Database Failure One of the reason for database failure issue is due to high server load. E.g. you are trying to filter on 24 hours CDR then you have noticed that it is taking a bit longer and then you have closed the tab (interface) and re-open and tried to run again. Now it became two ongoing process on database at that time because the previous process is not properly killed and after some time, it induced more and more process until the server is not able to handle anymore. This is the same case only with generating report on SS (running to process at a time). This problem can be fixed only by Mera support by killing all the running processes on all servers.
65 | P a g e
Please note this to prevent the same issue in the future: 1. As much as possible , use latest hour CDR or last 1000 CDR only or you may filter shorter period only (e.g. 1 hour period only) on Last 24 hour CDR, or use CDR ID (from SQL CDR) only for faster searching. 2. When you have noticed it is taking a bit longer to load, do not close the interface because it will not kill the process when you are extracting CDR or running a report , the solution is let it finish and do not run other process at the same time or you may go to other table (e.g. dialpeer table) so the current process will stop and the system will filter the DP instead.
12.3.3 Syntax Errors The team is reminded to be careful with routing, particularly with syntax errors. These careless mistakes maybe small, but may have great effect on live traffic. If such situation arises, it may help to remember recent changes (routing, blocked codes, etc.) done before the issue started, and revert back if necessary. If you encounter very unusual on MVTS-pro, it is best to coordinate immediately to MERA Support, through email, calls and instant messaging to help find the problem. Below are some syntax errors we must avoid: 1. Two delimiter “||” at the end of the number (e.g. 639186980715||) on blocking a DST number on pre-routing translation rules and dialpeers. – The effect is it will block all DST numbers on live traffic. 2. Using delimiter “|” on blocking SRC numbers on pre-routing translation rules and on dialpeers – The effect is it will block all blank SRC calls (calls with no ANI) as well.
12.3.4 Ghost Dial Peers due to Scripting Node Bug There are some situations where in we encounter calls coming in mysteriously from old/ deleted dial peers. You may observe in report generation or in ASR Report that there are still stats from ghost dial peers, but when you check in Dial Peers they were possibly already deleted earlier. In this case, there is an error in scripting node in which the ghost dial peer still existing, and may needs restarting. To identify which scripting nodes are at fault, we may need to do Call Simulation in each of the four scripting nodes. First, we should locate in the Last hour or Last 24 hours CDR some samples of these calls. We need to know the Origination IP and Incoming DST number of these calls.
Once we locate samples, we can go to Call Simulation; and fill up the required parameters:
66 | P a g e
Scripting Node – we should test from scripting -1 to scripting-4, to see which have errors SRC Protocol – SIP or H323 Origination IP Address – fill in the origination IP Destination Number – input Incoming DST number (including incoming prefix) Run the command for each scripting node
The result log will show the dial peers where the call went into, it will also display the ghost dial peer. Once we identify which Scripting node is affected, inform HK team (Michael or Vincent) to restart that node. Do a round of tests once again to check if there are still issues.
12.4 Types of Traffic 12.4.1 Call Center Traffic There are special types of routes which we can accept in call center traffic from our customers. This is voice traffic which came from call center that has distinctly very low completion rate, as most dialed numbers are not in service or invalid. We use special carriers which can freely accept call center traffic. Mixing this with normal voice traffic may result to significant degrade it stats, so we usually offer to customers at a high rate. For normal carriers, as much as possible there should be no CC traffic present as the resources would not be fully utilized. Most of these carriers do not have special equipment which can filter cc traffic from normal traffic automatically.
67 | P a g e
As a NOC member we should be aware which routes should there be cc traffic. If ever we may observe unusual stats from our normal destinations, we should be able to check and identify if customer is sending cc traffic. Below are some known characteristics to observe to identify cc traffic: 1. High volume traffic with Low ASR and ACD. Most calls are going to operator message only or are invalid numbers. 2. From the CDRs we may observe patterns from consecutive numbers in ascending series. Manual testing the numbers result to invalid number, not in service Ex. 861223344551, 861223344552, 861223344553, 861223344554, etc.
3. There are also unusual volume of numbers which come from one SRC number
4. Consecutive numbers with same short durations (less than 30 seconds)
If ever we observe this mixing with normal traffic, 1. Immediately inform customer to check traffic.
68 | P a g e
2. Attached sample numbers or CDR for better trace. 3. At the same time, we block the SRC number or number series in pre-routing or in dial peers. 4. Should they have not confirmed and they continue to send cc traffic, confirm with AM if necessary for follow up. 5. If partner have confirmed they have removed the fault traffic, we may unblock but check after few hours and confirm no cc traffic present.
12.5 Ring No Answer Scenarios Drop by termination side: 18 – no user responding 19 – no answer from the user
SIP, 408 Request Timeout SIP, 480 Temporarily unavailable
If the call is disconnected by termination, the call will overflow to next carrier as caller is still on line and the switch is trying every possible route it will connect. Drop by origination side: 16 – normal call clearing
SIP, 487 - Request Terminated
If the call is hang up by origination, then it will not overflow since the call is not active anymore
12.6 Look Ahead Routing (LAR) By default, all disconnect codes are able to reroute or overflow to the next route except for the calls that has LAR fault reasons (it means the call is not rerouted due to those reasons). If you see blank on that column, then the call was rerouted to the next carrier. Samples:
69 | P a g e
12.6.1 How to disable LAR for specific code Under Termination Equipment, add the SIP or H323 codes that you needs to disable the LAR then separate it with semicolon “;”.
12.7 Post Dial Delay (PDD) In order to achieve the good service for the user, the recommendations prescribe the values of PDD. These recommendations determine: the longest mean time of PDD (tmPDD) and the longest PDD duration for which 95% of connections will receive the answer from the called side (t95PDD). The recommendations are defined for local, transit and international connections. In [1] and [2] it is stated that tmPDD≤3s, 5s and 8s, and t95PDD≤6s, 8s and 11s for local, transit and international connections (respectively) and normal traffic load (load A). For the increased traffic load (load B) the values tmPDD≤4.5s, 7.5s and 12s, and 95PDD≤9s, 12s and 16.5s for local, transit and international connections (respectively) are recommended. In [1] it is stated that typical local, transit and international connection passes through 1-4, 5-7 and 8-10 network nodes, respectively. http://pe.org.pl/articles/2012/5b/37.pdf
12.8 ANI Translation We can use ANI translation in some cases where the customer is sending ANI with prefix which are not supported but most of the routes, specially the CLI routes. E.g. CCS CDR test results on our premium routes are showing ANI 79260437214 only on their CDR but on our side we are receiving ANI 10104#0079260437214 and the test calls are unable to connect.
"10104#00" is just their internal ANI prefix on testing our route so we can remove it on our side. We will just translate their testing ANI, e.g. from "10104#0079260437214" to "79260437214". All other ANI which are not starting with "10104#00" will not be affected.
70 | P a g e
Sample Orig SRC number translation:
71 | P a g e
13
Disconnect Cause Codes
13.1 SIP Response Codes The Session Initiation Protocol (SIP) is a signaling protocol used for controlling communication sessions such as Voice over IP telephone calls. SIP is based around request/response transactions, in a similar manner to the Hypertext Transfer Protocol (HTTP). Each transaction consists of a SIP request (which will be one of several request methods), and at least one response. Following is a list of SIP Response Codes:
13.1.1 Information SIP Responses – 1xx Informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response.
100 Trying Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response. 180 Ringing Destination user agent received INVITE, and is alerting user of call. 181 Call is Being Forwarded Servers can optionally send this response to indicate a call is being forwarded. 182 Queued Indicates that the destination was temporarily unavailable, so the server has queued the call until the destination is available. A server may send multiple 182 responses to update progress of the queue. 183 Session in Progress This response may be used to send extra information for a call which is still being set up. 199 Early Dialog Terminated Can be used by User Agent Server to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated.
13.1.2 Successful SIP Responses – 2xx The action was successfully received, understood, and accepted.
200 OK Indicates the request was successful. 202 Accepted Indicates that the request has been accepted for processing, but the processing has not been completed. 204 No Notification Indicates the request was successful, but the corresponding response will not be received.
13.1.3 Redirection SIP Responses – 3xx Further action needs to be taken in order to complete the request.
300 Multiple Choices
72 | P a g e
The address resolved to one of several options for the user or client to choose between, which are listed in the message body or the message's Contact fields. 301 Moved Permanently The original Request-URI is no longer valid, the new address is given in the Contact header field, and the client should update any records of the original Request-URI with the new value. 302 Moved Temporarily The client should try at the address in the Contact field. If an Expires field is present, the client may cache the result for that period of time. 305 Use Proxy The Contact field details a proxy that must be used to access the requested destination. 380 Alternative Service The call failed, but alternatives are detailed in the message body.
13.1.4 Client Error SIP Responses – 4xx The request contains bad syntax or cannot be fulfilled at the server.
400 Bad Request The request could not be understood due to malformed syntax. 401 Unauthorized The request requires user authentication. This response is issued by UASs and registrars. 402 Payment Required Reserved for future use. 403 Forbidden The server understood the request, but is refusing to fulfill it. 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. 405 Method Not Allowed The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. 406 Not Acceptable The resource identified by the request is only capable of generating response entities that have content characteristics but not acceptable according to the Accept header field sent in the request. 407 Proxy Authentication Required The request requires user authentication. This response is issued by proxys. 408 Request Timeout Couldn't find the user in time. 409 Conflict User already registered. Deprecated by omission from later RFCs and by non-registration with the IANA. 410 Gone The user existed once, but is not available here any more. 411 Length Required The server will not accept the request without a valid Content-Length. Deprecated by omission from later RFCs and by non-registration with the IANA. 412 Conditional Request Failed The given precondition has not been met. 413 Request Entity Too Large Request body too large. 414 Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
73 | P a g e
415 Unsupported Media Type Request body in a format not supported. 416 Unsupported URI Scheme Request-URI is unknown to the server. 417 Unknown Resource-Priority There was a resource-priority option tag, but no Resource-Priority header. 420 Bad Extension Bad SIP Protocol Extension used, not understood by the server. 421 Extension Required The server needs a specific extension not listed in the Supported header. 422 Session Interval Too Small The received request contains a Session-Expires header field with a duration below the minimum timer. 423 Interval Too Brief Expiration time of the resource is too short. 424 Bad Location Information The request's location content was malformed or otherwise unsatisfactory. 428 Use Identity Header The server policy requires an Identity header, and one has not been provided. 429 Provide Referrer Identity The server did not receive a valid Referred-By token on the request. 430 Flow Failed A specific flow to a user agent has failed, although other flows may succeed. This response is intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be treated as a 400 Bad Request response). 433 Anonymity Disallowed The request has been rejected because it was anonymous. 436 Bad Identity-Info The request has an Identity-Info header, and the URI scheme in that header cannot be dereferenced. 437 Unsupported Certificate The server was unable to validate a certificate for the domain that signed the request. 438 Invalid Identity Header The server obtained a valid certificate that the request claimed was used to sign the request, but was unable to verify that signature. 439 First Hop Lacks Outbound Support The first outbound proxy the user is attempting to register through does not support the "outbound" feature of RFC 5626, although the registrar does. 470 Consent Needed The source of the request did not have the permission of the recipient to make such a request. 480 Temporarily Unavailable Callee currently unavailable. 481 Call/Transaction Does Not Exist Server received a request that does not match any dialog or transaction. 482 Loop Detected. Server has detected a loop. 483 Too Many Hops Max-Forwards header has reached the value '0'. 484 Address Incomplete Request-URI incomplete. 485 Ambiguous Request-URI is ambiguous. 486 Busy Here Callee is busy. 487 Request Terminated Request has terminated by bye or cancel.
74 | P a g e
488 Not Acceptable Here Some aspects of the session description of the Request-URI is not acceptable. 489 Bad Event The server did not understand an event package specified in an Event header field. 491 Request Pending Server has some pending request from the same dialog. 493 Undecipherable Request contains an encrypted MIME body, which recipient cannot decrypt. 494 Security Agreement Required The server has received a request that requires a negotiated security mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between, or a digest authentication challenge.
13.1.5 Server Error SIP Responses – 5xx The server failed to fulfill an apparently valid request.
500 Server Internal Error The server could not fulfill the request due to some unexpected condition. 501 Not Implemented The server does not have the ability to fulfill the request, such as because it does not recognize the request method. (Compare with 405 Method Not Allowed, where the server recognizes the method but does not allow or support it.) 502 Bad Gateway The server is acting as a gateway or proxy, and received an invalid response from a downstream server while attempting to fulfill the request. 503 Service Unavailable The server is undergoing maintenance or is temporarily overloaded and so cannot process the request. A "Retry-After" header field may specify when the client may reattempt its request. 504 Server Time-out The server attempted to access another server in attempting to process the request, and did not receive a prompt response. 505 Version Not Supported The SIP protocol version in the request is not supported by the server. 513 Message Too Large The request message length is longer than the server can process. 580 Precondition Failure The server is unable or unwilling to meet some constraints specified in the offer.
13.1.6 Global Failure SIP Responses – 6xx The request cannot be fulfilled at any server.
600 Busy Everywhere All possible destinations are busy. Unlike the 486 response, this response indicates the destination knows there are no alternative destinations (such as a voicemail server) able to accept the call. 603 Decline The destination does not wish to participate in the call, or cannot do so, and additionally the client knows there are no alternative destinations (such as a voicemail server) willing to accept the call. 604 Does Not Exist Anywhere The server has authoritative information that the requested user does not exist anywhere. 606 Not Acceptable The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.
75 | P a g e
76 | P a g e
13.2 H.323 Disconnect Codes Decimal Value 1
Hexadecimal Value 01
Definition Unallocated (unassigned) number. This number is not in the routing table or it has no path across the ISDN cloud (network). 1. Check routing table to see it the number is available. 2. Check to make sure the correct digits were dialed and it is a valid number.
2
3
02
No route to specified transit network (national use).
03
The number was dialed with a transit network code such as 108880 to from AT&T to MCI and there is no route between the 2 networks. No route to destination. The dialed number is in the routing plan, but there is no physical route to the destination. 1. The link may be down at one end or the other. 2. The span or WAN is not connected correctly.
4
5
6
7
8
0
16
77 | P a g e
04
Send special information tone.
05
Indicates that the called party cannot be reached for reasons that are of a long-term nature and that the special information tone should be returned to the calling party. Misdialed trunk prefix (national use).
06
Indicates the erroneous inclusion of a trunk prefix in the called party number. Channel Unacceptable.
07
Indicates that the channel most recently identified is not acceptable to the sending entity for use in this call. Call awarded and being delivered in an Established channel.
08
Indicates that the user has been awarded the incoming call, and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode virtual calls). Pre-Emption.
09
Indicates that the call is being pre-empted. Pre-Emption Circuit reserved for reuse.
10
Indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Normal Call Clearing.
17
18
19
11
This is one of the most common cause codes and is received for many reasons. It usually occurs because someone hung up the call at one side or the other. User Busy.
12
The number dialed is busy and cannot receive any more calls. No User Responding.
13
The called party does not respond to the call, or does not wish to answer the call. No Answer from User (User Alerted). The called party has been alerted to the incoming call, but does not respond with a connect indication within a prescribed period of time.
14
Note: This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers. Subscriber Absent.
15
Used when a mobile station has logged off, radio contact is not obtained with a mobile station or if a personal telecommunications user is temporarily not addressable at any user-network interface. Call Rejected.
16
Indicates that the equipment sending this cause does not wish to accept this call, alth9ough it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. May also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. Number Changed.
26
1A
This is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause value, cause number 1 shall be used. Non-Selected User Clearing.
27
1B
Indicates that the user has not been awarded the incoming call. Destination Out-of-Order.
1C
This is a working number, but the span to the destination is not active or there is a problem sending messages to this destination. Invalid Number Format (address incomplete).
1D
Indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. This can happen when you are calling out using a network type number (enterprise) when you should be calling out Unknown or National for the Type of Number (TON). Facility Rejected.
20
21
22
28
29
This cause is returned when a supplementary service requested by the user cannot be provided by the network.
78 | P a g e
30
31
34
38
39
40
41
42
43
44
47
1E
Response to STATUS ENQUIRY.
1F
This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message. Normal, Unspecified.
22
This is a very common cause code and happens when the network is not able to determine what to do with the call being made. No Circuit/Channel Available.
26
There are no channels available to handle this call. This may happen if the destination gateway is full with calls. Network Out-of-Order.
27
Indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time. Permanent Frame Mode Connection Out-of-Service.
28
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service. Permanent Frame Mode Connection Operational.
29
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information. Temporary Failure.
2A
The call was disconnected due to a network failure. The network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately. Switching Equipment Congestion.
2B
Indicates that the switching equipment generating this cause is experiencing a period of high traffic. Access Information Discarded.
2C
Indicates that the network could not deliver access information to the remote user as requested, i.e., user-to-user information, low layer compatibility, high layer compatibility, or sub-address, as indicated in the diagnostic. Requested Circuit/Channel not Available.
2F
This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface. This may happen when you get in a glare condition: Both sides are selected topdown or bottom-up channel hunting. Resource Unavailable, Unspecified. Used to report a resource unavailable event only when no other cause in the resource unavailable class applies.
79 | P a g e
49
50
53
55
57
58
62
63
65
66
69
70
80 | P a g e
31
Quality of Service Not Available.
32
Used to report that the requested Quality of Service, as defined in Recommendation X.213, cannot be provided (e.g., throughput or transit delay cannot be supported). Requested Facility Not Subscribed.
35
This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause, but the user is not authorized to use. Outgoing Calls Barred Within Closed User Group (CUG).
37
Indicates that although the calling party is a member of the CUG for the outgoing CUG call, outgoing calls are not allowed for this member of the CUG. Incoming Calls Barred within CUG.
39
Indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed to this member of the CUG. Bearer Capability Not Authorized.
3A
Indicates that the user has requested a bearer capability which is implemented by the equipment that generated this cause but the user is not authorized to use. Bearer Capability Not Presently Available.
3E
Indicates that the user has requested a bearer capability, which is implemented by the equipment that generated this cause but which is not available at this time. Inconsistency in Designated Outgoing Access Information and Subscriber Class.
3F
This cause indicates that there is an inconsistency in the designated outgoing access information and subscriber class. Service or Option Not Available, Unspecified.
41
Used to report a service or option not available event only when no other cause in the service or option not available class applies. Bearer Capability Not Implemented.
42
Indicates that the equipment sending this cause does not support the bearer capability requested (i.e., requesting 64kb data when only speech is supported). Channel Type Not Implemented.
45
Indicates that the equipment sending this cause does not support the channel type requested. Requested Facility Not Implemented.
46
Indicates that the equipment sending this cause does not support the requested supplementary service. Only Restricted Digital Information Bearer Capability is Available (national
use).
79
81
82
4F
Indicates that the calling party has requested an unrestricted (64kb) bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability. Service or Option Not Implemented, Unspecified.
51
Used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies. Invalid Call Reference Value.
52
Indicates that the equipment sending this cause has received a message with a call reference that is not currently in use or assigned on the usernetwork interface. E.G. The call that is being reference by this value, does not exist on this system. Identified Channel Does Not Exist. Indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call.
83
84
85
86
87
88
53
For example, if a user has subscribed to those channels on a PRI numbered from 1 to 12 and the user equipment or the network attempts to use channels 13 through 23, this cause is generated. A Suspended Call Exists, but This Call Identity Does Not.
54
Indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended calls(s). Call Identity in Use.
55
Indicates that the network has received a call suspended request containing a call identity that is already in use for a suspended call within the domain of interfaces over which the call might be resumed. No Call Suspended.
56
Indicates that the network has received a call resume request containing a call identity information element, which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed. Call Having the Requested Call Identity Has Been Cleared.
57
Indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended. User Not Member of CUG.
58
Indicates that the called user for the incoming CUG call is not a member of the specified CUG or that the calling user is an ordinary subscriber calling a CUG subscriber. Incompatible Destination. The number being dialed is not capable of the type of call. 1. Calling a restricted line in unrestricted mode.
81 | P a g e
2. Calling a POTS phone using unrestricted mode.
90
5A
Indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other compatibility attributes which cannot be accommodated. Non-Existent CUG.
91
5B
Indicates that the specified CUG does not exist. Invalid Transit Network Selection (national use).
5F
Indicates that a transit network identification was received which is of an incorrect format as defined in Annex C/Q.931. Invalid Message, Unspecified.
60
Used to report an invalid message event only when no other cause in the invalid message class applies. Mandatory Information Element is Missing.
61
Indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message. Message Type Non-Existent or Not Implemented.
95
96
97
98
99
100
101
102
62
63
Indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause. Message is Not Compatible with the Call State, or the Message Type is Non-Existent or Not Implemented. Indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state. An Information Element or Parameter Does Not Exist or is Not Implemented.
64
Indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element identifier(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. Invalid Information Element Contents.
65
The call has an information element that is not understood by the switch being called. This cause is usually followed by the information element that is causing the problem. The Message is Not Compatible with the Call State.
66
Indicates that a message has been received which is incompatible with the current call state for this call. Recovery on Timer Expired. This occurs when ISDN messages dont arrive in specified time according to
82 | P a g e
the Q.931 specification.
103
110
111
127
67
This cause is sometimes followed by the timer that has expired. Parameter Non-Existent or Not Implemented Passed On (national use).
6E
Indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending the cause. Message with Unrecognized Parameter Discarded.
6F
Indicates that the equipment sending this cause has discarded a received message, which includes a parameter that is not recognized. Protocol Error, Unspecified.
7F
Used to report a protocol error event only when no other cause in the protocol error class applies. Interworking, Unspecified. Indicates that there has been interworking with a network which does not provide causes for actions it takes. Thus, the precise cause for a message which is being sent cannot be ascertained.
83 | P a g e
14
Retail Works This is a special case only when no Retail support is on duty, e.g. during Holidays etc. In this case NOC is responsible for some Retail duties (Sync file, Export Pins, and Payment). Below are the following steps to be done.
14.1 Sync File Agents request for line activation of the ATL accounts in order for the client’s immediate use. They will ask us to sync the changes they made in our local database, and upload (or SYNC) the changes to our HK servers. This is also the first step on the Export Pins and payment process.
1. From browser, login to EBS 192.168.78.15
2. Fill up the three menus (red box) you may enter and ATL number as keyword (in this example is use ATL50). As long as there is customer information shown below (e.g. CustomerID = 50 ) 3. Click on the Account button, you will then be navigated somewhere at the middle of the page 4. Click on the Create Sync file button, you may have to give some time for it to generate. 5. Once completed, you will be prompted with a dialog box saying “Process completed”
84 | P a g e
6. Click OK, then you can then minimize the browser window.
7. From the desktop Open the Ultra VNC Client (green icon). Make sure VNC Server is connected to IP 192.168.78.7 please see below screenshot for reference: 8. When prompted for password, type “atl” 9. You will then be opening a remote desktop environment. This is our remote PC in our HK office.
85 | P a g e
10. On the remote desktop locate and open the “atl” software, icon is like below:
11. It will prompt with login window. Please fill up with User Name: sa And Password is: atl
12. Choose Asia Reseller1. Then Select Pin Codes.
13. A new window will open. Locate “Import” at the bottom right of the page. Another dialog box will open, just click OK.
86 | P a g e
14. Select the shortcut icon “Shortcut to SYNC_1611”. Then scroll to the right most part of the subfolder and click the text file with contain the current date as title. Click Open.
87 | P a g e
15. Another dialog box prompt will open, click OK then the system will do the import process. Wait until loading bar reaches 100% completion. The boxes will all close after that and will prompt you back to the main window. Hit Close button until you go back to remote desktop environment.
16. Open atl icon again. This time do the Sync file for Asia Reseller2
17. Click Import Button , and click OK on the dialog box
88 | P a g e
18. You will be prompted which file to open. This time, choose the file “shortcut to SYNC_161100”. Scroll to the rightmost part and choose the one with the latest date.
19. Another dialog box will open, click OK.and system will do the Import process. Wait until its 100% complete. 20. You may then close the windows and exit the VNC remote desktop.
14.2 Export Pins This process is important as we need to keep our servers (Local and HK servers) in sync with the most recent information (call records and all other transactions) . We do export pin process 3 times in a day – in morning, in afternoon, and in the evening. As an NOC night shift member, one must know and master this procedure, in special cases and in holiday duty. 1. Firstly, do Sync File for Reseller1 and Reseller2 (procedure above). Once Sync File is finished, keep the VNC Remote Desktop environment open. 2. Open atl icon again. Go to Asia Reseller1, then click Pin Codes.
89 | P a g e
3. This time click the Export Button. Dialog box will appear, click OK
4. You will be asked to open a file. Choose “Desktop” from the pull down tab.
90 | P a g e
5. Choose “Shortcut to pincode”, then choose Reseller1, then the text file exp_pin.txt.
6. When asked to overwrite, Click yes on the dialog box, and system will do the export pin.
91 | P a g e
7. Wait until process is finished, it takes about 15 minutes. Then close all the windows, and remain on the remote desktop environment. Export Pin for Reseller1 in finished.
8. Open atl icon again. This time choose Asia Reseller2. Click on the Pin Codes.
9. Click on the Export Button, click OK on the dialog box. Chhose Desktop on the pull down tab.
92 | P a g e
10. Choose Shortcut to pincode, choose Reseller2, choose exp_pin.txt file
11. Click “Yes” when asked to overwrite. Then wait until process is finished. Then close the windows and exit the VNC environment.
12. From the desktop, open PuTTY program. Select ebs, click Load.
93 | P a g e
13. A terminal window will appear. Please log in with them below information: login as: ebs Password: ebs123 -sh-3.00$: su Password: connect1611 14. You will then reach the directory [root@ebs1 ebs]# . from here type the below commands: cd /usr/local/ebs/bin ls ./updateAllPin.sh 15. System will now process the files. Wait until finished, you will go back to [root@ebs1 ebs]# directory.
16. Type in exit two times and window will be closed. Send an email informing noc and retail team that export pin process is done this evening.
94 | P a g e
14.3 PHCC and PPN Payment This procedure we are gathering all the customer payment done within the day and importing it to our HK database. This procedure is very sensitive as this contains all payment information, so be very careful. 1. Do the Sync File procedure. 2.
From the desktop, navigate to our share folder (192.168.79.12). Find New Account folder. Find EBS folder. Then locate the two excel files EBS –Limit Alteration form – PHCC& IPP& RI. Latest version upon this writing is ver14. The other file is EBS- Limit Alteration Form – PPN & PIPP & PPP. Latest version upon this writing is ver5
3. On the PHC form, there are three tabs on the top area of the sheet. Click Get Payment
4. Enter the date yesterday. Please note the date format should always be year-month-day
5. The sheet will generate all the PHCC payment within the day. When finished, click on the Save Limit, enter the date today. Please observe proper date format.
95 | P a g e
6. Click OK on the popups :
Payment counts saved
Updating Load Service account
Update Done.
7. Click file then Save AS. Save to 192.168.79.12PHCC History with current date as a file name. Put c at the end indicating evening payment (a indicates morning and b is afternoon payment) E.g. 20121114c 8. Close the PHCC excel file. 9. Done same procedure On the PPN excel file. Click Get Payment, enter date yesterday. Observe proper date format.
96 | P a g e
10. Click Save Limint, then enter current date
11. Click file then Save AS. Save to 192.168.79.12PPN History with current date as a file name. Put c at the end indicating evening payment (a indicates morning and b is afternoon payment)
97 | P a g e
E.g. 20121114c 12. Close the excel files. 13. Open UltraVNC from the desktop. login host server 192.168.78.7 with password atl 14. On the remote desktop environment open the atl icon. Login with password atl
15. Choose Asia Reseller1 choose Pin codes
16. Click on Import, click ok on dialog box. Choose the file Shortcut to Daily, then choose PHCC(new). Srcoll to the right most part then choose the file name with the latest date. click OK
98 | P a g e
17. Wait till import process is done. Close all windows until on the remote desktop environment. 18. Open atl icon again log in to Asia reseller2, choose Pin codes. 19. Click on the Import btton, click OK on dialog box. Choose Shortcut to Daily. Now choose PPN. Scroll to the rightmost part, then choose the file with th current date. 20. Wait until process is finished. Close all the windows and the VNC remote desktop. 21. Email to noc and retail team that Payment is uploaded this evening. Indicate the ime of the sync file for reference.
99 | P a g e
15
Release Notes Version 201305: Added new topics 10 Web-based WS System 11.6 Ghost Dial Peers due to Scripting Node Bug 12.2.3 Codec Incompatibility Version 201306: Added new topics 12.3.1 CDR Replication stopped 12.4 Types of Traffic Version 201307: Added more details on below topics 12.2.4 Codec Matching 12.2.8 SIP 18x before SIP 503 Issue 13.1 SIP Response Codes Version 201308: Added new topics 12.1.1 Disclosing of Information to Partners 12.3.2 Syntax Errors Version 201309: Added new topics 9 ASR Report File 12.2.9 TS, 8 - [H.323] Procedure failure Version 201310: Added new topics 11.5.6 DST Allow Patterns and Code Mismatch 12.2.10 Incorrect PDD Value 12.2.11 Loopback Call Issue 12.3.2 Database Failure Version 201311: Added new topics 12.5 12.6 12.7
Ring No Answer Scenarios Look Ahead Routing (LAR) Post Dial Delay (PDD)
Version 201312: Added new topics 5.4 12.8
100 | P a g e
Extracting CLI using DTMF Tones ANI Translation
