Skip Ribbon Commands
Skip to main content

Xadean's Empirical Musing


Quick Launch

Xadean's Empirical Musing > Posts > Polycom VVX Phones Fail to Blind Transfer in Lync Server 2013 Deployment
September 24
Polycom VVX Phones Fail to Blind Transfer in Lync Server 2013 Deployment

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

0916144138|sip  |0|00|    INVITE sip:4436166338;;user=phone;transport=tls SIP/2.0

0916144138|sip  |0|00|    Via: SIP/2.0/TLS;branch=z9hG4bKb6ef1ad01C948C1C

0916144138|sip  |0|00|    From: "John Doe" <>;tag=927754E0-F394DD4C;epid=0004f264b92d

0916144138|sip  |0|00|    To: sip:4436166338;;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" <>;tag=927754E0-F394DD4C;epid=0004f264b92d

0916144138|sip  |0|00|    To: sip:4436166338;;user=phone


The "TranslationService/" 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" <>;tag=927754E0-F394DD4C;epid=0004f264b92d

0916144138|sip  |0|00|    To: <sip:4436166338;;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/


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"<>;tag=927754E0-F394DD4C;epid=0004f264b92d

0916144149|sip  |0|00|    To: <sip:4436166338;;user=phone>;tag=8bc1ae42f0;epid=2B9335DCDC

0916144149|sip  |0|00|    P-Asserted-Identity:;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

0916144915|sip  |0|00|    REFER;gruu;opaque=srvr:MediationServer:WTgOV5bLx1eoFpGD4eyWegAA;grid=cf0add08853d497797199a1a00fbc8e3 SIP/2.0

0916144915|sip  |0|00|    Via: SIP/2.0/TLS;branch=z9hG4bKfad8d32c47379670

0916144915|sip  |0|00|    From: "John Doe" <>;tag=48385D0-3EE9DD1C;epid=0004f264b92d

0916144915|sip  |0|00|    To: <;user=phone>;tag=c1cc077b;epid=2B9335DCDC

0916144915|sip  |0|00|    Refer-To: sip:9165154209;;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.



There are no comments for this post.

Add Comment


Body *