Twilio webRTC 通话在整整 10 分钟后中断 [英] Twilio webRTC call cuts off after exactly 10 minutes

查看:46
本文介绍了Twilio webRTC 通话在整整 10 分钟后中断的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用 Twilio.js 使用 webRTC 记录通话.工作正常,除了在 10 分钟标记(准确!)呼叫挂断.TwiML 上的最长记录时间设置为 7200 秒.

Using Twilio.js to record a call using webRTC. Works fine except at the 10 minute mark (exact!) the call hangs up. Max record time on TwiML is set to 7200secs.

浏览器的控制台显示:
[Twilio.PeerConnection] 信号状态是稳定的"twilio.js:1843 [Twilio.PeerConnection] iceConnection 状态是正在检查"twilio.js:1843 [Twilio.PeerConnection] iceConnection 状态为已连接"twilio.js:1843 [Twilio.PeerConnection] iceConnection 状态为完成"

[10 分钟后...]

[After 10 minutes...]

twilio.js:1843 [Connection] 从网关收到 HANGUPtwilio.js:1843 [连接] 断开连接...

Chrome://webrtc-internals 转储没用:<代码>{"time": "11/28/2016, 4:35:48 PM","type": "iceConnectionStateChange",值":ICEConnectionStateCompleted"},{"time": "11/28/2016, 4:45:51 PM","type": "停止",价值": ""},

打破 twilio.js 库,我看到有些东西发送了一个带有有效负载的 websocket 消息:{"payload":{"callsid":"CA18974349269fb9f24977185c5deaa62c"},"type":"hangup","version":""},这显然会导致客户端挂断电话.

Breaking in the twilio.js library I see that something sends a websocket message with payload: {"payload":{"callsid":"CA18974349269fb9f24977185c5deaa62c"},"type":"hangup","version":""}, which clearly causes the client to hang up the call.

关于为什么会发生这种情况的任何想法?它发生在桌面和移动浏览器中.

Any ideas of why this may happen? It happens from both desktop and mobile browsers.

推荐答案

原来 Twilio 会在 600 秒后切断 webRTC 调用.不完全确定为什么,但我猜它与 --stale-nonce 参数有关,因为 Turn Servers 恰好有 600 秒的超时.也许?

Turns out Twilio is cutting off webRTC calls after 600 seconds. Not exactly sure why but I am guessing it has something to do --stale-nonce param for Turn Servers which coincidentally have a 600 sec timeout. Maybe?

编辑并修复.

最终,Twilio 对我们的请求做出了回应,并提供了一种解决方法来启用 WEBRTC 10 分钟以上的录制.恕我直言,这很hacky,但它有效.

Eventually Twilio responded to our ticket and provided a workaround to enable WEBRTC 10+ min recording. IMHO it's quite hacky, but it works.

当呼叫者加入时,将一个出站 API 调用泵入会议,并播放无声 mp3,无论是非常长的还是循环的短的.这个出站支路是会议开始所必需的,静默的mp3会双向发送RTP.另一个相当相似的是让客户端像这样拨入:

When the caller joins, pump an outbound API call into the conference with a that plays a silent mp3, either a really long one or a looped short one. This outbound leg is necessary to start the conference, and the silent mp3 will send RTP bidirectionally. Another rather similiar is to have the client dial into like this:

<Response>
   <Dial record="true" action="record_action">
    <Conference waitUrl="url_to_nearly_silent_audio_file">record</Conference>
  </Dial>
</Response>

您需要为 waitURL 中的循环制作一个小容量的 WAV 文件,以防完全静默的 WAV 文件不会生成 RTP 数据包.

You will need to manufacture a low volume WAV file for a loop in waitURL, in case a completely silent WAV file doesn't generate RTP packets.

https://www.twilio.com/docs/api/twiml/conference

这篇关于Twilio webRTC 通话在整整 10 分钟后中断的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