ARS table in SIP deskphone

[fabiopmoura]

Hello guys,

After I updated the servers of a customer last month, He have trouble making calls to some numbers through the SIP extensions. I realized that SIP devices loading the ARS table of CM when are restarted, the ARS table in CM there similar numbers. Example:

Dialed Total Route Call Node ANI
String Min Max Pattern Type Number Req

1 3 8 p1 natl n
2 7 8 p1 natl n
248 7 7 8 natl n

The problem is when the client tries to make a call to the number 24839400 through SIP extensions the deskphones end dialing in 7 digits. See traceSM note that the extension sends the INVITE missing a number.

Note: In the other stations (H323, analog and digital) the call is made normally. In softphone is works


7043 SM CM

17:22:15.856 | |--Not Fou->| | (8) 404 Not Found (No route available)
17:22:21.150 |--INVITE-->| | | (7) T:02483940 F:7043 U:02483940
17:22:21.151 |<--Trying--| | | (7) 100 Trying
17:22:21.151 |<--Proxy A-| | | (7) 407 Proxy Authentication Required
17:22:21.163 |----ACK--->| | | (7) sip:02483940@unimedrj.root
17:22:21.204 |--INVITE-->| | | (7) T:02483940 F:7043 U:02483940
17:22:21.205 |<--Trying--| | | (7) 100 Trying
17:22:21.207 | |--INVITE-->| | (7) T:02483940 F:7043 U:02483940 P:imsorig
17:22:21.208 | |<--Address-| | (7) 484 Address Incomplete
17:22:21.209 | |----ACK--->| | (139) sip:7043@unimedrj.root
17:22:21.210 |<--Address-| | | (7) 484 Address Incomplete
17:22:21.212 | |<--PUBLISH-| | (19) sip:2135207043@unimedrj.root
17:22:21.213 | |--Not Fou->| | (19) 404 Not Found (No route available)
17:22:21.247 |----ACK--->| | | (7) sip:7043@unimedrj.root
17:22:21.408 | |<--Trying--| | (7) 100 Trying
17:22:21.408 | |<--Address-| | (7) 484 Address Incomplete
17:22:21.449 | |----ACK--->| | (7) sip:02483940@unimedrj.root
17:22:21.450 |<--Address-| | | (7) 484 Address Incomplete
17:22:21.458 |----ACK--->| | | (7) sip:02483940@unimedrj.root
17:23:29.608 |--REGISTE->| | | (80) <sip:7043@unimedrj.root> Exp:900
17:23:29.610 |<--Unautho-| | | (80) 401 Unauthorized
17:23:29.619 |--REGISTE->| | | (80) <sip:7043@unimedrj.root> Exp:900
17:23:29.621 |<--200 OK--| | | (80) 200 OK (REGISTER)
17:23:29.621 |<--NOTIFY--| | | (81) <sip:7043@unimedrj.root> Ev:reg
17:23:29.638 |--200 OK-->| | | (81) 200 OK (NOTIFY)

 

[ZeroZeroOne]

I would first look at the ARS analysis for dial patterns beginning with zero since it looks like the dial string is "0 24839400" for 9 digits. The SIP invite "02483940@unimedrj.root" is getting truncated and missing the last digit.

 

[fabiopmoura]

Hi 001!

In Brazil is

Auto Route Selection (ARS) - Access Code 1: 0

The customer wants call the 0 24839400

 

[kyle555]

OK.

This can get deep! So, SMGR syncs CM. SMGR pushes that database to SM. SM processes it again and builds PPM for SIP AST devices. The devices get the PPM again and massage it into their dialplan. UDP, ARS, all sorts of things work in there - so if your ARS fac is *99, you'll see all sorts of entries beginning with *99 in the PPM even if your stations always dial UDP to ARS.

Now, depending what versions of firmware, SM, 96x0 and 96x1 you have, that can all change too.

Isn't sip fun?

Read this:

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

