[T21P] Problem with Blind Transfer

[svxsupervisors]

Hello dear, how are you?

I have some CallCenter environments with Asterisk servers and Yealink T21P phones. The phones serve me well, but I found a problem that is hurting my reports.

When my agents perform blind transfers, Asterisk does not understand how a transfer, it does not create the event 'TRANSFER' and not recreate a new UniqueID to the second call.

At first I thought it might be a problem in Asterisk, but realized tests with other branded handsets and functioned normally.

Assisted transfers did not have this problem.

Firmware Version - 34.72.0.75.

Please can you help me?

Best Regards!

[James_Yealink]

Hello,

Can you please send us pcap trace captured in Yealink phones and other brand phones?
We will compare the difference between them.

Regards,
James

[svxsupervisors]

(07-28-2015 05:35 AM)Yealink_James Wrote:  Hello,

Can you please send us pcap trace captured in Yealink phones and other brand phones?
We will compare the difference between them.

Regards,
James

Hello James,

Please find attached the pcap files.

Regards,
Jean Franco.

[myombo]

Hellow,

Can you please verify your "phone's Transfer configurations" under Features --> Transfer :
- Semi-Attended Transfer
- Blind Transfer On Hook
- Attended Transfer on Hook
- Transfer on Conference Hang up
- Transfer Mode Via Dsskey

If its the configuration issue, i think this can help.

[svxsupervisors]

(07-28-2015 05:13 PM)myombo Wrote:  Hellow,

Can you please verify your "phone's Transfer configurations" under Features --> Transfer :
- Semi-Attended Transfer -[ENABLED]
- Blind Transfer On Hook
- Attended Transfer on Hook
- Transfer on Conference Hang up
- Transfer Mode Via Dsskey

If its the configuration issue, i think this can help.

James,

Quote:

James,

Follow me transfer settings of my phone.

- Semi-Attended Transfer - [ENABLED]
- Blind Transfer On Hook - [ENABLED]
- Attended Transfer on Hook - [ENABLED]
- Transfer on Conference Hang up - [DISABLED]
- Transfer Mode Via Dsskey - [BLIND TRANSFER]

In fact my transfers work but do not signal as they should in Asterisk.

BLIND TRANSFER

-- Executing [99980@from-internal:1] Answer("SIP/homologsvx-0000008b", "") in new stack
-- Executing [99980@from-internal:2] NoOp("SIP/homologsvx-0000008b", ">>>> 1438113389.146 <<<<<<<") in new stack
-- Executing [99980@from-internal:3] Queue("SIP/homologsvx-0000008b", "6500,t,,") in new stack
-- Music class default requested but no musiconhold loaded.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- SIP/1001-0000008c is ringing
-- SIP/1001-0000008c answered SIP/homologsvx-0000008b
-- Music class default requested but no musiconhold loaded.
[2015-07-28 16:56:40.569] NOTICE[2622][C-00000042]: chan_sip.c:23141 handle_response_notify: Got OK on REFER Notify message
[2015-07-28 16:56:40.636] NOTICE[2622][C-00000042]: chan_sip.c:23141 handle_response_notify: Got OK on REFER Notify message
== Spawn extension (from-internal-xfer, 99980, 1) exited non-zero on 'SIP/homologsvx-0000008b'
-- Executing [99980@from-internal-xfer:1] Answer("SIP/homologsvx-0000008b", "") in new stack
-- Executing [99980@from-internal-xfer:2] NoOp("SIP/homologsvx-0000008b", ">>>> 1438113389.146 <<<<<<<") in new stack
-- Executing [99980@from-internal-xfer:3] Queue("SIP/homologsvx-0000008b", "6500,t,,") in new stack
-- Music class default requested but no musiconhold loaded.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- SIP/1001-0000008d is ringing
-- SIP/1001-0000008d answered SIP/homologsvx-0000008b

QUEUE LOG

+------------+----------------------------+-----------+-------+----------------+---------
| id | time | queuename | agent | callid | event |
+------------+----------------------------+-----------+-------+----------------+---------
| 1429392833 | 2015-07-28 16:56:29.149186 | 6500 | NONE | 1438113389.146 | ENTERQUEUE
| 1429392834 | 2015-07-28 16:56:34.620841 | 6500 | 2000 | 1438113389.146 | CONNECT |
1429392835 | 2015-07-28 16:56:40.439598 | 6500 | 2000 | 1438113389.146 | COMPLETECALLER
| 1429392836 | 2015-07-28 16:56:45.310440 | 6500 | NONE | 1438113389.146 | ENTERQUEUE
| 1429392837 | 2015-07-28 16:56:48.474826 | 6500 | 2000 | 1438113389.146 | CONNECT
|1429392838 | 2015-07-28 16:56:52.313697 | 6500 | 2000 | 1438113389.146 | COMPLETEAGENT

