LAGS WHILE BEFORE A DIALLED NUMBER CONNECTS

[ugwuugochukwuk]

Hello All,

A client of mine complained they experience lags while making calls on their IP phones. When you dial a number, it takes almost a minute before the call connects. This wasn't the case before now. 

Note: This does not affect all the users.

Kindly assist.

Thanks in anticipation!!!

[Jaime Valencia]

Start by looking at the detailed call flow, review dial plan overlapping, and as you don't provide any more details (products, call flow, etc.), review traces/debugs as necessary to find out if the communication happens correctly and where the delay is introduced.

[ugwuugochukwuk]

Hello Jamie,

What output are you advising I review ? Below is the Dialled Number Analyzer Output for one of the user experiencing the lag.

<?xml version="1.0" standalone="yes" ?>

<DigitAnalysisResult>

       <ResultsSummary>

              <CallingPartyInfo>

                     <CallingParty><![CDATA[1386]]></CallingParty>

                     <Partition>PT_ABA:PT_ABJ:PT_AMA:PT_AWO-OMAMMA:PT_BENIN:PT_DIRECT_LINES:PT_ENUGU:PT_FIN:PT_GSM_NUMBERS_FAC:PT_HEINET_FAC:PT_IBADAN:PT_ICD:PT_ICT:PT_IJEBU-ODE:PT_KADUNA_KAKURI:PT_KADUNA_KUDENDA:PT_LAGOS:PT_LOCAL_NUMBERS_FAC:PT_NATIONAL_NUMBERS_FAC:PT_OFF_HOURS:PT_ONITSHA:PT_ON_HOURS:PT_SALES:PT_OTA</Partition>

                     <DeviceCSS></DeviceCSS>

                     <LineCSS>CSS_GSM_ACCESS_FAC</LineCSS>

                     <AARGroup></AARGroup>

                     <AARCSS></AARCSS>

              </CallingPartyInfo>

              <DialedDigits><![CDATA[1352]]></DialedDigits>

              <MatchResult>RouteThisPattern</MatchResult>

              <MatchedPatternInfo>

                     <Pattern><![CDATA[1352]]></Pattern>

                     <Partition>PT_LAGOS</Partition>

                     <TimeSchedule></TimeSchedule>

</MatchedPatternInfo>

              <CalledPartyNumber> <![CDATA[1352]]></CalledPartyNumber>

<TimeZone>Etc/GMT</TimeZone>

              <DeviceLocation>OnNet</DeviceLocation>

              <InterDigitTimeout>YES</InterDigitTimeout>

              <AllowDeviceOverride>Disabled</AllowDeviceOverride>

              <OutsideDialTone>NO</OutsideDialTone>

       </ResultsSummary>

       <CallFlow>

<DirectoryNumber DN = "1352">

<Partition>PT_LAGOS</Partition>

<TypeCFACSSPolicy>Use System Default</TypeCFACSSPolicy>

<DeviceLocation>Unknown</DeviceLocation>

<ForwardingData>

<ForwardAll dn = "" VoiceMail = "No" CSS = ""></ForwardAll>

<ForwardBusy><Internal dn = "" VoiceMail = "No" CSS = ""></Internal><External dn = "" VoiceMail = "No" CSS = ""></External></ForwardBusy>

<ForwardNoAnswer><Internal dn = "" VoiceMail = "No" CSS = ""></Internal><External dn = "" VoiceMail = "No" CSS = ""></External></ForwardNoAnswer>

<ForwardNoCoverage><Internal dn = "" VoiceMail = "No" CSS = ""></Internal><External dn = "" VoiceMail = "No" CSS = ""></External></ForwardNoCoverage>

<ForwardUnregistered><Internal dn = "" VoiceMail = "No" CSS = ""></Internal><External dn = "" VoiceMail = "No" CSS = ""></External></ForwardUnregistered>

<CFDF dn = "" VoiceMail = "No" CSS = ""></CFDF>

<PickupGroupNumber></PickupGroupNumber>

</ForwardingData>

<Device Type ="Cisco 7945">

<DeviceStatus>Registered</DeviceStatus>

<DeviceName>SEP00235E1A00E0</DeviceName>

<IgnorePresentationIndicators>Disabled</IgnorePresentationIndicators>

<LoggedIntoHuntGroups>Enabled</LoggedIntoHuntGroups>

<AlertingName>

SYS Solutions/Services MGR.</AlertingName>

<IsDualMode>

Disabled</IsDualMode>

<DoNotDisturb>

<DNDStatus>

Disabled</DNDStatus> <DNDOption>

</DNDOption>

<DNDRingSetting>

</DNDRingSetting>

</DoNotDisturb>

<AutomatedAlternateRouting>

<AARGroup></AARGroup>

<AARCallingSearchSpace></AARCallingSearchSpace>

<AARVoiceMailEnabled>Disabled</AARVoiceMailEnabled>

<AARDestinationMask></AARDestinationMask>

<AARPrefixDigits></AARPrefixDigits>

</AutomatedAlternateRouting>

</Device>

<Device Type ="Cisco IP Communicator">

<DeviceStatus>UnKnown</DeviceStatus>

<DeviceName>SEP50E085478E16</DeviceName>

<IgnorePresentationIndicators>Disabled</IgnorePresentationIndicators>

<LoggedIntoHuntGroups>Enabled</LoggedIntoHuntGroups>

<AlertingName>

SYS Solutions/Services MGR.</AlertingName>

<IsDualMode>

Disabled</IsDualMode>

<DoNotDisturb>

<DNDStatus>

Disabled</DNDStatus> <DNDOption>

