Yealink Forums

Hello all!

I'm having a very tricky problem with yealink phones T20P and T26P (almost all my more than 2000 terminals suffer with this problem). The scenario is: phone A calls phone B; Phone B answers the call and transfers it to phone C (no matter if it is an attended or blind transfer). Then the audio from phone A user is completely unperceptive on phone C (choppy and metallic like if there is a problem on RTP synchronism). Audio from phone C to phone A is good.
Additional notes:
1. I tried with and without a SIP proxy. The behavior is the same;
2. Attended transfer is made through pressing * during the call. DTMF are sent to the sip server out of band (RFC 2833);
3. The problem don’t happen if I use G711 codec;
4. When using SIP proxy I tried to capture outgoing RTP packet from the SIP proxy for an entire call. Then I reassembled RTP packet payload for each feed (from proxy to phone A and the other to phone C) onto 2 audio files. Both audio are good, no packet missing and perfectly audible. So the audio exits the proxy in apparently good conditions.
5. I tried several versions of firmware but the behavior is always the same;
6. I googled about the problem and found someone complaining the same but no solution were provided. Someone hinted about problems in the RTP packets timestamp…

If someone have the same problem, is it possible to share his/her findings or maybe point for the solution? I’m pretty sure that it should be something messing with RTP reassembling on the yealink (maybe the timestamp problem I found on google can give an explanation) because I have other phone brands (grandstream and Aastra) that are configured exactly in the same way yealink are and they don’t experience this problem.
Thanks for any clue you can give me.

Regards,
Carlos Franco

Why don't you use G711 codec?
This issue happens in two callers in Yealink Phones or from other brand?
I advise you ask your distributor for help and supply syslog level 6, config.bin and trace pcap to them.
They can submit your issue to the corresponding Yealink technical specialist and arrange the solvement asap.
How to Get the Correct Syslog, Config.bin and Trace

(05-08-2014 02:02 PM)Yealink Support Wrote: [ -> ]>Why don't you use G711 codec?
Good question, but I'll answer with another one: Isn't it expectable that the phone should work with G722 ? The audio experience in G722 is very different from narow band codecs...

>This issue happens in two callers in Yealink Phones or from other
>brand?
The problem happens when the two callers are Yealink Phones.
The other brands, like I wrote in the original post, doesn't have the problem. I they also use G722 (aastra and recent models of grandstream).

>I advise you ask your distributor for help and supply syslog level 6,
>config.bin and trace pcap to them.
They can submit your issue to the corresponding Yealink technical specialist and arrange the solvement asap.
I'll do that, but I was trying to reach Yealink directly as this problem is affecting 1800 yealink users, and it happens very often because it's very common assistants (T26P models) to transfer calls to technical guys in their department and the result is calls should be hung bercause we can't understand what our client is saying...
I'll post traces from phone here too.

Thank you for your quick answer and recommendation.

Best regards,
Carlos Franco
How to Get the Correct Syslog, Config.bin and Trace

---

Hello again,

Here are the trace I will send to my distributor.

The event sequence that generate this trace was:

1. PhoneA calls PhoneB - both audio feeds are OK;
2. Phone B hits * key to transfer the call, but as no number is dialed,
the transfer function times out and returns to call between PhoneA
and PhoneB - both audio remains OK;
3. Phone B hits * key to transfer the call and after 2 seconds hits
again * to abort the transfer:
- audio from phone B to Phone A remains good, but audio from
phone A to phone B is completly corrupted;

In this example, the call transfer isn't completed (so I don't need to
collect packet from a third phone) but the effect is the same: Phone
C (to where the call is transfered) will not be able to understand
what phone A is saying.

thanks again for the help you could give me (maybe redirecting this information to your technical dept).

Best regards,

Carlos Franco

Do you test x.72.0.25?
Why do you use * to transfer but not transfer key?

Can you tell me who is your distributor?

(05-08-2014 09:38 PM)Yealink Support Wrote: [ -> ]Do you test x.72.0.25?
I think so, but I can test again to be sure.

Why do you use * to transfer but not transfer key?
Because in the beginning although we inform people to use * they started to use the TRAN key on yealink phones. Then we started receiving reports of audio problem when calls were transferred (I believe that the cause is defferent but the type of audible audio is the same). We have other brands of phones, some have a transfer key and others not. So we send a notice that call transference should be made through the * key. It's the way that we found to have the same behaviour no matter the brand the phone is... Now we have no problem with aastra phones, no problem with grandstream phones (but most of them are only G711 capable) and a reproducible but unexplainable problem with yealink...

---

(05-08-2014 10:24 PM)Yealink Support Wrote: [ -> ]Can you tell me who is your distributor?

Yes. It's VOXSYS. I call them this morning and they promptly asked me to send them all my findings and told me that they will put all their effort to help me regarding the number of devices we have from them.

Regards,

Carlos Franco

The transfer issue may be caused by many reasons, different servers, different sip message or process will reduce this issue.
So you should supply the issue transfer key pcap for your distributor to debug.

(05-09-2014 09:11 AM)Yealink Support Wrote: [ -> ]The transfer issue may be caused by many reasons, different servers, different sip message or process will reduce this issue.
So you should supply the issue transfer key pcap for your distributor to debug.

I understand. But As I stated on my earlied post, I wish to use the transfer option from asterisk (the * key in me implementation) and not from the phone option key. This is for a matter of standardization and to have maximum independance from phone brands. Anyone who has to support a large community of users and devices spread over large geographical area will understand my concern...
I wish Yealink can also understand me too. :-)
BTW, my distributor already answered me that he forwarded my question to yealink for further support...

Best regards,

Carlos Franco