ASSISTED TRANSFER

-- Executing [99980@from-internal:1] Answer("SIP/homologsvx-0000008e", "") in new stack
-- Executing [99980@from-internal:2] NoOp("SIP/homologsvx-0000008e", ">>>> 1438113429.149 <<<<<<<") in new stack
-- Executing [99980@from-internal:3] Queue("SIP/homologsvx-0000008e", "6500,t,,") in new stack
-- Music class default requested but no musiconhold loaded.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- SIP/1001-0000008f is ringing
-- SIP/1001-0000008f answered SIP/homologsvx-0000008e
-- Music class default requested but no musiconhold loaded.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Executing [99980@classe6:1] Answer("SIP/1001-00000090", "") in new stack
-- Executing [99980@classe6:2] NoOp("SIP/1001-00000090", ">>>> 1438113440.151 <<<<<<<") in new stack
-- Executing [99980@classe6:3] Queue("SIP/1001-00000090", "6500,t,,") in new stack
-- Music class default requested but no musiconhold loaded.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- SIP/1000-00000091 is ringing

QUEUE LOG

+------------+----------------------------+-----------+-------+----------------+---------
| id | time | queuename | agent | callid | event |
+------------+----------------------------+-----------+-------+----------------+---------
| 1429392839 | 2015-07-28 16:57:09.167652 | 6500 | NONE | 1438113429.149 | ENTERQUEUE |
| 1429392840 | 2015-07-28 16:57:12.367861 | 6500 | 2000 | 1438113429.149 | CONNECT |
| 1429392842 | 2015-07-28 16:57:27.182163 | 6500 | 2000 | 1438113429.149 | TRANSFER |

+------------+----------------------------+-----------+-------+----------------+---------
| id | time | queuename | agent | callid | event |
+------------+----------------------------+-----------+-------+----------------+---------
| 1429392841 | 2015-07-28 16:57:20.747642 | 6500 | NONE | 1438113440.151 | ENTERQUEUE
| 1429392843 | 2015-07-28 16:57:38.290878 | 6500 | 2001 | 1438113440.151 | RINGNOANSWER
| 1429392844 | 2015-07-28 16:57:47.111207 | 6500 | 2000 | 1438113440.151 | CONNECT |
| 1429392845 | 2015-07-28 16:57:49.749551 | 6500 | 2000 | 1438113440.151 | COMPLETEAGENT

There is another way of validating this?

I can't change the functionality of the button.

Regards,

[jjnet]

Hi,

We have almost exactly the same issue with Yealink Phones and 3CX Call Queues. As an example the Yealink T46GN is not releasing call on blind transfer until answered/timed out at the other extension and this seriously delays new queue calls from reaching the Agent (20-30 seconds sitting idle)

This is what happens currently:
A calls B
B blind transfers to C (using method: TRAN->extn->TRAN)
B does not release the leg of the call until C answers (the display on the phone shows the call has left, however 3CX still has a leg open to phone B until A and C are connected)

This is what should happen:
A calls B
B blind transfers to C (using method: TRAN->extn->TRAN)
B releases the leg of the call when TRAN is pressed a second time

The behaviour only seems to occur with Yealink phones, i have tested using a Snom 870 and the 3CX SoftPhone which release the call straight away and the next call queue can come straight to the Agent.

Similar issues discussed here on the 3CX forum:

http://www.3cx.com/forums/yealink-t28-no...39132.html
http://www.3cx.com/forums/blind-transfer...22494.html

[svxsupervisors]

Hi,

We work with call center and use only Yealink phones to our operations.

We currently have about 400 phones between the T21p and T19p models, both have the same problem reported in this topic.

We need a special attention in this case because I believe that besides solving our problem we can help other users of Yealink.

There is another way to support done by you?

I'm waiting for a contact.

[jjnet]

Yealink have been really helpful in regard to this strange behaviour and after sending some traces from Snom and Yealink phone they have now released a new T46G Firmware (28.80.0.72.rom) that changes the blind transfer behaviour to match what we see with the Snom phones.

We've tested with only one agent logged into the call queue and as soon as we blind transfer the first call the second call comes straight in now.

Great job Yealink :-)

For other Yealink models you may need to contact Yealink support and request the appropriate firmware, I think they will include this in the next major release cycle anyway.