一种WebRTC通话的路由方法及系统与流程

文档序号:12695952阅读:378来源:国知局
一种WebRTC通话的路由方法及系统与流程

本发明属于通讯技术领域,尤其涉及以浏览器为代表的WebRTC终端发起的VoIP呼叫的智能路由技术。



背景技术:

在VoIP领域,主叫必须知道被叫的号码信息,才可以建立正确的呼叫。而在电子商务领域,传统的基于网络的商务洽谈或咨询一般是预先设置好的固定方向通道,咨询方不需要知道被咨询方的相关信息即可通过所述通道联系到对方。由于近几年WebRTC及新浏览器接口技术的逐步兴起,VoIP技术和网页开发技术中间的技术鸿沟渐渐消失,VoIP技术需要引入非依赖号码的路由方法,来完成在电子商务领域的话务智能路由。

如上所述,VoIP技术需要一种基于浏览器提供的网页浏览位置及地理位置等信息的智能路由技术,以降低VoIP技术与网页开发技术之间的融合成本,实现更为智能及准确的话务路由。另一方面也可以借助互联网广告领域基于cookie的精确推送功能,做到话务的精确路由功能及通话背景信息丰富功能。



技术实现要素:

本发明的目的在于提供一种WebRTC通话的智能路由方法,互联网信息经由VoIP承载,并被VoIP作为话务路由的制定依据,从而实现非基于号码,基于客户地理位置、语言及网页浏览历史等互联网特性信息的智能呼叫路由业务。

为了实现上述发明目的,本发明的技术方案如下:

一种WebRTC通话的智能路由方法,主要包括如下步骤:(1)WebRTC终端向地理位置信息服务器发送地理位置信息获取请求;(2)地理位置信息服务器返回所述地理位置信息获取请求的互联网IP以及该IP相关的地理位置信息给所述WebRTC终端;(3)WebRTC终端向通信服务器发送无明确被叫目的地的呼叫建立请求,在所述呼叫建立请求中携带地理位置等信息;(4)所述通信服务器解析所述呼叫建立请求携带的信息,根据预设的路由规则结合解析出的信息,将所述呼叫建立请求路由至匹配的通信业务中;(5)所述通信业务再根据业务自身的规则或设置将所述呼叫建立请求路由至匹配的VoIP终端,完成被叫目的地的选择;(6)所述VoIP终端上解析所述呼叫建立请求中携带的地理位置等信息,并将该信息有组织地显示在显示模块上;(7)所述VoIP终端结束所述呼叫建立请求发起的呼叫时,所述通信服务器将本次通信过程的详细信息包含所述地理位置信息记录至呼叫日志中。

为了与客户关系管理系统结合,提供更为完整的客户信息及客户管理功能,所述 WebRTC终端可以生成随机的客户身份识别码,记录在非易失的存储模块中并将所述识别码,添加到所述呼叫建立请求中。所述通信服务器在解析所述地理位置信息时,可以结合所述客户身份识别码,连接客户关系管理系统,建立或更新所述客户关系管理系统中的客户信息。

较佳地,所述WebRTC终端可以和其所在的网页相互配合,由所述网页记录客户的浏览足迹。由所述WebRTC终端将所述浏览足迹添加到所述呼叫建立请求中。由所述通信服务器将该浏览足迹更新到所述客户关系管理系统中。为服务专员提供更为详细的信息,以提供精准的服务及支持。

上述呼叫建立请求可以携带多种类型的客户信息,信息一:所述WebRTC终端通过所述地理位置服务器获取的地理位置信息。具体包含时区,经度,纬度,国家或地区,省或州,城市等信息;信息二:所述WebRTC终端客户的语言信息,通过浏览器接口或操作系统接口获取到客户目前正在使用的语言;信息三:所述WebRTC终端客户的客户身份识别码信息,所述WebRTC终端通过特定算法生成唯一标示所述客户的识别码,用于与所述客户关系管理系统进行客户信息备案及后续更新;信息四:WebRTC终端客户的浏览足迹信息,所述客户在基于浏览器的WebRTC终端上浏览网页时,所述网页按照特定规则记录客户的浏览路径以及在各个页面的停留时间;信息五:所述WebRTC终端客户所用设备的相关信息,如设备品牌,操作系统类型,设备配置情况等。信息种类不限于上述五种,具体使用哪几种,按照商业需求的实际情况酌情使用。