</DNDOption>

<DNDRingSetting>

</DNDRingSetting>

</DoNotDisturb>

<AutomatedAlternateRouting>

<AARGroup></AARGroup>

<AARCallingSearchSpace></AARCallingSearchSpace>

<AARVoiceMailEnabled>Disabled</AARVoiceMailEnabled>

<AARDestinationMask></AARDestinationMask>

<AARPrefixDigits></AARPrefixDigits>

</AutomatedAlternateRouting>

</Device>

</DirectoryNumber>

       </CallFlow>

       <AlternateMatches>

       </AlternateMatches>

</DigitAnalysisResult>

[TONY SMITH]

---

@ugwuugochukwuk wrote:

Hello All,

A client of mine complained they experience lags while making calls on their IP phones. When you dial a number, it takes almost a minute before the call connects. This wasn't the case before now. 

Note: This does not affect all the users.

---

Do you mean it affects only some users, and those users get the issue every time? Or is it some users and only some of their calls?

Does it happen with on-hook dialling or only off-hook?  Or when they're returning a call from the call history?

Looking at your hellishly unreadable DNA output (screenshot would be much easier to read), it appears the number is matching the pattern "!" which means it will wait for interdigit timeout.  Is this a PSTN call, and have you created a reasonable dial plan for your country?  Normally you should only have to use a simple "!" for International dialling, and even then I would add some explicit matches for frequently dialled countries.

[ugwuugochukwuk]

Hello Tony,

It affects some users and all their calls. It happens when these users want to make calls. When they dial the intended number, it takes about one minute for the call to connect whereas for other users, it connects immediately.

[TONY SMITH]

Please show screenshots of the DNA call flow for an example of each, one for a call that goes through immediately and one for a call that experiences the delay.  Are you completely sure the users are dialling in the same way, for example are you sure that some users aren't dialling on-hook and some dialling off-hook?

[ugwuugochukwuk]

Hello Tony,

Kindly find the screenshot of the DNA output from one of the users that experience the lags below.

[TONY SMITH]

How does that differ from a non-delayed call?  In this call he's dialling 1388 and reaching an internal extension with than number.  Do you have other dial patterns that could overlap?  If so then make sure your directory numbers are flagged Urgent (this is not default).

[ugwuugochukwuk]

Hello Tony,

Attached is the screenshot of the DNA output from a user who does not experience the delay. There are no other dial plans.

For this user with the attached screenshot, immediately I finish dialing the number, the call goes through and the user's phone at the other end starts ringing.

For another set of users, after I must have dialed the numbers, it takes couple of seconds or a minute before it starts ringing.

[TONY SMITH]

Your delayed call to 1388 shows "Inter Digit Timeout = YES", the non delayed call to 1383 shows "Inter Digit Timeout = NO".  So there could be a few reasons, maybe you have something that overlaps with 1388 but not with 1383, or you have 1383 marked Urgent but 1388 isn't, or the overlap is in a Partition visible to one caller but not the other.  Or possibly the calls are dialled differently.  Were they dialled on-hook or off-hook?  I think I asked that a couple of times, but it's important because with most phones if you dial on-hook then there's an implied end of dialling when you lift the receiver up to place the call.

For your test calls do the following ... lift the receiver off hook, or press the speaker button, so you have dial tone before dialling.

Can you post your dial plan report?  "Call Routing / Route Plan Report" then from "Related links" top right, select "View in File"

Also the contents of the CSS_INTERNATIONAL_ACCESS_FAC and CSS_ICT_AGENT_ACCESS

[ugwuugochukwuk]

Hello Tony,

I just made off hook calls now as advised on both phones, and I have attached the DNA output. I've also attached the Dial Plan Report as requested. 

I also checked to confirm, none of the numbers are marked as urgent priority 

[TONY SMITH · Accepted solution]

You have a route pattern "1XXXXXXX" in PT_LOCAL_NUMBERS_FAC.  When the user dial 1388 the system is going to sit and wait to see if any more digits are going to be dialled.  If you really want to keep this overlap, which is not advised, you should mark the internal DNs starting with 1 as urgent.  The downside is that these will block calls to local numbers starting with those digits.  For example you have an extension 1493 so would not be able dial Lagos airport as 14933385.

[ugwuugochukwuk]

Many thanks Tony for your help, I really appreciate.

I just deleted the route pattern you mentioned above and the users can make calls without the experiencing the delay.. I will keep on monitoring the situation.

Many thanks once more for the help.

[ugwuugochukwuk]

Hello Tony, 

Trust you're well ?

I have some users whom their directory numbers start with two (2) who are still experiencing this lag when making calls. The lags are experienced when they make off-hook calls. They are also users whose directory numbers start with two (2) who do not experience any lags.

Please what do you think could be the cause ?

Thanks in anticipation!!

[TONY SMITH]

The lag first mentioned was caused by an overlap, which means that there are different length patterns starting with the same digit matches, and these overlapping patterns are visible to the CSS of the calling device. The actual number of the calling device doesn't matter, what matters is its CSS and the destination pattern.

So in the previous example the user dialled 1388 and the device CSS was able to see both the intended destination in "PT_LAGOS" and also the overlapping pattern 1XXXXXXX in "PT_LOCAL_NUMBERS_FAC". Another phone whose CSS did not include that second partition, would be able to dial 1XXX extensions without delays.

Your dial plan has lots of potential overlaps, but to see where they actually take effect we need to know the number dialled, and the CSS of the calling device, and the contents of that CSS.  

Can you do what you did before, and post screenshots from DNA showing this delayed call from one of your 2XXX extensions?