Problem
You have a user who is enabled for Enterprise Voice in a Lync Server 2013 environment that had no issues placing and receiving calls but recently noticed that users attempting to call them is now receiving a fast busy with the error message:
Cannot contact <userName>
Running a trace with Snooper on the server shows that a SIP/2.0 485 Ambiguous error is logged during the failed call:
TL_INFO(TF_PROTOCOL) [0]2160.20F4::06/06/2017-13:36:28.621.00008520 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[4058195155] $$begin_recordTrace-Correlation-Id: 4058195155
Instance-Id: 495426
Direction: outgoing;source=”local”
Peer: CONTles03.CONT.com:58390
Message-Type: response
Start-Line: SIP/2.0 485 Ambiguous
From: <sip:tluk@contoso.com>;tag=244c2c0e70;epid=98eec5ee8d
To: <sip:+44xxxxx9578@contoso.com;user=phone>;tag=872B83A7584D65996E00DA963EC419D0
Call-ID: 1c27d3fe51e6418892fe4e79cb4f564b
CSeq: 1 INVITE
Via: SIP/2.0/TLS 192.168.131.2:58390;branch=z9hG4bK323649EF.04A161E3BE17588C;branched=FALSE;ms-received-port=58390;ms-received-cid=36CFC00
Via: SIP/2.0/TLS 172.16.1.121:50637;received=216.249.42.188;ms-received-port=50637;ms-received-cid=AE8300
Content-Length: 0
ms-diagnostics: 4199;reason=”Multiple users associated with the target phone number”;HRESULT=”0x8004C3CD”;processing-cluster=”CONTlse03.CONT.com”;processing-frontend=”CONTLSE03.CONT.COM”;source=”CONTLSE03.CONT.COM”
$$end_record
Solution
One of the reasons why this user would experience issues with inbound calls is if someone had recently created an account that uses the same number but with a different extension for their Line URI field. To troubleshoot this, launch the Lync Server 2013 Control Panel and search for users with the problematic user’s number but without the extension.
For this example, the problematic user’s Line URI field is configured as such:
tel:+44xxxxxx9578;ext=9578
With the above information, add a Line URI filter configured to contain the string:
tel:+44xxxxxx9578
As shown in the screenshot above, two users have been returned.
Open the properties of the user accounts to compare the Line URI field and in the case of this example, the problem is caused by a typo in the Line URI field where:
User A: tel:+44xxxxxx9578;ext=9578
User B: tel:+44xxxxxx9578;ext=9579
User B’s Line URI was meant to be:
User A: tel:+44xxxxxx9579;ext=9578
… and because of the slight typo shown above, the Control Panel allowed the configuration to be made since the strings were unique but a call could not be routed properly because there were 2 matches to the number even though the extensions were different.
