Jabber calls using wrong extension to make call

[johnfplut]

I have a user that when they call another extension using jabber it looks like the call is coming from a different user/extension. If you answer, the call is silent. I used the user that is having a problems softphone to copy when making new softphones so maybe their information got copied to the other softphone but I can't find their username in any of the settings. I tried deleting their softphone and recreating it but that didn't help anything.

-When they call with their desk phone they show up normally/as themselves.

-Chatting in Jabber they show up normally.

Anyone else see this or recommend where to look?

Thanks.

[Dennis Mink · Accepted solution]

Have you checked that the alerting names and display names on the extension of the CSF device??

have you associated the line with the appropriate user?  (all the way at the bottom of the line configuration page)

=============================
Please remember to rate useful posts, by clicking on the stars below. 

=============================

[johnfplut]

Those are all set correctly. When this user calls it is using the wrong name and extension. You can't answer the call because the caller listed isn't actually calling you.

[johnfplut]

This is working correctly today, I think the client user had to restart their Jabber client for the changes to take effect.

[Jonathan Schulenberg]

The Alerting/Display Name information is only used if a directory lookup returns zero results. The most common reason for this is that the directory source (i.e. LDAP) has more than one account with that caller ID value, or post-Directory Lookup Rule transformed value, in any of the searched fields. In this situation the directory source will return all resulting accounts in an unpredictable order and Jabber will use the first record returned. So, if both Bob and Jane have extension 2000 in telephoneNumber then Jabber has an equal chance of showing Bob or Jane. The returned information is then stored in a local cache until the client is restarted or manually cleared. This is probably why it happened to work after the restart: the LDAP query happened to return the correct record first.

Please remember to rate helpful responses and identify helpful or correct answers.