Anyways, look at the PPM flow to the phone in a traceSM (that's with a "reload complete" in user registrations in SMGR) and you'll see the dial plan that gets pushed to the phone. See if the string where the phone terminated dialing without the last 0 matched an entry in that PPM dialplan to be an absolute match that couldn't possibly match other longer strings.

I've had problems with the inverse where I had to more explicitly define certain numbers of shorter lengths so the phone wouldn't wait a long time for a digit timeout before sending out the invite because other, longer entries in it's dial plan could have been dialed to match those longer patterns as well.

 

[ZeroZeroOne]

Ah. 0 and 00 are local and long distance codes in several countries.

What version of System, Session, and Communication Manager are you running now?
What type of SIP phones are you using?

If Session Manager is saying "no route found" let's look at that.
Are the SIP endpoints registering correctly to Session Manager? In System Manager, go to Session Manager / System Status / User Registrations.
Check the Communication Profiles for the SIP Endpoints. Are the Origination and Termination Sequences pointing to CM?

Is there a Dial Pattern or Regular Expression to send digits from Session Manager to Communication Manager?
Under Session Manager / System Tools / Call Routing Test, Do you get any successful results when running the test?


These are just some questions to get you started. I hope it helps.

 

[fabiopmoura]

Helo Kyle555,

see the image...

the customer wants to make a call to the number 24839400 in the string 2 to rout p1, but the extension does not send the 8 digits and the CM receives only 7 digits and routes the call to the Route 8 wrong

 

[fabiopmoura]

No 001 here in Brazil is "0" ARS access code

 

[jtc22]

What trunks do you are using calling out? PRI, analog, or SIP?

 

[kyle555]

Yes. See my previous comment about looking at PPM dialplans that are sent to the phone.

In H323, CM processes every digit and processes every digit according to ARS/UDP, etc.

In SIP, the SIP telephone receives the dial plan from Session Manager in PPM - so, do a traceSM and filter on PPM for the extension in question (start the trace with PPM only, and press 'f' to filter and type '-u 1234' to filter on extension 1234 - and don't enter the ' quotation marks). Then, go in System Manager, in "Session Manager" and in "System Status" and "User Registrations" and find the phone you're dealing with and "Reload Complete" - that should sent all PPM to the phone and it should appear in your traceSM. One of the elements sent in PPM from SM to the phone will include the dial plan Session Manager made for the telephone and include all the strings the phone processes before sending anything to CM. I think you at least need to start checking there to make sure that the dial plan sent to the phone doesn't include a match to a "complete" string of 02483940 instead of 024839400.

Perhaps the per-location ARS tables matter too. Are you using a multi-location dial plan in CM?

 

[fabiopmoura]

Kyle555,

I know you understand my problem. I thank you for your help.

is only one location (Multiple Locations feature not assigned)

I'm checking what you asked and soon I will publish the result.

 

[fabiopmoura]

Kyle555,

this is the table downloaded by the device during the PPM reload, but the ARS setting in the CM is this:

CM ARS:
Dialed String Location Min Max Route Pat Call Type Node Number
0 all 11 13 p2 natl
00 all 13 16 p3 natl
023 all 7 7 8 locl
0300 all 9 13 9 natl
038 all 7 7 8 locl
052 all 7 7 8 locl
054 all 7 7 8 locl
077 all 7 7 8 locl
0800 all 10 11 p1 natl
08005700100 all 11 11 p1 natl
08023121xxxx all 12 13 p1 natl
0900 all 9 10 p1 natl
0xxxx9 all 14 14 p2 natl
1 all 3 8 p1 natl
1 all 11 13 6 natl
121 all 11 11 7 locl
125 all 7 7 8 locl
126 all 7 7 8 locl
179 all 7 7 8 locl
180 all 7 7 8 locl
2 all 7 8 p1 natl
205 all 7 7 8 locl
21118300 all 8 8 41 locl
21118325 all 8 8 41 locl
231 all 7 7 8 locl
247 all 7 7 8 locl
248 all 7 7 8 locl
269 all 7 7 8 locl
276 all 7 7 8 locl
290 all 7 7 8 locl
296 all 7 7 8 locl
3 all 7 8 p1 natl


Table in PPM reload
15:4| <item>0Z1xxxxxxx</item> |
15:4| <item>0Z1xxxxxxxxxx</item> |
15:4| <item>0Z1xxxxxxxxxxx</item> |
15:4| <item>0Z1xxxxxxxxxxxx</item> |
15:4| <item>0Z205xxxx</item> |
15:4| <item>0Z21118300</item> |
| <item>0Z21118325</item> |
| <item>0Z231xxxx</item> |
| <item>0Z247xxxx</item> |
| <item>0Z248xxxx</item> |
| <item>0Z269xxxx</item> |
| <item>0Z276xxxx</item> |
| <item>0Z290xxxx</item> |
| <item>0Z296xxxx</item> |
| <item>0Z2xxxxxx</item> |
| <item>0Z2xxxxxxx</item> |
| <item>0Z312xxxx</item> |
| <item>0Z341xxxx</item> |
| <item>0Z35121215</item> |
| <item>0Z3xxxxxx</item> |
| <item>0Z3xxxxxxx</item> |
| <item>0Z4xxxxxx</item> |
| <item>0Z4xxxxxxx</item> |
| <item>0Z5xxxxxx</item> |
| <item>0Z5xxxxxxx</item> |
| <item>0Z6xxxxxx</item> |
| <item>0Z6xxxxxxx</item> |
| <item>0Z7xxxxxx</item> |
| <item>0Z7xxxxxxx</item> |
| <item>0Z8011</item> |
| <item>0Z8898xxxx</item> |
| <item>0Z8xxxxxx</item> |
| <item>0Z8xxxxxxx</item> |
| <item>0Z90xxxxxxxxxx</item> |
| <item>0Z90xxxxxxxxxxx</item> |
| <item>0Z90xxxxxxxxxxxx</item> |
| <item>0Z921xxxxxxxx</item> |
| <item>0Z9306</item> |
| <item>0Z976997037</item> |
| <item>0Z98420598x</item> |

 

[kyle555]

You have a more exact match of 248 min/max 7/7 than your match of 2 min/max 7/8. That's why you're getting shut down.

 

[fabiopmoura]

Kyle555,

Yes, but the routes are different. The string 2 7/8 are local calls and the string 248 7/7 has another route "8". When the customer calls 24839400 he should calling the string 2 7/8 P1.

Note: in h323, analog and digital extensions is work

 

[fabiopmoura]

Kyle555,

I believe that when we update the SM, CM and SMGR last month, some setting has been changed to determine the speed dial the number. I believe that if there is a delay in devices SIP, it will identify what I want to make a call of 8 digits and will route the call to the string 2 8/8 routing for P1

 

[kyle555]

http://support.avaya.com/css/P8/documents/101014573

Read the part about higher precedence to specific patterns. Of course it doesn't work the same as H323 phones. That would be too easy.

 

[fabiopmoura]

Damn, but it worked before the update, as I will explain this to the client? :-(

Thank you for your help!

 

[kyle555]

What update did you do?

Read chapter 7 of this doc:

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

It explains what changed when

 

[fabiopmoura]

Kyle555,

It became very clear explanation of the manual!

thank you my friend!!!

You are the man!