如果用户“始终允许",Twilio WebRTC 客户端会中断麦克风访问? [英] Twilio WebRTC client breaks if user "always allows" microphone access?

查看:31
本文介绍了如果用户“始终允许",Twilio WebRTC 客户端会中断麦克风访问?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在代理"端使用 Twilio WebRTC 客户端构建呼叫中心应用程序.

I'm trying to build a call centre app using the Twilio WebRTC client on on the "agent" side.

目前处于演示阶段,但我遇到了一个主要问题,它似乎是浏览器的 WebRTC 堆栈或 Twilio 的客户端代码中的错误.如果永久允许从浏览器访问麦克风(这是 Chrome 中的默认允许"行为,在 Firefox 中是一种可能性),那么第一个呼叫可以正常通过,但是当第二个呼叫路由到客户端时,接听它打破了一切.

It's at the demo stage currently, but I've come across a major issue which appears to be a bug either in the browser's WebRTC stack, or Twilio's client code. If the permanently allows access to the microphone from the browser (which is the default "Allow" behaviour in Chrome, and a possibility in Firefox), then the first call comes through fine, but when a second call is routed to the client, answering it breaks everything.

例如,在 Chrome 中(在 PC 和 Mac 上测试,使用当前最新版本 48),通过的第一个呼叫工作正常(我已经允许将麦克风用于此主机,并且它正在运行根据需要在 HTTPS 上):

In Chrome, for example (tested on PC and Mac, with the current latest version, 48), the first call that goes through works fine (I've already allowed the mic to be used for this host, and it's running on HTTPS as is required):

[Device] Setting up PStream
twilio.min.js:58 [WSTransport] Opening socket
twilio.min.js:58 [WSTransport] attempting to connect
twilio.min.js:58 [Device] Registering to eventStream with url: wss://matrix.twilio.com/2012-02-09/ACbf0c1cb8b610edf31aa7929d1105895a/32906…M5OSJ9.q_G8AEsidiWelamCLuEhKg7dL1hMtioZgK_gNsY61fs&feature=publishPresence
twilio.min.js:58 [Matrix] Attempting to connect to wss://matrix.twilio.com/2012-02-09/ACbf0c1cb8b610edf31aa7929d1105895a/32906…M5OSJ9.q_G8AEsidiWelamCLuEhKg7dL1hMtioZgK_gNsY61fs&feature=publishPresence...
twilio.min.js:58 [WSTransport] Socket opened
twilio.min.js:58 [PStream] Setting token and publishing listen
twilio.min.js:58 [Matrix] Socket opened... sending ready signal
twilio.min.js:58 [Device] Stream is ready
client:49 Ready
twilio.min.js:58 [Twilio.PeerConnection] signalingState is "have-remote-offer"
twilio.min.js:58 [Twilio.PeerConnection] signalingState is "stable"
client:64 Successfully established call
twilio.min.js:58 [Twilio.PeerConnection] iceConnectionState is "checking"
twilio.min.js:58 [Twilio.PeerConnection] iceConnectionState is "connected"
twilio.min.js:58 [Connection] Received HANGUP from gateway
twilio.min.js:58 [Connection] Disconnecting...
client:69 Call ended
twilio.min.js:58 [Twilio.PeerConnection] iceConnectionState is "closed"
twilio.min.js:58 [Twilio.PeerConnection] signalingState is "closed"

然后当我第二次调用它时,最初传入"处理程序被称为 OK 并且它会用铃声等提醒,但是当我调用 Connection.accept() 时,会发生以下情况:

Then when I make the second call to it, initially the "incoming" handler is called OK and it alerts with the ring tone etc, but when I call Connection.accept(), the following happens:

twilio.min.js:58 [Twilio.PeerConnection] signalingState is "have-remote-offer"
twilio.min.js:58 [Twilio.PeerConnection] signalingState is "stable"
client:64 Successfully established call
twilio.min.js:58 [Connection] Received an error from MediaStream:
twilio.min.js:58 Object {info: Object}
client:60 Error: Error creating the answer: Failed to set local answer sdp: Called in wrong state: STATE_INPROGRESS
twilio.min.js:58 [Connection] Received HANGUP from gateway
twilio.min.js:58 [Connection] Received an error from the gateway:
twilio.min.js:58 Object {code: 31000, message: "Call is no longer valid", connection: a}
client:60 Error: Call is no longer valid
twilio.min.js:58 [Connection] Disconnecting...
twilio.min.js:58 [Twilio.PeerConnection] iceConnectionState is "closed"
twilio.min.js:58 [Twilio.PeerConnection] signalingState is "closed"

发生这种情况时,Chrome 中的标签页上的红色圆圈录音灯"仍然亮着,当您将鼠标悬停在上面时,会显示此标签页正在使用您的相机或麦克风".Twilio.Device 的状态保持忙碌",拨入的电话仍在响铃.

When this happens, the tab in Chrome has the red circle "recording light" on still, which when you hover over says "This tab is using your camera or microphone". The status of the Twilio.Device remains "busy", and the phone call that's dialling in is still ringing.

这发生在 Twilio 在其快速入门页面上提供的演示代码中,所以我对如何处理感到有些茫然?

This occurs with the demo code that Twilio provides on their quickstart page, so I'm at a bit of a loss as to how to deal with?

在 Chrome 中,很难看到发生了什么,因为您无法轻松打开和关闭麦克风访问.在 Firefox 中,如果您始终允许"麦克风,则会发生相同的行为,但是如果您单击地址栏上的麦克风图标并删除权限,那么当您再次致电并要求它时,只要您说接受一次"",一切顺利.

In Chrome, it's hard to see what's happening as you can't turn on and off mic access easily. In Firefox, the same behaviour happens if you "always allow" the mic, but if you click the mic icon on the address bar and remove permission, then when you call again and it asks for it, so long as you say "accept once", all is well.

显然,呼叫中心每次想要接听电话时都必须接受访问权限是不好的 - 有什么解决办法吗?

Clearly it's no good for a call centre to have to accept access every time they want to answer a call - any ideas how to fix it?

有一种可能的解决方法是在每次通话结束时断开 Twilio 连接并重新获取连接,但这远非理想(我也没有测试过它是否有效).

There's a possible workaround of dropping the Twilio connection and re-acquiring every time a call ends, but it's far from ideal (I haven't tested to see if it works, either).

支持页面测试显示如下(所有测试通过 OK):

The support page tests show the following (all test pass OK):

User agent: Mozilla%2F5.0+%28Macintosh%3B+Intel+Mac+OS+X+10_11_2%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F48.0.2564.82+Safari%2F537.36
Javascript: OK (version 1.6)
Browser Version: OK (chrome 48.0.2564.82)
Adobe Flash Version: OK (Shockwave Flash 20.0 r0)
[Device] Setting up PStream
[WSTransport] Opening socket
[WSTransport] attempting to connect
[Device] Destroyed eventstream.
Microphone: OK ( )
[WSTransport] Socket opened
[PStream] Setting token and publishing listen
[Device] Stream is ready
Twilio Client: OK (Device.ready)
[Twilio.PeerConnection] signalingState is "have-local-offer"
[Twilio.PeerConnection] signalingState is "stable"
Twilio Client: OK (Device.connect)
[Twilio.PeerConnection] iceConnectionState is "checking"
[Twilio.PeerConnection] iceConnectionState is "completed"
[Twilio.PeerConnection] iceConnectionState is "completed"

但我认为这是预期的 - 第二次尝试连接到客户端时出现问题:(

But I think that's as expected - the problem occurs on the second time you try to connect to the client :(

更新:

与 Twilio 支持人员进行了多次交流,这是客户端中可重现的错误,因此必须等到他们修复它.一种解决方法是在传入事件中自动应答呼叫,并在其他地方管理您的呼叫处理.

Having spoken with Twilio support quite a bit, it's a reproduceable bug in the client, so will have to wait until they fix it. A workaround of sorts is to auto-answer the call in the incoming event, and manage your call handling elsewhere.

推荐答案

答案是他们正在努力修复 Twilio 客户端中的一个错误 - 但只有在调用后使用 answer() 调用时才会发生这种情况传入事件 - 因此,如果您自动接听电话,并以其他方式进行管理,则一切正常.

The answer is that it's a bug in the Twilio Client that they're working to fix - but it only happens if you use an answer() call after the incoming event - so if you auto answer the call, and do the management some other way, all is fine.

这篇关于如果用户“始终允许",Twilio WebRTC 客户端会中断麦克风访问?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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