First and foremost - I did a search on this community for some basic keywords to find if anyone had run into this. Not the best of all search results in this forum. Liked the other forum better. Anyway onto the issue.

Example Dialed number for me:
678-212-1234

Expected results:
Not a DID and no profile defined for this number. Previous tests routed the call to the default attendant profile and was handled as expected.

Action:
Added several customer profiles for incoming numbers. All of which were single number profiles except one. The "problem profile" had ranges used vs. static direct numbers. 

Problem:
Profile with ranges in it caught our example number even though the example number was in no way a match to any range. Example of ranges as compared to the example number.

5037331000-503733199, 5037351000-5037356999

No where is there a match in those 2 ranges defined in the profile, yet it catches our example number. Looking through the IP log I can see that all profiles were no match. However once it went through the DNIS match and failed I see it attempt a "Range match" and finds a match which is the faulty profile. However I don't understand the matching numbers used. Below in the example I have no relation to the number 2147483647. That is not a real number associated with that call as far as I can tell.

CAttendantProfile::match_for_range : Range match found with (2147483647), (2147483647) for 2147483647

After it makes that match the next steps are the processing of that problem profile and sending the call through that flow which is wrong.

Anyone have an issue with mis-routing in attendant or issue using ranges in attendant?

Thanks all,
Nate

First question - are you sure it's matching on DNIS and not on ANI? (Since the numbers are nowhere close).

My first tactic is always to publish Attendant again to make sure nothing is cached and didn't get published properly.

Another tactic I use is to put the attendant handlers in Debug mode (usually starting with InteractionAttendantEntryPoint until I decide on a better one) to see what is actually being passed through the handlers for ANI and DNIS and such. Do it during off hours if you have to test on the production system so you're not debugging customer calls.

------------------------------
George Ganahl
Principal Program Manager
Genesys
------------------------------

Original Message:
Sent: 06-22-2018 16:48
From: Nathaniel Bennett
Subject: Attendant wrong profile being picked

First and foremost - I did a search on this community for some basic keywords to find if anyone had run into this. Not the best of all search results in this forum. Liked the other forum better. Anyway onto the issue.

Example Dialed number for me:
678-212-1234

Expected results:
Not a DID and no profile defined for this number. Previous tests routed the call to the default attendant profile and was handled as expected.

Action:
Added several customer profiles for incoming numbers. All of which were single number profiles except one. The "problem profile" had ranges used vs. static direct numbers.

Problem:
Profile with ranges in it caught our example number even though the example number was in no way a match to any range. Example of ranges as compared to the example number.

5037331000-503733199, 5037351000-5037356999

No where is there a match in those 2 ranges defined in the profile, yet it catches our example number. Looking through the IP log I can see that all profiles were no match. However once it went through the DNIS match and failed I see it attempt a "Range match" and finds a match which is the faulty profile. However I don't understand the matching numbers used. Below in the example I have no relation to the number 2147483647. That is not a real number associated with that call as far as I can tell.

CAttendantProfile::match_for_range : Range match found with (2147483647), (2147483647) for 2147483647

After it makes that match the next steps are the processing of that problem profile and sending the call through that flow which is wrong.

Anyone have an issue with mis-routing in attendant or issue using ranges in attendant?

Thanks all,
Nate

Thanks for the response. 

I have republished and deleted the profile and re-added it to insure there was no "copy" profile issues. All done with manual entry. Digging deeper this actually affected more than just one number. I will trace the handlers in off hours since we are in mid production day right now. The logs clearly show the number not matching on the DNIS search. You then see a Range search performed and hit the stated problem profile. Again not being anything close to a match. 

To me it is almost like it took over the default profile that is the catch all. For now we have deactivated it and back to a working state.

------------------------------
Nathaniel Bennett
------------------------------

Original Message:
Sent: 06-22-2018 17:05
From: George Ganahl
Subject: Attendant wrong profile being picked

First question - are you sure it's matching on DNIS and not on ANI? (Since the numbers are nowhere close).

My first tactic is always to publish Attendant again to make sure nothing is cached and didn't get published properly.

Another tactic I use is to put the attendant handlers in Debug mode (usually starting with InteractionAttendantEntryPoint until I decide on a better one) to see what is actually being passed through the handlers for ANI and DNIS and such. Do it during off hours if you have to test on the production system so you're not debugging customer calls.

------------------------------
George Ganahl
Principal Program Manager
Genesys

Original Message:
Sent: 06-22-2018 16:48
From: Nathaniel Bennett
Subject: Attendant wrong profile being picked

First and foremost - I did a search on this community for some basic keywords to find if anyone had run into this. Not the best of all search results in this forum. Liked the other forum better. Anyway onto the issue.

Example Dialed number for me:
678-212-1234

Expected results:
Not a DID and no profile defined for this number. Previous tests routed the call to the default attendant profile and was handled as expected.

Action:
Added several customer profiles for incoming numbers. All of which were single number profiles except one. The "problem profile" had ranges used vs. static direct numbers.

Problem:
Profile with ranges in it caught our example number even though the example number was in no way a match to any range. Example of ranges as compared to the example number.

5037331000-503733199, 5037351000-5037356999

No where is there a match in those 2 ranges defined in the profile, yet it catches our example number. Looking through the IP log I can see that all profiles were no match. However once it went through the DNIS match and failed I see it attempt a "Range match" and finds a match which is the faulty profile. However I don't understand the matching numbers used. Below in the example I have no relation to the number 2147483647. That is not a real number associated with that call as far as I can tell.

CAttendantProfile::match_for_range : Range match found with (2147483647), (2147483647) for 2147483647

After it makes that match the next steps are the processing of that problem profile and sending the call through that flow which is wrong.

Anyone have an issue with mis-routing in attendant or issue using ranges in attendant?

Thanks all,
Nate

What version of CIC are you running? Somewhere in the early 20XX version numbers Genesys changed DNIS comparison from String to Integer. If the phone number is greater than 214-748-3647 you are going to overflow and take the route that matches this phone number range. There is a server parameter you can add to the system "UseDNISStringComparison"  Description "This will allow the system to analyze DNISs as strings and not integers. 1 = Enable, 0 or delete = disable or do DNIS comparison via Integer".

------------------------------
Mark Tatera
ConvergeOne

Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.
------------------------------

Original Message:
Sent: 06-22-2018 17:52
From: Nathaniel Bennett
Subject: Attendant wrong profile being picked

Thanks for the response.

I have republished and deleted the profile and re-added it to insure there was no "copy" profile issues. All done with manual entry. Digging deeper this actually affected more than just one number. I will trace the handlers in off hours since we are in mid production day right now. The logs clearly show the number not matching on the DNIS search. You then see a Range search performed and hit the stated problem profile. Again not being anything close to a match.

To me it is almost like it took over the default profile that is the catch all. For now we have deactivated it and back to a working state.

------------------------------
Nathaniel Bennett

Original Message:
Sent: 06-22-2018 17:05
From: George Ganahl
Subject: Attendant wrong profile being picked

First question - are you sure it's matching on DNIS and not on ANI? (Since the numbers are nowhere close).

My first tactic is always to publish Attendant again to make sure nothing is cached and didn't get published properly.

Another tactic I use is to put the attendant handlers in Debug mode (usually starting with InteractionAttendantEntryPoint until I decide on a better one) to see what is actually being passed through the handlers for ANI and DNIS and such. Do it during off hours if you have to test on the production system so you're not debugging customer calls.

------------------------------
George Ganahl
Principal Program Manager
Genesys

Original Message:
Sent: 06-22-2018 16:48
From: Nathaniel Bennett
Subject: Attendant wrong profile being picked

First and foremost - I did a search on this community for some basic keywords to find if anyone had run into this. Not the best of all search results in this forum. Liked the other forum better. Anyway onto the issue.

Example Dialed number for me:
678-212-1234

Expected results:
Not a DID and no profile defined for this number. Previous tests routed the call to the default attendant profile and was handled as expected.

Action:
Added several customer profiles for incoming numbers. All of which were single number profiles except one. The "problem profile" had ranges used vs. static direct numbers.

Problem:
Profile with ranges in it caught our example number even though the example number was in no way a match to any range. Example of ranges as compared to the example number.

5037331000-503733199, 5037351000-5037356999

No where is there a match in those 2 ranges defined in the profile, yet it catches our example number. Looking through the IP log I can see that all profiles were no match. However once it went through the DNIS match and failed I see it attempt a "Range match" and finds a match which is the faulty profile. However I don't understand the matching numbers used. Below in the example I have no relation to the number 2147483647. That is not a real number associated with that call as far as I can tell.

CAttendantProfile::match_for_range : Range match found with (2147483647), (2147483647) for 2147483647

After it makes that match the next steps are the processing of that problem profile and sending the call through that flow which is wrong.

Anyone have an issue with mis-routing in attendant or issue using ranges in attendant?

Thanks all,
Nate