本发明方法中,WebRTC终端发起呼叫时并不需要明确指定被叫目的地,被叫目的地的选择在通信服务器上完成,这样的框架对于服务的快速变更有着巨大的优势,企业运维人员不需要修改WebRTC终端,仅配置通信服务器即可。

通过本发明方法可以实现基于地理位置,语言或浏览足迹等信息的更为智能的通话路由功能。企业客服及支持系统可以借助该功能,提供精准的服务,节省客户及客服系统的时间。为跨国跨地区企业提供全球化统一客服服务系统提供基础平台。并借助WebRTC的技术优势,降低客户的通信费用门槛,为企业省下大量通信成本及费用。

附图说明

图1为本发明具体实施例中WebRTC呼叫业务角色关系示意图;

图2为本发明具体实施例中WebRTC呼叫业务的流程图。

具体实施方式

本发明的基本原理:在WebRTC终端发起无明确被叫的呼叫时,根据一定的策略,通过扩展SIP或其他信令消息包正文或头域携带客户的地理位置或语言等信息;并在VoIP服务器收到这些信息时,通过按照配置好的信息解析规则解析所述信息中的关键部分,按照解析的结果将呼叫请求转发到对应的通信业务中,再由通信业务按照其规则将呼叫请求最终发向特定的分机,完成被叫目的地的指定。在完成被叫目的地的指定的同时,VoIP服务器还会以所述信息中的地理位置信息或客户身份识别码信息作为索引,连接所述客户关系管理系统进行客户详细资料查询或客户档案建立。并将完整的客户信息发送给被叫分机,以供被叫在接听来电前,了解该客户的相关信息及需求。

为了更清楚地说明本发明实例的技术方案,下面将结合示例图对本发明的实施进行详细的介绍,下面的描述仅仅是本发明的一些实施例。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些实施例获得本发明的其他实施方式。

图1为本发明具体实施例中WebRTC呼叫业务角色关系示意图。客户通过使用WebRTC终端向话务员发起WebRTC呼叫业务,实现本发明披露的WebRTC呼叫业务,该呼叫过程主要涉及以下角色:客户、Web服务器、VoIP服务器、地理位置服务器、客户信息服务器及话务员的业务示意图。由图可知,WebRTC呼叫业务的主业务流程为客户经由Web服务器及VoIP服务器与更为合适的话务员实现通话的过程。客户浏览相关网站时,客户浏览器访问Web服务器获取网页文件。Web服务器同时根据客户的IP地址、浏览器特征等数据,通过地理位置服务器将IP地址转换成地理位置及当地语言等信息。待客户需要联系网站服务人员时,由正在浏览该网站的WebRTC终端发起无指定被叫的WebRTC呼叫,并通过拓展SIP等信令的头域信息来携带客户的相关信息。所述客户相关信息包括但不限于客户公网IP、地理位置信息(国家、省或州、市县、当地语言及所处时区等)、客户浏览器信息(语言、操作系统、浏览器指纹、当前所处页面及本网站浏览记录等)等。

在VoIP服务器收到所述WebRTC呼叫后会解析所述信令头域信息,并与客户信息服务器通信,使用客户信息中的浏览器指纹等信息检索或建立客户的档案,从而为话务员提供更为详细的客户资料;另一方面,所述VoIP服务器根据解析出的客户信息,结合内部预先配置好的话务路由规则,计算出所述WebRTC呼叫路由及最终的被叫。最终通过扩展SIP或IAX的正文携带完整的客户信息,以便于扩展的XML格式携带客户信息,发送呼叫请求给最终的被叫。

此外,上述VoIP服务器解析收到的呼叫信令,用信令中携带的用户粗略信息来向另外一台专门存储用户信息的服务器(CRM)来查询这个客户的详细信息,比如之前就有来联系过之类的。最终合成更完整的信息。

被叫话务员的VoIP设备在收到该呼叫请求后,可以解析其中携带的扩展XML格式客户信息,在其显示模块上进行展现,帮助话务员在接起呼叫前了解对方的基本信息,以提供更好的服务。

在本发明具体实施例中,有以下几点需要说明:

