Strange Twinning issue--caller ID coming up with incorrect exchange

[BCM400Noob]

On an Avaya IP Office v9.1

User on x714 calls another internal user on x995. x995 is twinned to their cell phone for when they are at their desk. When the twinned call arrives on the cell phone of user 995, the wrong number appears on the cell phone.

x714 uses exchange 878, our dominant DID exchange is 454. User shows up on twinned cell phone as 454-0714 instead of 898-0714, so naturally when the person on the cell phone calls back, it dials the wrong number.

Not sure what to look for as everything appears to be set up correctly on the 2 extensions and the 2 users.

Thanks.

 

[derfloh]

Can be caused by incoming call routing.

 

[nnaarrnn]

what happens when that same user just dials the cell phone of the other user?

 

[BCM400Noob]

Sorry for the delay in getting back.

When the user dials directly, the correct number appears on the cell phone.

I'll see what I can see under incoming call routing.

 

[BCM400Noob]

I don't see anything unexpected under internal call routing.

x714 has 898-0714 and x995 has 4540995 for the incoming number

 

[amriddle01]

When a twinned call is initiated it uses the settings of the user who received the call not the user making the call

 

[BCM400Noob]

In looking through the logs, I did find this:

09:08:53 3660633480mS CMARS: FORM: 9xx DID - Received Number: xxxxxx5545
09:08:53 3660633481mS CMARS: FOUND A SHORT CODE - short_code: N; [highlight #FCE94F]- Tel: Nsi2674540E[/highlight] - Called_Party: xxxxxx5545 - Line Group Id: 1
09:08:53 3660633481mS CMARS: SetCurrentTarget: Short_Code: N; - Line_Group_ID: 1
09:08:53 3660633481mS CMARS: FindActiveARSByGroupID GroupID=1 - Not Found
09:08:53 3660633481mS CMLRQ: FindActiveLRQByGroupID GroupID=1 - Not Found
09:08:53 3660633481mS CMCallEvt: 0000000000000000 0.76151.0 -1 BaseEP: NEW CMEndpoint f1720a60 TOTAL NOW=11 CALL_LIST=4
09:08:53 3660633482mS CMTARGET: ISDN BChannel 22: in-service check = 1
09:08:53 3660633482mS CMTARGET: ISDN BChannel 22: in-service check = 1
09:08:53 3660633483mS CMARS: ModifyCMARSTarget: Short_Code: N; - Line_Group_ID: 1 set line status to CMARS_TRYING
09:08:53 3660633483mS CMARS: FOUND LINE - Line Id: 1 - using line group id: 1 (code N;, line 1) - Called Number: 2158085545 - Calling Number: [highlight #FCE94F]xxx4540714[/highlight]

I've highlighted the relevant items where it appears it is getting the number to put together and send the ANI information, I'm just not clear how it got set up or how to remedy.

Thanks.

 

[teletechman]

In your ARS tables you will see the SC set up there. Or if they bypassed the ARS and went direct with a SC then look in SCs and you will see an entry with the Nsi267454. To fix this what are you trying to send, I have had to set up a dedicated SC and ARS table for twinned phones only to get them to see the incoming callerID.
Mike

 

[BCM400Noob]

Here are my ARS entries:

7xx DID:

Code Telephone Number Feature Line Group ID
1N; 1Nsixxx8980E Dial 1
N; Nsixxx8980E Dial 1

9xxDID:

1N; 1Nsixxx4540E Dial 1
N; Nsixxx4540E Dial 1

xxx above is our area code

 

[teletechman]

so when you twin it is using the 9xxDID ARS table probably by a SC, that is why you see those exchanges. What do you want sent, figure that out then fix it.
Mike

 

[derfloh]

Shouldn't the short code really matter? If you enable "sent original caller ID for twinned calls" under system settings the NSi part of the short code should be ignored.

 

[amriddle01]

That setting is related to direct calls to the user that are twinned not calls being transferred by another user, as I mentioned the call is initiated using the users who is twinned settings and so would try and send their caller ID not the caller ID of the person transferring

 

[teletechman]

That is what I am saying, the user calls a twinned ext, the twinned ext then has a number programmed for the twinnig feature. Here is the US it might look like 91234567890, with 9 being the access code for the PRI or SIP. The system then looks at the SCs and sees 9N to ARS table 9xxDID which has the 9xxDID: 1N; 1Nsixxx4540E Dial 1 N; Nsixxx4540E Dial 1 programmed the system then send the xxx4540714 as that is the ext calling from. I have a system that has 2 sets of DID blocks and need to make a separate SC entry for sending the DIDs with different exchanges out, I use user SCs to make that work.
Mike

 

[BCM400Noob]

I think teletechman has the situation pegged. It is an internal user who is calling the twinned extension and the system is simply trying to construct the number for caller ID to be sent and it is selecting the wrong exchange.

I'll poke around some more, but I think this is it.

Thank you.

 

[BCM400Noob]

Ok, looks like it is mostly set up correctly:

Short codes:

Code Feature Telephone number Line Group ID
*9xx Voicemail Collect "#"9N 0 (drop down option 52 9xx DID)
*7xx Voicemail Collect "#"9N 0 (drop down option 56 7xx DID)


Is it as simple as changing the Line Group ID to the corresponding drop down option? Naturally don't want to mess anything up. I do note that my Incoming Call Route does have 0 Line Group ID next to all my extensions, so not sure if they are associated with each other.

Thanks