Agent Group call state - Yealink T48+ BLF

[Vernon]

Hello,

 

As with my earlier posts and doing more testing i think i found something that doesn't look to be influenced by the phone config settings.

 

The issue is when a manager is monitoring multiple agents and a call comes in, all agents go into "Talking" mode even though the caller is in the early call stage and nobody has picked up. It takes a couple of seconds for the status to clear but it becomes hard to gauge who is picking up calls as it doesn't seem to go through the list of agents before the status changes. This shows up on the T48+ type models that track call states via BLF's on top of other functions.

 

Digging into it, it looks like the call states may be mis-attributed when calls go through an agent group.

 

When calling an extension directly the state is labelled as early and shows appropriately on the phone BLF. Data below bolded.

Direct Call

        <?xml version="1.0"?>\r\n
        <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="186" state="full" entity="sip:100@test.domain.com:5060">\r\n
          <dialog id="57" call-id="921e247c@pbx" direction="recipient">\r\n
            <state>early</state>\r\n
            <local><identity display="TEST MAIN">sip:1234567890@test.domain.com</identity></local>\r\n
            <remote><identity display="TEST CALLER ">sip:0987456321@test.domain.com</identity><target uri="sip:*87100@test.domain.com"/></remote>\r\n
          </dialog>\r\n
        </dialog-info>\r\n

 

When calling the agent group however, the state is confirmed even though the caller hasn't connected to any agent yet.

Agent Group

 

        <?xml version="1.0"?>\r\n
        <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="183" state="full" entity="sip:100@test.domain.com:5060">\r\n
          <dialog id="56" call-id="b6ae8646@pbx" direction="recipient">\r\n
            <state>confirmed</state>\r\n
            <local><identity display="TEST MAIN">sip:1234567890@test.domain.com</identity></local>\r\n
            <remote><identity display="TEST CALLER ">sip:0987456321@test.domain.com</identity></remote>\r\n
          </dialog>\r\n
        </dialog-info>\r\n

 

This is on a test v66.0.7

 

[execcomm]

Yes, me having a same problem. I did not know how to check. Any fix?

[Vodia PBX]

The dialog state is at the end of the day just a way to turn BLF lights on, off or make them blink. The IETF could have come up with something simpler, but it did not happen and we have to use what is available on most phones. A blinking LED is the "promise" from the PBX that the user can pick that call up. 

When the call comes into the ACD, there is the first announcement that must be played. During that time IMHO it would be wrong to offer a pickup. Only when the call has made it through the initial announcements it should offer a pickup. 

Hopefully the phone is not too smart about it — if the call is first connected the phone might say, wait it was connected and now it is ringing how can that be? And not display the ringing state. 

[Vernon]

I think you misunderstand what the issue is. It's not about the call pick up promises or the blinking, it's about the dialogue the PBX sends.

 

I found a reference picture that can help understand what the BLF buttons look like under the new version. Any call that comes in into an ACD triggers all the agents to go "Talking", which is incorrect, they should be ringing, and only the agent that picks up the call is "Talking".

 

I should have included the captured data from an older PBX that showed the call states, but only included for the tested version. In the new version the ACD sends out a <state>confirmed</state>\r\n packet for an incoming call and this causes all the monitored agents to show up as "Talking" compared to the older PBX that sent <state>early</state>\r\n which would tag the BLF key as "Ringing".

 

This is only a problem for phones that are capable of providing extra BLF information, in my tests it's the Yealink T48S+ models.

 

[execcomm]

This is annoying my client a lot. Cannot be used very well with agent groups. Any fix? I'm using a T56A. 

[execcomm]

Any fix for this?

[execcomm]

Still trying to find a fix for this. I have some problem as poster. It's really annoying my client, and at the same time it does not seem like a hard fix. It should send the Early status not the confirmed. I logged the same information and it is vodia that send the wrong message in agent group.

[Vodia PBX]

So in a nutshell, you want to show the early state for all calls unless they are talking to an agent?

[execcomm]

Yes. It is normal, because the user is not talking, its ringing. 

[execcomm]

This has not been fixed yet. I've tried it and I might loose my customer because of this. Please help

[Vernon]

I'm still a little surprised this hasn't been resolved. From the techs i spoke with, they found it easier to downgrade the phone model for ACD managers than expect a fix.

 

It may not have been the most precise troubleshooting provided, but it's easily replicated.

 

All that would need to be done is to just change how the ACD tags incoming calls. Pre v66.0.7 it sent the correct string, for whatever reason, in 66.0.7 it was changed.

 

Old ACD sent this BLF Status for incoming calls:

<state>early</state>\r\n - Shows ACD Agents as "Ringing" until X agent picks up and their BLF status changes to "Talking"

New ACD send this BLF status for incoming calls:

<state>confirmed</state>\r\n - Shows all ACD agents as "Talking" until X agent picks up and after 5-10 second delay only their ext shows as "Talking"

 

It doesn't look like this has addressed since v66.0.7.

 

[execcomm]

Is this fixed in new version? Client is very frustrated.

 

@Vernom did you figure out?