Jump to content

Agent Group call state - Yealink T48+ BLF


Recommended Posts

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

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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. 

Link to comment
Share on other sites

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.

 

BLFStatus.PNG

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...