接到来电时打开网页

发布于 2024-09-14 09:19:20 字数 320 浏览 11 评论 0原文

我们有一个 Web 应用程序,人们问我们是否可以在他们的 PBX 上接到来电时弹出屏幕。

我认为最简单的方法是在系统托盘中放置一个小应用程序,并等待使用 TAPI 或 TSAPI 的调用。当有电话进来时,它会打开一个指向配置的 URL 的网页,并将呼叫者 ID 作为参数传递。

这样的应用程序存在吗?

PS任何人都知道简单计算机电话协议发生了什么

We have a web application, and people have asked us if we can pop up screens when they get an incoming call on their PBX.

I think that the easiest way to do this would be to have a small app that sat in the system tray and waited for a call using TAPI or TSAPI. When a call comes in, it would open a web page to a configured URL, passing the caller ID as a parameter.

Does such an application exist somewhere?

P.s. anyone know what happened to the Simple Computer Telephony Protocol

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一世旳自豪 2024-09-21 09:19:20

这在很大程度上取决于所使用的 PBX - 我使用过 Avaya 和 CallMedia 服务器。这两家公司都提供了一个小型桌面客户端和一个可以在代码中引用的 DLL。

最大的问题是一旦系统托盘应用程序收到事件就通知网页。启动浏览器可能会很慢,并且对于呼叫处理而言并不是良好的用户体验。更好的是保持浏览器打开并接收事件。

我工作的公司使用了一些相当过时的技术,所以他们有:

PBX --(XML)-- PBX 系统托盘客户端 --(COM)-- 我们自己的桌面app --(COM)-- 嵌入页面中的 ActiveXControl --(Javascript)-- 适当处理事件的网站框架 正如

你所看到的,它相当长且复杂 - 一个更优雅的方法是有一个silverlight/类似的应用程序嵌入在从系统托盘客户端接收事件的页面上(通过网络服务或类似的?)

您还需要解决以下问题:a)打开多个页面 - 是否所有页面都获取事件? b) 以后更换 PBX 不需要完全重写。

当我离开那家公司时,我们正在实施一种机制,让我们的应用程序直接通过 XML 接收来自 PBX 的消息。通过 2-Way WCF 在我们的桌面应用程序中注册的任何/所有网页上的 Silverlight 控件。然后,我们让桌面应用程序将适当的事件发送到适当的页面。

需要考虑的其他一些事项:您要处理混合渠道吗?即可以处理电子邮件阻止来电事件吗?如果是这样,您需要某种双向通信来表示“拒绝呼叫...”。您还需要注意代理的电话机所处的状态 - 如果您在完成保存数据之前进入“可用”状态,则您可能会在记录所有内容之前浏览掉。另外,根据我的经验,客服人员真的很乐意按下电话机上的按钮,而不是您的应用程序中的按钮 - 因此您需要处理意外的状态变化。

还要考虑转接呼叫 - 大多数现代 PBX 允许以 ID 与呼叫关联的方式进行呼叫转接 - 因此,如果是内部转接,接收者的屏幕可以显示所有呼叫注释/等。

如果您能澄清什么是 PBX/等,我可以提供更多信息。您正在使用以及需要处理哪些事件

我建议您至少处理:
来电铃声响起,
电话已接听,
电话掉线,
呼叫已转接

,您应该能够提出:
接听电话,
拨打电话,
挂断电话,
转接呼叫(热转和冷转,如果是内部数据,则可以选择使用数据)

当然,这对于您的解决方案来说可能有点过分了:)

编辑:我忘记补充一点,我们的解决方案还处理记录代理的开/关当他们登录到网络应用程序时,电话集的信息 - 这提供了非常好的用户体验,但需要处理所有登录/注销变量以及维护用户->扩展名的查找表#

It depends a lot on the PBX in use - I've work with Avaya and CallMedia servers. Both of those companies provided a small desktop client and a DLL which can be referenced from within code.

The biggest problem is informing the web page once the system tray app gets an event. Launching a browser can be slow and is not a good user experience for call handling. Better is to keep a browser open and receive events..

The company I worked for used some pretty out-dated tech so they had:

PBX --(XML)-- PBX System Tray Client --(COM)-- Our own desktop app --(COM)-- An ActiveXControl embedded in the page --(Javascript)-- The website framework which handled the event as appropriate

As you can see it was quite long and convoluted - A more elegant approach would be to have a silverlight/similar app embedded on the page which receives events from the system tray client (via a web service or similar?)

You also need to address the question of a) multiple pages open - do all get the events? and b) swapping PBX at a later date shouldn't require a complete re-write.

As I left that company we were implementing a mechanism where our app received messages from the PBX directly via XML. Silverlight controls on any/all web pages registered with our desktop app via 2-Way WCF. We then had our desktop app send the appropriate events to the appropriate page.

Some other things to consider: Are you going to be handling mixed-channel? ie can handling an email block an incoming call event? If so, you need some sort of 2-way comms to say "Rejecting call...". You also need to be careful about what State the agents' telset is in - If you go to an "available" state before you finish saving data, you can potentially browse away before recording everything. Also, in my experience, agents are really happy to press the buttons on the telset rather than in your app - so you need to handle unexpected status changes.

Also consider transferring calls - most modern PBX allow a call transfer to occur in such a way that an id is associated with the call - so if it's an internal transfer, the recipients' screen can show all call notes/etc.

I can provide more info if you can clarify what PBX/etc. you're using and what events you need to handle

Events I'd recommend you handle at a minimum:
Call ringing,
Call answered,
Call Dropped,
Call Transferred

and you should be able to raise:
Accept Call,
Place Call,
Drop Call,
Transfer Call (Hot and Cold transfers, optionally with data if it's internal)

Of course this may be overkill for your solution :)

Edit: I forgot to add that our solution also handled logging the agents on/off of the telset when they logged into the web app - This gave a really nice user experience but required handling all the logon/logoff variables as well as maintaining a lookup table of user->extension #

迎风吟唱 2024-09-21 09:19:20

NCID(网络呼叫者 ID) 是一个 Sourceforge 项目,似乎是我想要的东西,但它依赖于 Linux 服务器,并且似乎仅支持来自连接到串行端口的调制解调器的来电显示,或者通过嗅探通过服务器的以太网接口的 SIP 数据包。它不支持任何带有 TAPI 或类似系统的 PBX 系统,因为它仅在 Linux 上运行。

连接到服务器 NCIDpop 的客户端应用程序正是我想要的 - 它可以使用 URL 字符串来查找号码,并在单击它时打开一个网页。

这对我来说并不完全是答案,但可能对其发现这个问题的其他人有用。

NCID (Network Caller ID) is a Sourceforge project that seems to be the sort of thing I want, but it depends on a linux server, and only seems to support Caller ID from a modem connected to a serial port, or by sniffing SIP packets passing over the Ethernet interface of the server. It doesn't supoprt any PBX systems with TAPI or similar because it runs on Linux only.

The client app that connects to the server NCIDpop does exactly what I want - it can take a URL string to go and look up a number with, and open a web page when you click on it.

It's not quite the answer for me, but might be useful to others finding this question.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文