AVAYA - Incoming Call Route / Caller ID issues 1

[cj26]

Hello all,

I am having an issue with a customer who has ~50 users and wants the sales personnel to have their DID show as Caller ID on external calls(607 111 2222 / 607 111 2223 / etc), while having all of the rest of the employees show the main number(607 111 1111).

SIP service with using "Internal Data," for all fields.

The issue I am running into is that if a users "SIP," tab is configured to use the main number (607 111 1111) then their DID that is assigned to an ICR will not work... So if somebody calls in trying to use that users DID to reach them directly, they just get a fast busy.

But as soon as I change the user "SIP," tab information back to their corresponding DID, it will work fine. This is great for the sales personnel but we want to show the main number for the rest of the employees... Not DIDs for everyone.

I am assuming there is some authentication type issues somewhere corresponding to the individual users "SIP," configuration and the ICR? Not sure though...

I have tried to search other treads for similar issues but have not found quite the same issue unfortunately.

If you need more information or a better explanation please feel free to ask, and any advice I am thankful for!

 

[janni78]

You need a SIP URI with all fields set to Auto (or "*") for routing via ICR.

If you only have a SIP URI with "Internal Data" then it will route incoming calls based on that as well.

"Trying is the first step to failure..." - Homer

 

[cj26]

You need a SIP URI with all fields set to Auto (or "*") for routing via ICR.

If you only have a SIP URI with "Internal Data" then it will route incoming calls based on that as well.

Thanks for that!

So to be clear.. is this how you would recommend to configure this: (See screenshot as well)
Channel 1 - incoming group (20) - Auto / Auto / Auto
Channel 2 - outgoing group (20) - Internal Data/ Internal Data / Internal Data

 

[janni78]

I usually have the same incoming ID on the URIs, it will still use ICR.

You can have a different Outgoing ID on the Auto URI so you can use that to set CLI with .s shortcode instead of using the SIP tab.

"Trying is the first step to failure..." - Homer

 

[cj26]

I usually have the same incoming ID on the URIs, it will still use ICR.

You can have a different Outgoing ID on the Auto URI so you can use that to set CLI with .s shortcode instead of using the SIP tab.

First, thank you for the fast responses Janni.

Second, just wanted to run this by you to see if this is what you were talking about? See screenshots below please. So I would just add that short code with the number the user will want to display for those who want a separate CID when dialing out?

Thanks again! Help is much appreciated!

 

[janni78]

Yes, but in that case you need to have a different Outgoing ID on the URI with Auto, otherwise it will use the one with Internal.

"Trying is the first step to failure..." - Homer

 

[cj26]

Yes, but in that case you need to have a different Outgoing ID on the URI with Auto, otherwise it will use the one with Internal.

So Janni - I have one more question for you.

I replicated this on my system R10.0.0.6.0 (Customer has R9.1.12)

My system I have the separate URI channels (Outgoing is using Internal Data for all fields / Incoming is using Auto|*)

My system it works great as it should, if I change a user config under "SIP," tab then it will display that for the CID going outbound, if i leave the user extension under the SIP tab (127 for example) then it shows the lead number.​

I replicated this on my customers IP Office and it works with the exception of the CID outbound. It will not show the lead number if entered, but for some reason if the users extension (242 for example) is entered in their SIP credentials like most users are by default, it will show that ( +1242) is the caller ID to the end party.. I dont really understand why it is happening this way. Kind of hitting a roadblock here.

The only differences I can see in the system are obviously R9.1 to R10 and where my ARS table is like "NS##########," his has "NSi##########," haven't had much exposure to the different characters you can enter into ARS and what they do so maybe that is playing an issue here?

Again, thanks for any help you can provide.

 

[cj26]

So,

I did some testing after hours last night. It seems to me that there is some kind of conflict between the ICR & the user SIP settings.
I can get it so the ICR works and the user displays their DID outbound on their calls which is great for some users as mentioned before.. But we would like 90% of people to display the lead number instead of a DID. I cant get their lead number to show no matter what I seem to do but if I take their user SIP settings out and default them, it shows their extension as caller ID which I don't quite understand.. Where if i replicate that on my system it works as it should.

 

[snowman50]

Hi Cj26
you have said.
"
I am having an issue with a customer who has ~50 users and wants the sales personnel to have their DID show as Caller ID on external calls(607 111 2222 / 607 111 2223 / etc), while having all of the rest of the employees show the main number(607 111 1111)."

"But as soon as I change the user "SIP," tab information back to their corresponding DID, it will work fine. This is great for the sales personnel but we want to show the main number for the rest of the employees... Not DIDs for everyone."

***** Why don't you put in the main number on the SIP TAB of the users that do not required there DDI to be sent out.****

thats what I normally do and it works for me...... .

 

[cj26]

Hi Cj26
you have said.
"
I am having an issue with a customer who has ~50 users and wants the sales personnel to have their DID show as Caller ID on external calls(607 111 2222 / 607 111 2223 / etc), while having all of the rest of the employees show the main number(607 111 1111)."

"But as soon as I change the user "SIP," tab information back to their corresponding DID, it will work fine. This is great for the sales personnel but we want to show the main number for the rest of the employees... Not DIDs for everyone."

***** Why don't you put in the main number on the SIP TAB of the users that do not required there DDI to be sent out.****

thats what I normally do and it works for me...... .

Hi Snowman,

So when I do that, the ICR for the user no longer works. So we would like it so their Incoming Call Route still works, but when they dial out it displays the lead number rather than their assigned DID. And then as mentioned before, if I leave the SIP tab for the user as default it will display their extension as Caller ID.

Also, This works as you mentioned on my system in house as that is how i have it set up... R10
But the customer (R9.1.12) when set up this way does not work.

 

[teletechman]

WE had this issue recently and created a user with the DID in its SIP tab but had the ICR going to the user who was using it. Then we put the main number to that user and all was happy.
Mike

 

[cj26]

WE had this issue recently and created a user with the DID in its SIP tab but had the ICR going to the user who was using it. Then we put the main number to that user and all was happy.
Mike

Mike, do you mind elaborating a little more on how you resolved your issue?

 

[janni78]

The Incoming ID should still be the same on both URIs as mentioned before, start with changing that.

"Trying is the first step to failure..." - Homer

 

[teletechman]

We just created phantom users to use for authenticating the SIP DID then pointed the ICR to the user we wanted. Kind of a round about way but it did work.
Mike

 

[janni78]

We just created phantom users to use for authenticating the SIP DID then pointed the ICR to the user we wanted. Kind of a round about way but it did work.

That's just a way to get around the SIP trunk not being configured correctly.
I don't get why they don't go through this in training, one of the most common issues I encounter on other systems.

"Trying is the first step to failure..." - Homer

 

[cj26]

That's just a way to get around the SIP trunk not being configured correctly.
I don't get why they don't go through this in training, one of the most common issues I encounter on other systems.

Unfortunately I never got instruction on SIP just was kind of thrown in and told to figure it out. Also this customer has 4 sites.. They had 2 already up and running (1 experiencing these problems) then the two that we deployed.

 

[teletechman]

I know this is not the right way just another way or work around for users to get things working.
Mike