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 < [email protected]> 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 <[email protected]> wrote: > >> There's not an easy way I know of besides using DNA. >> >> >> On Thu, May 15, 2014 at 11:45 AM, Anthony Holloway < >> [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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. >> >>
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
