11 MVTS-Pro Configurations
11.5 Routing Update
11.5.6 DST Allow Patterns and Code Mismatch
Please note that MVTS is checking first the DST-prefix patterns before it checks the precedence in finding where the traffic should go first.
51 | P a g e
1. It is checking first the DST allow patterns. The longer the codes, the higher the priority. E.g. we have two DP for Vietnam Mobile, the 1st DP has DST allow pattern of 841.* and the 2nd DP has DST allow pattern 84121.*. The call will go first on the 2nd DP even if the 1st DP has higher precedence than the 2nd DP.
2. If the DST allow pattern on all DP are the same, MVTS will then check the precedence to find where the traffic should go first.
Therefore, all routing should have the same DST prefix allow patterns on each destination so that the routing sequence will be based on precedence only.
For code mismatch, we should always block the unsupported codes instead of opening the supported codes to keep the “DST Allow Patterns” uniform on all DPs for each destination.
52 | P a g e
12 Troubleshooting Guides 12.1 What to do and How to Respond
1. You should always extract the CDRs of their given sample numbers to understand why the calls did not complete. (Request CDR from them if not given)
2. If you found an issue on the carrier, you need to block the faulty carrier and raised TT to them. If no other carrier on the routing, try to replace it with a working one which is within the rate offer. Then inform customer as follows:
“We thank you for bringing this into our attention. We observed a temporary issue and now it is resolved.” (you can add real time stats or test calls to show that the route is working fine)
If no carrier for replacement, we should tell customer as follows:
“We thank you for bringing this into our attention. We have duplicated this problem and we already raised the issue with our carrier partner. We will get back to you at the earliest.”
3. If you 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.”
4. 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:
“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
53 | P a g e
than when they faced the problem so more reason to understand the problem) 3. Give them supporting details which shows our routes are working well.
Most important to remember
1. think clearly, read the email correctly to understand the exact problem raised by carrier and use simple but sound logic when doing trouble shooting
2. For problems we raise to carriers, be very clear in your TT so carrier easily understands the problem and try and follow up after a short via MSN or phone especially for those routes which we send good volume of traffic to as well as those where we do not have sufficient backup routes
12.1.1 Disclosing of Information to Partners
There have been instances wherein carriers reveal us their condition about their termination carriers. These maybe unreliable and does not describe whole picture of the route. Most of this information are discussed internally only, and suggested not to be shared such information to our ingress partner/ customer. This sensitive information mentioned such as Carrier Name, IP Addresses, NOC or Accounts Manager Names, Contact numbers, etc. should be taken for internal references only.
If Customer is asking for update we can reply to them as general as possible
1. If the issue is between our carrier and their supplier only, we will just inform our customer that we have temp capacity issue only, etc.
2. If the issue is general, e.g. all routes including CLI routes as well are down due to cable cut, bad weather, political, etc. then we can tell to our customers those information.
12.2 Factors that Affects the Call Quality
12.2.1 Media Packets
If live traffic send us with a kind of Codec that we do not support, live traffic is possible connect but do not negotiate a proper Codec on SS. CDRs will show Media packets missing (the incoming and outgoing codec legs are incomplete)
E.g. WS customer <-> AsiaTel showing "blank", AsiaTel <-> Carrier showing "g.729"),
To avoid the issue, we choose Codec group 1 that included most of available Codec (i.e.
we accept Live traffic with any Codec)
54 | P a g e
If in case live traffic cannot connect well with a kind of Codec, we can choose other Codec group which narrow down kind of available Codec,
"Always discard non-matching codecs" option (on Incoming GW) should be enabled in order to reject Live traffic using un-supported Codec with returning Busy tone cc. 34 (i.e. Overflow signal), E.g. Incoming GW of Joint Power traffic as an example (for Joint test, they connect well using g.729 only, point to Codec group 14 and reject the rest)
12.2.3 Codec Incompatibility
There are some situations which one may encounter tickets from customers pushing us to improve the route Statistics (ASR and/ or ACD). There are many approaches in order to check and improve at our end, but will share some basic understanding regarding codec compatibility, and how it helps to improve stats.
One should check on the CDRs, and identify if there are some codec incompatibility, between Incoming traffic and SS equipment, or between Incoming traffic and carrier partner. Take last hour stats, or last 1000 samples of the traffic. Or if they are complaining for past records, we may use Last 24 hours CDR or the latest ASR report. Commonly, we can see in the CDRs that there may be calls which failed due to Incompatible Codecs.
If there is still traffic going in, we may need to acquire sample trace or log file of the failed calls.
We can obtain log by going to Equipment-> Customer Incoming Equipment-> then put a check mark on Origination Logging. We can run the logging for a short period of time only, or until we capture 3-5 failed samples. We can check if we had captured calls already by going to Debugging-> Debug calls. Never forget to turn the logging off, to avoid wasting of valuable resources. Once we have acquired the debug calls we can investigate further as to which codecs they are sending, and if our switch are able to match with the settings we put to them initially (during the interconnection process).
From the debug log, we can observe the codecs they are sending by looking on the INVTE, if the interconnection is SIP. Or in OUT CallBegin, if interconnection is H323. Below is sample of SIP Log. From the log below, we can see the codecs in the rtpmap and fmtp parameters. Payload type (red font) will indicate with rtpmap and fmtp are together.
v=0
o=- 1364827029 1364827029 IN IP4 218.189.19.2 s=-
55 | P a g e
a=sendrecv
Below is sample Log from H323. The codecs can be found on fmt and vad parameters, under srcMedia
};
srcVendor "TS-v4.5.0-08ae";
srcMedia {
56 | P a g e choose Codec Group13 (Codec Group 1 with and without VAD)
There are also special cases in which the terminating carrier has limited codec support (ex carrier support G729 only for the particular destination). In this case our switch can support codec
57 | P a g e
transcoding, just make sure we open the supported codecs on customer traffic towards our switch, then opening the supported codecs from our switch towards termination carrier. MVTS can do convert the traffic to the supported codecs allowed by the carrier end. There will be some implications, or quality may change due to the conversion process itself, but this is better option than calls will fail due to incompatible codecs. We can take the case related to this item as below:
E.g. Worldhub traffic to BTglobal
I checked your test DP via BTglobal and I noticed you are trying to use the codecs which Worldhub is currently sending.
First, the concept of matching customers codec is advisable only on Origination GW not termination GW because vendor may not support all codec which our customer is sending to us. If customer is sending codec other than our vendor can support, MVTS is doing codec transcoding or codec conversion to be able to pass customer's traffic to vendor side.
On your test below, BTS is not supporting G729AB,G.729_vad and G.729A_vad that's why calls encountered "no compatible codec"
issue. This is not related to Worldhub traffic as we are the one forcing to send those codec to them.
I study your debug sample as well and I found on their INVITE, the useful 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=- their traffic will get "No compatible codec" issue.
58 | P a g e
But at this point, we cannot match worldhub codec with btglobal codec due to carrier limitation.
Codec transcoding is helping on matching codec but quality may reduced depending on how many times the codec was converted. The more the codec transcoding, the lower the quality will be. That's the reason why other customers are just passing their customer's traffic without changing the codec but the drawback of this is, it is more prone to codec compatibility issue. As a result, doing codec transcoding is still better.
12.2.4 Codec Matching
You may go through the following steps.
1. Enable the origination logging to find the exact codec they are using (because each codec may have different settings)
2. Under 'INVITE' section, you will see for e.g. G729a on their call.
v=0
o=SYN-UK-SBC-1-1 10518101 10518101 IN IP4 188.244.114.23 s=sip call
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 {
4. Now you can add that codec on the codec group list. You can clone default g729 codec (vad disabled) and just add their codec (G729a) on the rtpmap as follows.
59 | P a g e
Note: You will notice also that we have G.729A already on the list but their call is still fail failing. It is because their rtpmap is G729a and not G.729A. rtpmap should be perfectly match with their's.
5. Now their g729 call should connect successfully now.
12.2.5 Multiple Codec Transcoding
I we use codec group 1, it will minimize the codec transcoding as we will just pass customer traffic to supplier without converting it to specific codec only. This is applicable only if supplier support all the codecs and customer is sending diff codecs which probably means they are not doing codec transcoding also. When the call do multiple transcoding, the ACD will drop considerably and it will affect the call quality because a lot of clipping will be done on it. Below are example experiment.
customer G729 to carrier G729 = ACD is 90 secs customer G729 to carrier G723 = ACD is 30 secs
12.2.6 False Answer Supervision
False Answer Supervision (FAS) occurs when providers terminate calls fraudulently, resulting in the calling party being overcharged for calls, or charged for calls that were never completed.
Types of FAS
FAS can occur in one of three ways:
• Calls that are not successfully completed but that are billed anyway
• Deliberate rerouting of calls to an automated messaging platform designed to trick the customer into staying on the line
• Premature billing during Post Dial Delay (PDD) or ringing time prior to when the call is 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-per-minute rates.
60 | 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.
61 | 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:
62 | P a g e
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.
63 | 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
In order to detect loop calls, the NOC member should manually test a carrier, and observe in