Module 01 - Dialed Number Analyzer not triggered correctly on 9011.! TP

Hello,

Using Module 01 configuration the dialed number analyzer is not showing the correct routing with 9011.! translation pattern.

With this dial plan it should hit the TP then get routed to RL_PSTN. The call still seems to be routed correctly through the phones and CUCM though.

In the incorrect DNA, why doesn't it hit the 9011.! TP?

The fixed number TP 9.[2-9]XX[2-9]XXXXXX is analyzed correctly.

 

E.g.: in both examples I am using 1002 (external phone number mask +1205501XXXX)

Incorrect DNA: on 9011.! (Seattle to Netherlands - International call)


  • Results Summary

    • Calling Party Information

      • Calling Party
        = 1002

      • Partition
        = PT_INTERNAL-DNs

      • Device CSS
        = CSS_DIAL-US-PSTN-International

      • Line CSS
        =

      • AAR Group Name
        =

      • AAR CSS
        =

    • Dialed Digits
      = 901131107047444

    • Match Result
      = RouteThisPattern

    • Matched Pattern Information

      • Pattern
        = 9011.!

      • Partition
        = PT_DIAL-US-PSTN-International

      • Time Schedule
        =

    • Called Party Number
      = 901131107047444

    • Time Zone
      = Pacific Standard/Daylight Time

    • Call Classification
      = OnNet

    • InterDigit Timeout
      = NO

    • Device Override
      = Disabled

    • Outside Dial Tone
      = NO

  • Call Flow

    • TranslationPattern :Pattern=

      • Positional Match List =

      • Calling Party Number = 1002

      • PreTransform Calling Party Number =

      • PreTransform Called Party Number =

      • Calling Party Transformations

        • External Phone Number Mask = NO

        • Calling Party Mask =

        • Prefix =

        • CallingLineId Presentation =

        • CallingName Presentation =

        • Calling Party Number = 1002

      • ConnectedParty Transformations

        • ConnectedLineId Presentation =

        • ConnectedName Presentation =

      • Called Party Transformations

        • Called Party Mask =

        • Discard Digits Instruction =

        • Prefix =

        • Called Number =

  • Alternate Matches

    • Note: Information Not Available



NOTE: The analysis results are purely based on configurations
available in the Cisco Communications Manager database. For Gateway
outbound calls, call details might differ depending on the Gateway's
settings.

 

Correct DNA: on 9.[2-9]XX[2-9]XXXXXX (Seattle to Seattle - subscriber call)


  • Results Summary

    • Calling Party Information

      • Calling Party
        = 2065011002

      • Partition
        = PT_INTERNAL-DNs

      • Device CSS
        = CSS_DIAL-US-PSTN-International

      • Line CSS
        =

      • AAR Group Name
        =

      • AAR CSS
        =

    • Dialed Digits
      = 92055015111

    • Match Result
      = RouteThisPattern

    • Matched Pattern Information

      • Pattern
        = +!

      • Partition
        = PT_TP-to-RP-PSTN

      • Time Schedule
        =

    • Called Party Number
      = +12055015111

    • Time Zone
      = Pacific Standard/Daylight Time

    • End Device
      = RL_PSTN

    • Call Classification
      = OffNet

    • InterDigit Timeout
      = NO

    • Device Override
      = Disabled

    • Outside Dial Tone
      = NO

  • Call Flow

    • TranslationPattern :Pattern= 9.[2-9]XX[2-9]XXXXXX

      • Positional Match List = +12055015111

      • Calling Party Number = 2065011002

      • PreTransform Calling Party Number = 1002

      • PreTransform Called Party Number = 92055015111

      • Calling Party Transformations

        • External Phone Number Mask = YES

        • Calling Party Mask = XXXXXXXXXX

        • Prefix =

        • CallingLineId Presentation = Default

        • CallingName Presentation = Default

        • Calling Party Number = 2065011002

      • ConnectedParty Transformations

        • ConnectedLineId Presentation = Default

        • ConnectedName Presentation = Default

      • Called Party Transformations

        • Called Party Mask =

        • Discard Digits Instruction = PreDot

        • Prefix = +1

        • Called Number = +12055015111

    • Route Pattern :Pattern= +!

      • Positional Match List = +12055015111

      • DialPlan =

      • Route Filter

        • Filter Name =

        • Filter Clause =

      • Require Forced Authorization Code = No

      • Authorization Level = 0

      • Require Client Matter Code = No

      • Call Classification =

      • PreTransform Calling Party Number = 2065011002

      • PreTransform Called Party Number = +12055015111

      • Calling Party Transformations

        • External Phone Number Mask = NO

        • Calling Party Mask =

        • Prefix =

        • CallingLineId Presentation = Default

        • CallingName Presentation = Default

        • Calling Party Number = 2065011002

      • ConnectedParty Transformations

        • ConnectedLineId Presentation = Default

        • ConnectedName Presentation = Default

      • Called Party Transformations

        • Called Party Mask =

        • Discard Digits Instruction = None

        • Prefix =

        • Called Number = +12055015111

    • Route List :Route List Name= RL_PSTN

      • RouteGroup :RouteGroup Name= Standard Local Route Group

        • PreTransform Calling Party Number = 2065011002

        • PreTransform Called Party Number = +12055015111

        • Calling Party Transformations

          • External Phone Number Mask = Default

          • Calling Party Mask =

          • Prefix =

          • Calling Party Number = 2065011002

        • Called Party Transformations

          • Called Party Mask =

          • Discard Digits Instructions =

          • Prefix =

          • Called Number = +12055015111

  • Alternate Matches

    • Note: Information Not Available