由于客户信息是较为敏感的,为保护这些敏感数据,网页端及服务器会对上述数据进行加密,然后填入扩展内容中。

服务器的WebRTC呼叫路由规则与传统基于号码格式的VoIP拨号计划规则完全不同。传统的拨号计划路由规则完全基于主被叫号码的格式匹配来确定话务的路由路径。所以仅适用于主被叫起码有一方有明确号码的情况。而基于网页的WebRTC呼叫由于业务场景较为特殊,主叫往往是无法提供号码的,而被叫方向也因实际呼叫的对象不同(如目的不同:售后服务、售前咨询;区域不同,语言不同等),使得传统基于号码的被叫号码规划方案会变得复杂,且无法自然地随着网页的变化及业务的发展适应新的需求。本发明中,WebRTC呼叫路由规则的设计不再单纯基于号码,而是可以基于各种自定义的关键字,目前提供的关键字有客户公网IP、地理位置信息中的各个字段以及客户浏览器信息的各个字段等。客户可随着业务的需求继续添加自定义的关键字及其路由规则。

由于本发明中的WebRTC呼叫不需要任何鉴权,为保护VoIP服务器不易遭受拒绝服务攻击。所有的呼叫请求均经由Web服务器中转,并由Web服务器对呼叫请求内容进行加工,将客户地理位置信息添加。同时过滤掉无法匹配的呼叫请求。另外,该设计可以让网站开发时选择自定义信令来实现呼叫的请求,避免前端开发人员需要跨领域学习较为复杂的SIP / IAX等VoIP标准信令。

图2为本发明实施例WebRTC呼叫业务的流程图。由图可知,本发明具体实施方式涉及以下操作步骤:

步骤S100:客户使用浏览器访问网站所在的Web服务器,Web服务器向客户浏览器返回会话ID供后续验证用。

步骤S110:Web服务器根据HTTP请求中的公网IP地址,向地理位置服务器查询IP对应的地理位置信息。

步骤S120:地理位置服务器根据提供的IP地址检索数据库中对应的地理位置信息及对应的人文信息,如当地主要语言等。将这些数据返回给Web服务器。Web服务器收到后缓存所述数据待后续使用。

步骤S130:客户按需求点击网站上的“客服”按键,发起呼叫请求,并在请求信令头域添加客户浏览器相关信息及步骤S100中获取到的会话ID;此处的客户浏览器相关信息比如客户之前浏览了本网站的哪几个网页及产品,在哪个网页上点击的呼叫,也就是目前停留的网页的URL地址,具体实例中可以参见下方的X-GS-Web-Path字段。

步骤S140: Web服务器收到呼叫请求后,验证请求中的会话ID是否是合法ID。丢弃非法呼叫请求。对合法的请求进行呼叫信令重组,以VoIP服务器可以识别的标准信令格式进行请求的封装。具体SIP信令格式如下:

INVITE sip:WebRTC@Grandstream SIP/2.0

Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9h...NpR9;rport

From: "Hangzhou,China"<sip:webrtc@anonymous.invalid>;tag=F99...B3T

To: <sip:WebRTC@Grandstream>

Contact: "Hangzhou,China"<sips:webrtc@df7jal23ls0d.invalid;transport=wss>;impi=Hangzhou;ha1=36c5...290

Call-ID: 4b7b681a-6f5d-eb9e-56d1-eac0b7e83417

CSeq: 19447 INVITE

Content-Type: application/sdp

Content-Length: 4915

Max-Forwards: 70

User-Agent: Grandstream/WebRTC

Organization: Grandstream

X-GS-Web-Path: https://udta.sample.xx/Products/A.html

X-GS-Public-IP: Hangzhou

X-GS-Web-Language: zh-CN

X-GS-City: Hangzhou

X-GS-RegionName: Zhejiang

X-GS-Country: China

X-GS-CountryCode: CN

X-GS-Timezone: +08:00

X-GS-UserID: DE3rHCW386

(省略SDP部分)

其中的几个扩展头域解释如下:

X-GS-Web-Path: 客户当前浏览的网页路径,可以按照页面功能将呼叫路由至特定的客服小组。如产品A的网页上的呼叫路由给A产品的技术专家,而产品B的网页呼叫则路由给B产品的技术专家

X-GS-Public-IP: 客户的公网IP,视客户对隐私的重视程度携带真实IP或是其他的值

