This case may be a little esoteric, but I ran into it this morning, and it caused me some grief. I have a Lync deployment that uses extensions instead of DIDs, which means that every user has a line URI that looks like “tel:+19058825000;ext=3900”. This includes UCMA applications, which other users (or the auto attendant) can dial internally by extension. Now, I wanted to give this application its own DID without breaking the extension dialling, which seemed like a simple matter-the gateway can forward the DID to the mediation server, and the mediation server can normalize the DID to the line URI. I set this up, placed a call from a cell phone, and everything was great. Then I tried calling the same number from Lync…
For those keeping score, I now have a Lync client placing a call out through the mediation server, through a gateway, and out to the PSTN. This call then turns right around, comes back into the same gateway, through the same mediation server, and in theory, gets to the application. Instead, I get a carrier “number is not in service” message, and a message in the Lync trace that seemed very strange:
TL_INFO(TF_PROTOCOL) 0AE8.139C::07/18/2012-16:56:42.578.00f4d3e7 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record
Start-Line: SIP/2.0 485 Ambiguous
From: “Chris Bardon”<sip:19058825000;phone-context=PstnGateway_192.firstname.lastname@example.org;user=phone>;epid=7CF3A158A2;tag=d8526b2edf
CSeq: 3186 INVITE
Via: SIP/2.0/TLS 192.168.200.230:63943;branch=z9hG4bKcdc9dfa6;ms-received-port=63943;ms-received-cid=1A2700
ms-diagnostics: 4002;reason=”Multiple users associated with the source phone number”;HRESULT=”0x8004C3CC”;source=”cttrhlync01.corp.computer-talk.com”
The key in there was the ms-diagnostics header saying that there were multiple users associated with the source phone, which I suppose is true if you ignore the extensions on the Line URIs. The real question here though, is why should the mediation server care about the source? The destination is valid, the call should go through, right? I looked for a definitive answer on this, but I haven’t managed to find one yet, so if anyone knows please leave a comment. My theory though is that the mediation server sees an incoming call that it can match to an outbound call, and thinks it can connect them internally without the PSTN leg. Because the extension isn’t being sent with the PSTN caller ID though, the MS can’t determine which user made this call in the first place, so it just gives up on the call rather than send it through anyway. Whatever the reason behind this is though, there is a workaround-modify the caller ID.
There are a few places where you could modify the caller ID for this case, but I chose to make it as specific as possible. I added a route in the Lync control panel that matched ^\+190588225000$ – the normalized version of my DID. Then I checked the “Suppress Caller ID” checkbox, and put a random phone number in there (actually, I used the company fax number). Commit the change, wait a few minutes (since routing changes aren’t necessarily instantaneous), and try the call again. This time it’ll succeed, although the caller ID that your app gets will be the value in the route, and not the actual Lync user’s caller ID. Also worth noting-this has no effect on actual calls from the PSTN-this is just for calls to the PSTN DID from Lync.
Of course, this case is only really relevant in a few cases, but it means that internal users can reach your application through the DID that you publish to the outside world the same way as external users can, which is good for consistency. It also would have worked had the line URI of the application been the same as the DID, but this would have broken being able to dial the app by extension elsewhere, like from the front end application I have to transfer to other apps, allowing them to share a single DID.