[cisco-voip] Digit Delay on 7 digit dialing

[Brian Meade]

Yea, DNA does the analysis enbloc rather than digit-by-digit so kind of
limited there besides just pulling out all the patterns and doing some
manual analysis.


On Thu, May 15, 2014 at 11:58 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> I don't think DNA shows you potential matches in that way though.
>
> For example: take patterns 1XXX AND 12XX. If I DNA for 1250 I should hit
> 12XX and DNA should show 1XXX as alternate match. However that does not
> cause T302. If I also had a pattern 1250X then I would hit T302 but DNA
> will not show it as a potential match.
>
> So darn, no easy way huh?
>
>
> On Thursday, May 15, 2014, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> There's not an easy way I know of besides using DNA.
>>
>>
>> On Thu, May 15, 2014 at 11:45 AM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>> Brian,
>>
>> Is there a way we can see those potential matches? Trace settings
>> perhaps? I'd like to avoid something complicated like dumping the dial plan
>> then running it through a python script. Which, if it comes down to it,
>> I'll do just that. Thanks.
>>
>> On Thursday, May 15, 2014, Brian Meade <bmeade90 at vt.edu> wrote:
>>
>> Matthew,
>>
>> Just got your log file.  I don't see the good example to compare but
>> here's what happens in the bad example:
>>
>> The Digit Analysis response shows that there are still off-net potential
>> matches that exist:
>> 80256949.000 |10:38:02.774 |SdlSig   |DaRes
>>    |info_da                        |Cdcc(2,100,212,3922322)
>>  |Da(2,100,204,1)
>>  |2,100,13,6484893.43368^1.8.40.57^SEPC40ACB4D64B2
>> |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=41764100 Dial
>> ExclusivelyOffNetPotentialMatchesExist OffNet
>> PretransformCgpn=tn=0npi=0ti=1nd=1665pi=0si0
>> Cgpn=tn=0npi=0ti=1nd=4013471665pi=0si0
>> DialingPartition=fe6a2257-c0b2-4185-a608-e5dab0982065
>> DialingPattern=9.[2-9]XXXXXX
>> DialingRPRE=(9)([2-9][0-9][0-9][0-9][0-9][0-9][0-9]) PID=(2,82,214)
>> PretransformCdpn=tn=0npi=0ti=1nd=92704112pi=0si0
>> PretransformTags=ACCESS-CODE:SUBSCRIBER PretransformPos=9:2704112
>> CollectedDigits=tn=0npi=0ti=1nd=92704112pi=0si0 Tags=ACCESS-CODE:SUBSCRIBER
>> Pos=9:2704112 CalledPartyLocalRouteGroup=patternUsage =5requestID =0
>>
>>
>> The Cdcc process then doesn't do anything for 7 seconds until we see the
>> T302 timer end:
>> 80260154.000 |10:38:10.277 |SdlSig   |StationT302
>>    |overlap_sending2               |StationCdpc(2,100,59,5990797)
>>  |SdlTimerService(2,100,3,1)
>> |2,100,13,6484893.43368^1.8.40.57^SEPC40ACB4D64B2
>> |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0]
>>
>>
>> That's the source of the 7 second delay.  You have some sort of overlap
>> in your dialplan.
>>
>> Brian
>>
>>
>> On Tue, May 13, 2014 at 12:39 PM, Matthew Loraditch <
>> MLoraditch at heliontechnologies.com> wrote:
>>
>>  And apologies to everyone for that log file………… I was doing other
>> things and didn’t realize how big it was….
>>
>> I guess I owe everyone whom I see next week a beer…
>>
>>
>>
>>
>>
>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA
>>
>> 1965 Greenspring Drive
>> Timonium, MD 21093
>>
>> direct voice. 443.541.1518
>> fax.  410.252.9284
>>
>> Twitter <http://twitter.com/heliontech>  |  Facebook<http://www.facebook.com/#!/pages/Helion/252157915296>
>> | Website <http://www.heliontechnologies.com/>  |  Email Support
>>
>> Support Phone.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140515/b32a80ff/attachment.html>