Session Manager PPM and dialplan 2

[OlegPowerC]

Hi!. My SIP ext is 208 and H.323 ext is 250 and Cisco phone behind CUCM is 700
When I call 250 - phone 250 ringing immediately, but all other whait interdigit timeout (or I can press #).
It is may be because SIP phone can not get dialplan by PPM.
I trace ppm and not see any getDialPlan requests.
May be I must do anything on session manager?
Thank You!

 

[kyle555]

It's in getAllEndpointConfigurationResponse

It's made up of what's in dialplan analysis, AAR, ARS, etc

If your CM is sync'd to SMGR properly, then SMGR replicates the data to SM. SM crunches that CM config into dialable strings for your phone so your phone knows when it's finished dialing.

If you're on 96x1s and on later loads of 6.3 or higher, you don't need to worry about all the details in the PPM whitepaper, but it's excellent reading.

https://downloads.avaya.com/css/P8/documents/101014573

https://downloads.avaya.com/css/P8/documents/100182873

 

[OlegPowerC]

Thank You very mutch!
Can I modify this:
In dialplan i have:

In the aar analisys:

PPM generate:

300+ and 8Z300
Why 300+?
in dialplan i have minimum and maximum 3
H.323 phone work as expected

 

[kyle555]

H323 works the way you expect because CM analyzes every digit. Once you dial something that can have no further specific match, it stops.

So, if you had 1900, min/max 11 as DENY in ARS and 1 min max 11 as allow, you would allow calls to any 11 digit number starting with a 1 unless it starts with 1900.

If you dialed the ARS code - 9 for example - from a H323 phone and then 1900, CM would stop you right there. It knows there is no further possible thing you could dial that would be legal.

PPM dial plans show you only what you CAN dial, not what you CAN NOT. So, having those 2 entries would get you PPM like
9Z1xxxxxxxxxx

PPM has no concept of "illegal" numbers - so there's no FORBID-9Z1900

And it's not going to make more complicated PPM to express the impossibility of dialing 1900 like this:
9Z11xxxxxxxxxx
9Z12xxxxxxxxxx
9Z13xxxxxxxxxx
9Z14xxxxxxxxxx
9Z15xxxxxxxxxx
9Z16xxxxxxxxxx
9Z17xxxxxxxxxx
9Z18xxxxxxxxxx
9Z1901xxxxxxxxx
9Z1902xxxxxxxxx
9Z1903xxxxxxxxx
9Z1904xxxxxxxxx
9Z1905xxxxxxxxx
9Z1906xxxxxxxxx
9Z1907xxxxxxxxx
9Z1908xxxxxxxxx
9Z1909xxxxxxxxx

But, if you actually had those entries in your ARS, then you would actually see PPM of that nature so your phone would stop after dialing 91900 just like a H323

Looking at your dialplan analysis - anything starting with 2 has to be 3 digits, it's an extension and can't go anywhere else.

https://downloads.avaya.com/css/P8/documents/101014573

p198 says you need to enable AAR/ARS dialing without FAC to use strings in the dialplan analysis table of type aar

We usually don't use AAR in the dialplan analysis table - at least on all the systems I've seen. You'd typically use UDP or EXT and in change dialplan parameters you can set CM to look at strings as being in EXT before UDP or UDP before EXT

So, if you had 7, length 3, go to UDP and in change uni 0 you made string 7 length 3 go to AAR, you'd probably not have PPM 7xx+


Remember to initialize sync from SMGR - not incremental - anytime you change anything in dialplan analysis. That takes a whole new database sync to build PPM again.

 

[OlegPowerC]

Thank You very mutch! I change 3xx -> AAR to EXT and add in UDP 3xx->AAR and now in PPM i see next:
<item>#xx</item> │
<item>2xx</item> │
<item>3xx</item> │
<item>7xx</item>

 

[kyle555]

Yeah, now that I think about it, it's because AAR can have any number of digits.

So when you had 7, length 3, aar in dialplan analysis, it is then known that anything at least 3 digit, starting with 7 will go to AAR

In AAR you can have strings 7xx, 7xxx, 7xxxxxxxxxxx etc, so dialplan analysis doesn't know what the complete length of string will be, that's why you get 7xx+. You did get the AAR table in your PPM, so if you had dialed 8700, you'd have gone right away whereas with 700 you'd wait for the timeout.

PPM is always going to start with every phone with a base of what's in dialplan analysis. That 7xx+ wasn't going to change or adapt if you made strings with length 7xxxxxx in the AAR table.

I learned something. I never have used ARS or AAR in the dialplan analysis table, but now I know why