X-GS-Web-Language: 客户浏览器选择的语言

X-GS-City: 客户所在城市

X-GS-RegionName: 客户所在省或州

X-GS-Country: 客户所在国家全称

X-GS-CountryCode: 客户所在国家的ISO-2代码

X-GS-Timezone: 客户所在的时区

X-GS-UserID: 客户身份号

步骤S150: 所述VoIP服务器收到上述信令报文后,根据解析出来的客户身份号,向客户关系服务器查询客户的进一步信息。此处的客户关系服务器简称CRM,一般用于存储客户信息、服务记录及反馈等。

步骤S160:所述客户关系服务器将与所述客户身份号相关的信息以特定格式返回给所述VoIP服务器。所述相关信息包含该客户身份号最近的服务情况记录等数据。

步骤S170:所述VoIP服务器根据解析出来的客户信息以及所述客户关系服务器提供的客户详细信息,结合系统预设的智能路由规则去决策出最佳的被叫,然后将呼叫转给被叫。按照智能路由规则中针对的信息项通过正则表达式等手段在客户完整信息中取值,若取出的值与智能路由规则下的子规则匹配,则该呼叫将路由到所述子规则中设置的目标。如所述本次呼叫:

所述智能路由规则关键字为X-GS-Web-Path。并且下面的子路由规则为:

若值中包含“A.html”则呼叫路由给产品A的客服团队;

若值中包含“B.html”则呼叫路由给产品B的客服团队;

其他的情况则呼叫路由给普通的客服团队。

则跟据步骤S140中列出的信息,由于所述呼叫中X-GS-Web-Path的值中含有“A.html”,则本次呼叫需要路由给产品A的客服团队。

服务器将所述呼叫信令进行扩展,将获取到的更为详细的客户信息以xml格式在信令正文部分进行扩展。所述扩展部分与SDP部分以boundary进行分割。并将所述呼叫信令发往产品A的客服团队振铃组,号码为3000,如下例:

INVITE sip:WebRTC@Grandstream SIP/2.0

Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9h...NpR9;rport

From: "Hangzhou,China"<sip:webrtc@anonymous.invalid>;tag=F99...B3T

To: <sip:3000@192.168.111.222>

Contact: "Hangzhou,China"<sips:webrtc@df7jal23ls0d.invalid;transport=wss>;impi=Hangzhou;ha1=36c5...290

Call-ID: 4b7b681a-6f5d-eb9e-56d1-eac0b7e83417

CSeq: 19447 INVITE

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: 7380 --boundary1

Max-Forwards: 70

User-Agent: Grandstream/WebRTC

Organization: Grandstream

X-GS-Web-Path: https://udta.sample.xx/Products/A.html

X-GS-Public-IP: Hangzhou

X-GS-Web-Language: zh-CN

X-GS-City: Hangzhou

X-GS-RegionName: Zhejiang

X-GS-Country: China

X-GS-CountryCode: CN

X-GS-Timezone: +08:00

X-GS-UserID: DE3rHCW386

Content-Type: application/sdp

(省略SDP部分)

--boundary1

Content-Type: application/customer-info+xml

Content-Disposition: customer-info

<xml version="1.0" encoding="UTF-8">

<customer-info>

<bio firstname="San" lastname="LI" sex="male" birthdate="1990-08-03"/>

<job company="" occupation="marketing" post="manager"/>

<tel cellphone="11178907878" office="05713434232" fax="05712312121"/>

...省略

</customer-info>

--boundary1--

在收到所述呼叫信令后,产品A客服团队的VoIP终端会解析扩展详细客户信息及信令头域的客户信息。统一在终端的显示模块上进行显示。帮助客服在接起呼叫前做好准备,为本次呼叫的客户提供更好的服务。

步骤S180:当产品A的某位客服接起所述呼叫后,客服与客户的媒体通道接通,双方可以进行音视频的通话,也可以借助WebRTC技术进行文件及图片的推送。丰富了客服及技术支持的能力,实现了更佳的沟通效果。

在具体实施中,为了增强通讯的安全性及私密性,所述各个设备或节点之间的通信可以采用信道加密(如TLS/SSL等技术)或者使用私有信道(如VPN等)的技术手段,具体实施方案可根据具体情况选择。

以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1