Skip to main content
Question

RingCentral Embeddable incoming call unstable rc-active-call-notify event

  • February 26, 2025
  • 4 replies
  • 40 views

I am working on a call center product which is based on RingCentral queues. I’ve created a queue and assigned it a direct phone number. Now, I am using embeddable widget and I am able to receive and accept calls, so this part is working fine.

However, I need to do some calls to my server API based on caller and recipient (direct queue) phone numbers and this is where I have issues. I am using event listener which is looking for a message with following type:

rc-active-call-notify Most of the time it works fine, but sometimes this event is just not being fired, even though I do receive a call and can accept it without any issue.Also, if I just wait on the line, I can actually see that call is being “reset” (I see in browser console Event: Rejected and then Event: Terminated entries, the widget blinks as if it was re-rendered, but the call will still keep on ringing) and after that I do see rc-active-call-notify event. Problem is I have to wait like 10-15 sec which is not realistic in real production use-case.The only event which is stable and I can see it every time is rc-call-ring-notify, but I cant bind to that one because it contains wrong recipient phone number. I need to get queue direct number, while rc-call-ring-notify payload has this instead: company_number*user_extension, e.g. +492280000000*301. Payload only contains the queue name, but I can not bind to it, unfortunately.I also tried to bind to rc-telephony-session-notify event, but faced the same issue.

4 replies

PhongVu
Community Manager
Forum|alt.badge.img
  • Community Manager
  • 2312 replies
  • February 27, 2025

I am not sure about the first part of your issue.

For the second part, I don’t see such a long delay as you said. The “rc-active-call-notify” and the “rc-telephony-session-notify” events come almost immediately when the incoming call is ringing. And I can grab the “from” and the “to” phone number correctly from the event payload.

 


  • Author
  • New Participant
  • 4 replies
  • February 27, 2025
PhongVu wrote:

I am not sure about the first part of your issue.

For the second part, I don’t see such a long delay as you said. The “rc-active-call-notify” and the “rc-telephony-session-notify” events come almost immediately when the incoming call is ringing. And I can grab the “from” and the “to” phone number correctly from the event payload.

 



As mentioned, the bug is a bit random, but for me it often happens during the first call after page refresh. In most cases there’s no delay as you say, but when it happens the behavior is following:

1. I receive the call and can see rc-call-ring-notify event with data (which as mentioned does not have the direct phone number in “to” prop so I cant use that one)
2. It rings for some time, then after some time (10-15 sec) I can see following logs:

Event: Rejected

Event: Terminated

end call:

3. Events above also make the widget blink, so I guess it refreshes
4. After it refreshes itself I can see all the expected events (rc-call-ring-notify, rc-active-call-notify, rc-telephony-session-notify) almost instantly.

Based on that, I do not think that events are just being delayed, it looks like force refresh the widget does itself fixes the problem.


Also here are the screenshots of logs with timestamps

 


PhongVu
Community Manager
Forum|alt.badge.img
  • Community Manager
  • 2312 replies
  • February 27, 2025

I doubt that it’s the web page and the environment. I tested many times in my simple test page and I cannot reproduce such an issue. Can you also create a simple page and try again.


  • Author
  • New Participant
  • 4 replies
  • March 3, 2025

Yep, just did that. Created a simple html page, added code from basic example to the script inside head tag and got the very same behavior 😕


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings