Problem Description: Experienced an issue in a client production environment where Polycom VVX phones would fail with a fast busy anytime a user would attempt to transfer a call. The same users could transfer a call successfully when they were just using a Lync desktop client and headset. In looking at the web GUI of the phone, I observed that the default transfer type is set to blind (see screenshot below).
When I change the default type to "consultative", the users are able to successfully transfer calls (albeit with a few additional steps). I opened a case with Polycom support in order to drill down deeper into the issue.
CAUSE: Put simply, the root cause is that the second number being dialed as the transfer to destination is not being normalized to an E.164 format and therefore failing.
Here is a regular call to 4436166338:
0916144138|sip |0|00|>>> Data Send TLS 64.47.206.39:443
0916144138|sip |0|00| INVITE sip:4436166338;phone-context=na_wn@contoso.com;user=phone;transport=tls SIP/2.0
0916144138|sip |0|00| Via: SIP/2.0/TLS 192.168.1.20:33763;branch=z9hG4bKb6ef1ad01C948C1C
0916144138|sip |0|00| From: "John Doe" <sip:jdoe@contoso.com>;tag=927754E0-F394DD4C;epid=0004f264b92d
0916144138|sip |0|00| To: sip:4436166338;phone-context=na_wn@contoso.com;user=phone
0916144138|sip |0|00|<<< Data received TLS
0916144138|sip |0|00| SIP/2.0 100 Trying
0916144138|sip |0|00| From: "John Doe" <sip:jdoe@contoso.com>;tag=927754E0-F394DD4C;epid=0004f264b92d
0916144138|sip |0|00| To: sip:4436166338;phone-context=na_wn@contoso.com;user=phone
The "TranslationService/5.0.0.0" is adding the +1:
0916144138|sip |0|00|<<< Data received TLS
0916144138|sip |0|00| SIP/2.0 101 Progress Report
0916144138|sip |0|00| From: "John Doe" <sip:jdoe@contoso.com>;tag=927754E0-F394DD4C;epid=0004f264b92d
0916144138|sip |0|00| To: <sip:4436166338;phone-context=na_wn@contoso.com;user=phone>
0916144138|sip |0|00| Call-ID: ea0c67913db9d4eed89986d65c64b92d
0916144138|sip |0|00| CSeq: 1 INVITE
0916144138|sip |0|00| ms-diagnostics: 14011;reason="Called Number translated";source="LYNCFEMED.CONTOSO.COM";RuleName="NA_WN-NATIONAL";CalledNumber="4436166338";TranslatedNumber="+14436166338";appName="TranslationService"
0916144138|sip |0|00| Server: TranslationService/5.0.0.0
Lots of progress reports and ringing traffic I'm skipping...
0916144149|sip |0|00|<<< Data received TLS
0916144149|sip |0|00| SIP/2.0 200 OK
0916144149|sip |0|00| From: "John Doe"<sip:jdoe@contoso.com>;tag=927754E0-F394DD4C;epid=0004f264b92d
0916144149|sip |0|00| To: <sip:4436166338;phone-context=na_wn@contoso.com;user=phone>;tag=8bc1ae42f0;epid=2B9335DCDC
0916144149|sip |0|00| P-Asserted-Identity: sip:+14436166338@contoso.com;user=phone
The phone then uses the P-Asserted-Identity to update the display (so it shows +14436166338 even though I called 4436166338):
0916144150|sip |3|00|GetRemotePartyAddress from 'P-Asserted-Identity'
0916144150|sip |3|00|CStkCall::OnEvNewDest (0x12e0334) new display '' user '+14436166338' old 'To' new 'P-Asserted-Identity' source
When we do a blind transfer to we're doing a REFER. In this example I was trying to transfer to 9165154209. I assume the server doesn't normalize this because it's a REFER rather than an INVITE.
The warm (consultative) transfers are working because you're starting an entirely new INVITE, which is normalized by the server, then merging to active calls together, rather than a REFER to a new number.
916144915|sip |0|00|>>> Data Send TLS 64.47.206.39:443
0916144915|sip |0|00| REFER sip:LYNCFEMED.CONTOSO.COM@contoso.com;gruu;opaque=srvr:MediationServer:WTgOV5bLx1eoFpGD4eyWegAA;grid=cf0add08853d497797199a1a00fbc8e3 SIP/2.0
0916144915|sip |0|00| Via: SIP/2.0/TLS 192.168.1.20:33763;branch=z9hG4bKfad8d32c47379670
0916144915|sip |0|00| From: "John Doe" <sip:jdoe@contoso.com>;tag=48385D0-3EE9DD1C;epid=0004f264b92d
0916144915|sip |0|00| To: <sip:+14436166338@contoso.com;user=phone>;tag=c1cc077b;epid=2B9335DCDC
0916144915|sip |0|00| Refer-To: sip:9165154209;phone-context=na_wn@contoso.com;user=phone
The current behavior:
Transfer button pressed
Phone > Lync – REFER
Lync > Phone – OK
Lync > Phone – NOTIFY "Trying"
Phone > Lync – BYE
With the special transfer interop:
Phone > Lync – REFER
Lync > Phone – OK
Lync > Phone – NOTIFY "Trying"
(Phone waits for call to connect)
Lync > Phone – NOTIFY "Ok"
Phone > Lync – BYE
WORKAROUND: In order to get the blind transfer to work successfully, the callers must add a "+1" as a prefix to the 2nd number being dialed. You do this by pressing the asterisk (*) twice and then entering the rest of the number.
RESOLUTION: I pinpointed the root cause for why the calls fail. The Polycom VVX phone is sending the SIP REFER/INVITE on blind xfer into the Lync Mediation Server on an inbound pool trunk that is under "Dial Plan" section of the Voice Routing labeled "PstnGateway_<IP Address>". Typically if Lync is doing the normalization on inbound calls, one would have specific rules to convert the incoming digits from the telco carrier into full E.164 format for DID's assigned to user LineURI fields. Some deployments don't have this inbound pool trunk because they rely on the SBC/gateway to do the digit manipulation and pass the numbers into Lync in full E.164 format. My guess is that since the inbound pool trunk does not exist, it does not try to use the translation service on blind transfer. Since this deployment does have an inbound pool trunk deployed, I had to add normalization rules for 10 digit/11 digit national dialing and international dialing so that it would convert the dialed number into E.164 format. Now the blind transfer works.
Here is the error message that occurs after the SIP REFER and SIP INVITE on blind transfer:
SIP/2.0 404 No matching rule has been found in the dial plan for the called number.
ms-diagnostics: 14010;reason="Unable to find an exact match in the rules set";source="<LYNC_FE_ME_POOL_FQDN>";CalledNumber="2024891495";ProfileName="PstnGateway_10.1.20.3";appName="TranslationService"
I was initial looking in the wrong place at the user assigned dial plan policy, routing rules, and trunk configuration called number translations as logic would suggest since outbound calls were failing.