NOTE: The analysis results are purely based on configurations
available in the Cisco Communications Manager database. For Gateway
outbound calls, call details might differ depending on the Gateway's
settings.

 

 

 

Comments

  • Mustang;

         One interesting thing that I am seeing here is this section:

    Call Classification
    = OnNet

         If this is going to a RL, shouldn't this say "OffNet" if it is supposed to route to an RL?

  • Yes - that's weird - but in the case of 9.1[2-9]XX[2-9]XXXXXX (long distance) the call hits the TP

    is routed out  and changed to Off-Net.

    However in the case of 9011.!  the TP is missed entirely.

    (Well, in the actual setup the CorpHQ phone is able to call the PSTN phone so CUCM must be doing the right

    thing at the backend. I am just curious why DNA does not catch the 9011.! TP)

     

    The DNA results look totally off in the case of the international TP.

    More weirdness:  with TP 9011.!# the correct behaviour is observed and note it matches 9011.! as alternate:


    • Results Summary

      • Calling Party Information

        • Calling Party
          = 2065011002

        • Partition
          = PT_INTERNAL-DNs

        • Device CSS
          = CSS_DIAL-US-PSTN-International

        • Line CSS
          =

        • AAR Group Name
          =

        • AAR CSS
          =

      • Dialed Digits
        = 901131107047444#

      • Match Result
        = BlockThisPattern

      • Called Party Number
        =

      • Matched Pattern Information

        • Pattern
          =

        • Partition
          =

      • Pattern Type
        =

      • Time Zone
        =

      • Outside Dial Tone
        = NO

    • Call Flow

      • TranslationPattern :Pattern= 9011.!#

        • Positional Match List =

        • Calling Party Number = 2065011002

        • PreTransform Calling Party Number = 1002

        • PreTransform Called Party Number = 901131107047444#

        • Calling Party Transformations

          • External Phone Number Mask = YES

          • Calling Party Mask = XXXXXXXXXX

          • Prefix =

          • CallingLineId Presentation = Default

          • CallingName Presentation = Default

          • Calling Party Number = 2065011002

        • ConnectedParty Transformations

          • ConnectedLineId Presentation = Default

          • ConnectedName Presentation = Default

        • Called Party Transformations

          • Called Party Mask =

          • Discard Digits Instruction = PreDot

          • Prefix = +

          • Called Number = +31107047444#

    • Alternate Matches

      • Partition :Name= PT_DIAL-US-PSTN-International

        • Pattern

          • Pattern = 9011.!

          • Pattern Type = Translation

          • TranslationPartition = [ba1bf031-c0aa-1f37-c3e4-a27ce37a16b2]

          • CallManager Device Type = AccessDevice

          • PatternPrecedenceLevel = ExecutiveOverride

      • Partition :Name= PT_TP-to-RP-PSTN

        • Pattern

          • Pattern = +!

          • Pattern Type = Enterprise

          • Call Classification = OffNet

          • Pattern Priority = Urgent

          • CallManager Device Type = AccessDevice

          • PatternPrecedenceLevel = ExecutiveOverride
  • Mustang;

         Is this a real world example or is this out of the lab?  If this is in the lab, i would like to try and reproduce it.  If it is from a lab, can you tell me which lab, which workbook?  Thanks!

  • Its module 1 of workbook vol 1

  • DNA works if "Urgent Priority" is checked under TP "9011.!" but then keypad dialing does not work [:(]

     

    What is the recommended configuration with overlapping and variable length TPs:  "9011.!#" and "9011.!"? To check or uncheck "Urgent Priority". The latter seems to be the Cisco recommended way but then DNA works funny.

    "If the dial plan contains overlapping patterns, Cisco Unified
    Communications Manager does not route the call until the interdigit
    timer expires (even if it is possible to dial a sequence of digits to
    choose a current match). Check this check box to interrupt interdigit
    timing when Cisco Unified Communications Manager must route a call
    immediately.


    Tip : By default, the Urgent Priority check box displays as
    checked.Unless your dial plan contains overlapping patterns or
    variable length patterns that contain !, Cisco recommends that
    you do not uncheck the check box."

  • Hi Mustang,

     

    What you are experiencing is completely normal, and for dialing you certainly do not want UP checked. Allow me to explain.

     

    First off, the "!" is saying that the pattern needs "1 or more digits between 0-9" (but not * or #) to make a match. This "!" also means that the only indication that the end of the dialing string has been reached will be the interdigit timeout value (Service Params T302 value). This is the very reason for the duplicate pattern with the trailing #. 

    So, IF you were to check the box for UP, then here is the logic that applies: The digit analysis engine sees the user dial 9, 0, 1, 1 and then any other single digit between 0-9, and since the logic for the "!" that we just discussed states "1 or more digits" - well ONE digit has been met, and therefore the minimum criteria has been met, and the UP checkbox tells the digit analysis engine that "As soon as the minimum criteria has been met to match this pattern (where UP is checked), then STOP looking for any other matches and go directly to routing the call according to this pattern. 

    So now onto the topic of DNA vs User Dialing. The DNA utility doesn't have the ability to "wait for interdigit timeout", so without UP checked, it fails to match that pattern (because it can't wait!). However with UP checked, it matches that pattern just fine (and it matches all of the digits, not just the 'next' digit after 9011, and this is because of how it sends the digits to the digit analysis engine - which is something called "en-bloc" or "all-at-once" vs what user dialing would be which is "overlap sending" or "one-digit-at-a-time" - and in fact this is the entire reason for the trouble you're experiencing in the first place). However, with the fact that the user dialing is  "overlap sending" or "one-digit-at-a-time" - when you try to dial this pattern from a SCCP or SIP phone (well, SIP phone with KPML at least), this is the very reason why it goes to try to route the call after the user dials 9, 0, 1, 1 and then any other single digit between 0-9, and you end up hearing reorder tone. 

     

    Hope this makes sense and helps to clear up things a bit!

    -Mark







  • Thanks - wonderfully clear explanation.

    One more question on the Module 01 configuration (and Module 02) - 

    The 9011.!# pattern does not have Trailing-# discard at the gateway - would you have expected dialing to work?

    I couldn't get it to work without changing the Called Party Transformation at the gateway/endpoint to PreDot-Trailing#.

    Now this may have been because I was mucking in my CUCM pub during the DNA saga but I was getting reorder until I changed the Discard behaviour.

    I can confirm non-# dialing with timeout worked.

  • That 9011.!# translation pattern should have that DiscardDigit: PreDot Trailing# there in the translation pattern Called Party Transformation settings. 



    Kind Regards,

    Mark Snow, CCIE #14073
    (Voice, Security)
    Instructor
    Internetwork Expert, Inc.
    INE Online Community
    INE Blog
    LinkedIn
    Toll Free: 877-224-8987
    Outside US: +1 775 826 4344

    - docendo discitur





    On Aug 22, 2011, at 17:09, mustang7071 <[email protected]> wrote:

    Thanks - wonderfully clear explanation.

    One more question on the Module 01 configuration (and Module 02) - 

    The 9011.!# pattern does not have Trailing-# discard at the gateway - would you have expected dialing to work?

    I couldn't get it to work without changing the Called Party Transformation at the gateway/endpoint to PreDot-Trailing#.

    Now this may have been because I was mucking in my CUCM pub during the DNA saga but I was getting reorder until I changed the Discard behaviour.

    I can confirm non-# dialing with timeout worked.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Mark;

         Thank you very much!  That explanation was GREAT!  I have seen that in the past in production, and just always assumed that DNA was flaking out.

Sign In or Register to comment.