Handling Hangups on incoming PSTN calls to Chime SDK Meetings

0

Hi! I've been hooking up Chime SDK into our application recently, and have got some basic functionality working - Audio/Video, muting, etc. Currently working through hooking up incoming PSTN calls. We've got a Lambda in place to handle those incoming calls, and got some SpeakAndGetDigits / JoinChimeMeeting combination working to bring participants in. For context, we're using the React component library for non-PSTN users.

The issue we have at the moment is around when participants leave. When a PSTN participant hangs up, that participant is still shown as active for a significant length of time (last test was around a minute). I'm trying to find a way to fix this.

https://docs.aws.amazon.com/chime-sdk/latest/dg/call-flow.html

The sample call flow doc above for PSTN calls implies that a Hangup can call deleteAttendee to clear this up - though I've yet to find a convenient way of linking the incoming calls back to the relevant attendee. Is there something I'm missing, or do I need to explicitly store all participant IDs explicitly (or use some hack like embedding the Call ID into the meeting participant third party ID)?

It does seem like something that should happen automatically as well - is there some reason I'm missing that people want a disconnected phone call to remain attached to a Meeting?

asked 4 months ago78 views
1 Answer
1
Accepted Answer

Thinking of the call flow that you refer to, in step 6 you got the meeting ID and attendee ID that you needed for the JoinChimeMeeting action. At that step, when you send the JoinChimeMeeting action, you could also store those IDs in TransactionAttributes. Those transaction attributes will be stored with that session so you'll be able use them for the deleteAttendee API call in step 8 when you get the Hangup event.

Transaction attributes: https://docs.aws.amazon.com/chime-sdk/latest/dg/transaction-attributes.html

profile pictureAWS
answered 4 months ago
profile picture
EXPERT
reviewed 3 months ago
  • Thanks for taking a look - I'd attempted this, and wasn't receiving the TransactionAttributes back on the Hangup call when received - I'd assumed they didn't last that long. I'll take a look and see if I've accidentally cleared them down on another response.

  • Thanks again for the response - looks like the TransactionAttributes I'd set were getting cleared (possibly when handling the ACTION_SUCCESSFUL events). I've updated our code to go a little more overboard with ensuring TransactionAttributes are carefully returned in full each time, and that's now feeding through the actions to the Hangup event as expected.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions