CN106210148A - 实时通话处理方法及装置 - Google Patents

Abstract

本发明实施例提供了一种实时通话处理方法及装置。该方法中，第一终端的浏览器在建立与车载设备的第一通信连接以及与第二终端的浏览器的第二通信连接之后，能够在接收车载设备发送的音/视频数据包时，将其发送至第二终端的浏览器，在接收到第二终端发送的音/视频数据包时，将其发送至车载设备，从而实现车载设备与其他终端之间进行视频或音频通话，有效扩大浏览器的使用范围，使其能够应用于车载领域中。

Description

实时通话处理方法及装置

技术领域

本发明实施例涉及智能终端技术领域，尤其涉及一种实时通话处理方法及装置。

背景技术

随着信息技术的进步和居民收入的增加，智能终端的普及率大大提高。目前的智能终端能够支持越来越多的功能，使得人们可以使用智能终端进行各式各样的操作。其中，通过智能终端中的浏览器访问网页，是人们获取各类信息的常用手段之一。人们只需在浏览器的搜索栏中输入待访问网页的网址，浏览器就可以通过移动网络访问发布该网页内容的网站服务器，从而使得人们可以通过浏览器浏览该网页发布的内容。

现有的浏览器已经不满足于单纯的包含浏览网页的功能，例如还可以进行视频或语音聊天等。然而，在实现本发明实施例的过程中发明人发现，现有的浏览器只能支持终端与终端之间的视频或语音通话连接，还无法支持其他设备例如车载设备与终端之间进行通话连接，从而限制了浏览器的应用范围。

发明内容

本发明实施例提供一种实时通话处理方法及装置，用以解决现有的浏览器无法支持车载设备与终端之间进行通话连接的缺陷。

第一方面，本发明提供了一种实时通话处理方法，包括：

第一终端的浏览器在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；

第一终端的浏览器根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；

第一终端的浏览器在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

可选地，所述方法还包括：

第一终端的浏览器在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；

其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

可选地，所述方法还包括：

第一终端的浏览器若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

可选地，所述根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接，包括：

第一终端的浏览器向所述第二终端浏览器所连接的实时通话服务器发送鉴权请求消息；

第一终端的浏览器在接收到实时通话服务器返回的鉴权通过的响应消息后，登录所述实时通话服务器；

第一终端的浏览器与登录到所述实时通话服务器的第二终端的浏览器通过所述实时通话服务器协商音/视频编解码方案；

在协商成功后，第一终端的浏览器基于webRTC与所述第二终端的浏览器建立第二通信连接。

可选地，所述音视频编解码方案为所述WebRTC支持的I420/VP8编解码方案。

第二方面，本发明实施例还提供了一种实时通话处理装置，应用于浏览器中，包括：

连接单元，用于在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；还用于根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；

通信单元，用于在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；还用于在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

可选地，所述通信单元，还用于在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；

其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

可选地，所述通信单元，还用于若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

可选地，所述连接单元，还用于：

向所述第二终端浏览器所连接的实时通话服务器发送鉴权请求消息；

在接收到实时通话服务器返回的鉴权通过的响应消息后，登录所述实时通话服务器；

与登录到所述实时通话服务器的第二终端的浏览器通过所述实时通话服务器协商音/视频编解码方案；

在协商成功后，基于webRTC与所述第二终端的浏览器建立第二通信连接。

可选地，所述音视频编解码方案为所述WebRTC支持的I420/VP8编解码方案。

本发明实施例提供的实时通话处理方法及装置中，第一终端的浏览器在建立与车载设备的第一通信连接以及与第二终端的浏览器的第二通信连接之后，能够在接收车载设备发送的音/视频数据包时，将其发送至第二终端的浏览器，在接收到第二终端发送的音/视频数据包时，将其发送至车载设备，从而实现车载设备与其他终端之间进行视频或音频通话，有效扩大浏览器的使用范围，使其能够应用于车载领域中。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的一种实时通话处理方法实施例流程图；

图2为图1示出的一种实时通话处理方法的信令交互实施例示意图；

图3为图1示出的步骤S102的具体方法实施例流程图；

图4为本发明提供的一种实时通话处理装置实施例结构示意图；

图5为本发明提供的一种实时通话处理实体装置实施例结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

第一方面，本发明实施例提供了一种实时通话处理方法，如图1所示，包括：

S101、第一终端的浏览器在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；

也就是说，第一终端的浏览器在建立与车载设备的第一通信连接之后，实时检测车载设备发送的消息，并在接收到车载设备的实时通话请求时，执行下一步的操作。

其中，这里的第一终端的浏览器可以通过多种方式与车载设备建立连接，例如可以基于数据线进行连接，也可以通过WIFI网络、蜂窝网络、蓝牙等方式进行连接，本发明实施例对此不作具体限定。当然还可以通过其他方式，本发明实施例对此也不作具体限定。

S102、第一终端的浏览器根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；

其中，这里的WebRTC(Web Real-Time Communication)也被称作是网页实时通信，它是一种可以支持网页浏览器进行实时语音对话或视频对话的技术。网页浏览器只需提供简单的Java script(Java语言脚本)即可实现实时通话的目的，因此实时通话技术具有简单易实现的特点。此外，实时通话技术还适于多种操作系统平台，同时还能够支持跨平台操作。在本发明实施例中，这里的实时通话技术主要应用于Android操作平台下，由Android操作平台中的浏览器提供Java script进行实时的通话连接。

因此，第一终端的浏览器在接收到实时通话请求后，可以基于webRTC与第二终端的浏览器建立第二通信连接，从而进行下一步的通信。

S103、第一终端的浏览器在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

也就是说，在建立连接之后，若第一终端的浏览器通过第一通信连接，接收到车载设备发送的音/视频数据包，则认为车载设备预向第二终端的浏览器发送数据。此时第一终端浏览器可以通过步骤S101中建立的第二通信连接将从车载设备接收到的音/视频数据包发送至第二终端的浏览器，以使第二终端的浏览器调用第二终端的播放器播放该音/视频数据包，从而第二终端就可以看到由车载设备传来的画面及声音。

类似地，若第一终端浏览器通过第二通信连接，接收到由第二终端的浏览器发送的音/视频数据包时，则认为第二终端预向车载设备发送数据。此时，第一终端浏览器不会调用自身的播放器播放该音/视频数据包，而是通过第一通信连接将这一音/视频数据包发送至车载设备，以使车载设备调用自身的播放器播放该音/视频数据包，从而车载设备就可以看到由第二终端传来的画面及声音。

不难理解的是，由于车载设备与第二终端进行的是实时视频通话，因此上述两个过程可以同时进行，使得车载设备以及第二终端能同时接收到对方的音视频数据，并同时向对方发送音视频数据，从而保证实时通话的进行。

本发明实施例提供的实时通话处理方法中，第一终端的浏览器在建立与车载设备的第一通信连接以及与第二终端的浏览器的第二通信连接之后，能够在接收车载设备发送的音/视频数据包时，将其发送至第二终端的浏览器，在接收到第二终端发送的音/视频数据包时，将其发送至车载设备，从而实现车载设备与其他终端之间进行视频或音频通话，有效扩大浏览器的使用范围，使其能够应用于车载领域中。

为便于理解本发明实施例提供的实时通话处理方法的各个终端之间的交互过程，下面结合附图2对各个终端的交互过程进行详细说明。

当车载设备预与第二终端建立视频通话时，由于不能之间建立连接，因此需要借助第一终端浏览器。因此，车载设备可以向第一终端浏览器发送第一通信连接请求，第一终端浏览器在接收到这一请求后向车载设备回复第一通信连接响应，从而建立与车载设备之间的第一通信连接。在车载设备与第一终端浏览器建立连接之后，若第一终端浏览器接收到车载设备发送的实时通话请求时，则认为该车载设备预与第二终端进行实时通话，此时第一终端浏览器首先根据这一请求，向第二终端浏览器发送第二通信连接建立请求。第二终端浏览器在接收到建立请求后，会向第一终端浏览器返回第二通信连接建立响应，从而建立与第一终端浏览器之前的第二通信连接。至此，车载设备与第一终端浏览器、第一终端浏览器与第二终端浏览器的连接已经建立完毕。

当第一终端浏览器接收到车载设备发送的音/视频数据包时，则将该音/视频数据包时转发至第二终端浏览器，以使第二终端能够看见车载设备采集的影像；当第一终端浏览器接收到第二终端浏览器发送的音/视频数据包时，则将该音/视频数据包时转发至车载设备，以使车载设备能够看见第二终端采集的影像，实现车载设备与第二终端的实时通话连接。

在具体实施时，上述方法实施例中的步骤S102可以有多种实现方式，下面对其中一种可选的实施方式进行详细说明。如图3所示，步骤S102可以具体包括：

S1021、第一终端的浏览器向所述第二终端浏览器所连接的实时通话服务器发送鉴权请求消息；

为便于理解，首先解释一下鉴权请求的概念。

鉴权请求，是一种在经过HTTP鉴权挑战的过程中发出的请求。而鉴权挑战(Challenge response authentication mechanism)是一种鉴权模式，其请求响应顺序具体如下：a)客户端发送“无鉴权”请求给服务器；b)服务器给客户端返回401(Unauthorized，意为未经授权的)，并附上服务器需要的鉴权方式(包括基本鉴权或摘要鉴权)以及其他信息；c)客户端基于服务器返回的信息重新组织请求消息，并带上鉴权信息再次发送请求。

也就是说，第二终端浏览器此时可以连接在某一实时通话平台上，若第一浏览器预与第二终端浏览器进行连接，则首先需要登录这一实时通话平台。因此第一终端浏览器会向该实时通话平台发送用于请求登录的鉴权请求，以使该实时通话平台对第一终端浏览器进行认证。

S1022、第一终端的浏览器在接收到实时通话服务器返回的鉴权通过的响应消息后，登录所述实时通话服务器；

也就是说，在实时通话平台对第一终端浏览器进行了认证并认证通过之后，向第一终端浏览器返回鉴权通过的消息，此时第一终端浏览器就可以登陆实时通话平台中。

在实际应用中，在第一终端浏览器登录了该实时通话平台之后，一般地会首先更新订阅信息。

其中，这里的更新订阅信息也被称为是更新subscribe订阅信息，subscribe订阅信息是基于订阅发布模式的一种信息。而订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使他们能够自动更新自己的状态。更新订阅信息可以被通俗的理解为，用户在每一次登录聊天软件的时候，聊天软件中好友的信息都会被更新。而用户自身的信息被更新时，其在好友的聊天软件上显示的信息也会被更新。

S1023、第一终端的浏览器与登录到所述实时通话服务器的第二终端的浏览器通过所述实时通话服务器协商音/视频编解码方案；

显然，只有第一终端的浏览器与第二终端的浏览器均使用统一的音/视频编解码方案对传输的音/视频数据进行编码，才能保证传输的数据可以被相互识别，因此第一终端的浏览器此时需要与第二终端的浏览器对音/视频编解码方案进行协商。

其中，这里的音/视频编解码方案可以为WebRTC支持的I420/VP8编解码方案。当然，还可以根据实际的传输情况选择其他WebRTC支持的编码方式，本发明实施例对此不作具体限定。

S1024、在协商成功后，第一终端的浏览器基于WebRTC与所述第二终端的浏览器建立第二通信连接。

在协商达成之后，第一终端的浏览器就可以通过该实时通话平台，并基于WebRTC技术与第二终端建立第二通信连接，从而为下一步的数据传输做好准备。

不难理解的是，步骤S102通过这样的鉴权挑战可以加强连接的安全性，确保连接至实时通话平台的终端均为安全可靠的终端，避免车载设备通过第一终端与不安全的设备进行视频或音频通话，为用户的信息安全提供了保障。

在具体实施时，本发明实施例提供的方法还可以包括：

S103’、第一终端的浏览器在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；

其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

具体来说，在音/视频数据包的交互过程中，第一终端浏览器为了告知车载设备以已经接受到上一个第二终端的浏览器的音/视频数据包，或为了告知第二终端的浏览器以已经接受到上一个车载设备的音/视频数据，需要向车载设备或第二终端浏览器发送数据包的确认信息。而这一确认信息如果在接收到每一帧数据包之后单独发送，势必会使得交互过程复杂化。因此，本发明实施例提供的方法还可以在发送当前音/视频数据包的同时，还传输用于表示已成功接收上一音/视频数据包的确认信息，使得车载设备或第二终端浏览器在接收到下一数据包的同时也可以接收到上一数据包的确认信息，从而能够简化交互流程，有效提升数据交互的效率，提高通话的质量。

进一步地，步骤S103’的基础上，为了能够在带宽不足时优先保证音频通话的质量，本发明实施例提供的方法还可以包括：

S103”、第一终端的浏览器若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

具体来说，在正常的环境下，第一终端的浏览器在向车载设备或者第二终端的浏览器发送数据包的过程中，会将音频数据以及视频数据一并发送给对方。然而在某些网络不好的环境下，若第一终端的浏览器检测获知通信连接的网络带宽小于预设值，则认为网络的带宽有限，不能够满足同时传输高质量视频数据和音频数据的传输要求，这时为了保证通话不被打断，需要优先保证音频的通话质量。因此此时第一终端的浏览器会丢弃待发送的音/视频数据包中的视频帧数据，保证音频数据优先传输。在这种情况下，虽然车载设备一侧以及第二终端侧均无法看见连贯流畅的视频画面，但是语音信号的交互还是可以顺畅进行的。

可以理解的是，上述这种丢弃视频帧数据的情况只是在网络状况不好时的一种过渡方式，在网络状况恢复时，也即检测获知通信连接的网络带宽大于或等于预设值时，第一终端的浏览器会保留视频帧数据，从而恢复为正常的高清流畅的通话。

第二方面，本发明实施例提供了一种实时通话处理装置，如图2所示，包括连接单元201以及通信单元202。

其中，连接单元201用于在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；还用于根据实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；通信单元202用于在接收到车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到第二终端的浏览器；还用于在通过第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将音/视频数据包发送至车载设备。

具体来说，连接单元201在建立与车载设备的第一通信连接之后，实时检测车载设备发送的消息，并在接收到车载设备的实时通话请求时，基于webRTC与第二终端的浏览器建立第二通信连接。在建立连接之后，若通信单元202通过第一通信连接接收到车载设备发送的音/视频数据包，则认为车载设备预向第二终端的浏览器发送数据。此时通信单元202可以基于第二通信连接将从车载设备接收到的音/视频数据包发送至第二终端的浏览器，以使第二终端的浏览器调用第二终端的播放器播放该音/视频数据包，从而第二终端就可以看到由车载设备传来的画面及声音。

类似地，通信单元202通过第二通信连接接收到由第二终端的浏览器发送的音/视频数据包时，则认为第二终端预向车载设备发送数据。此时，通信单元202不会调用自身的播放器播放该音/视频数据包，而是通过第一通信连接将这一音/视频数据包发送至车载设备，以使车载设备调用自身的播放器播放该音/视频数据包，从而车载设备就可以看到由第二终端传来的画面及声音。

不难理解的是，由于车载设备与第二终端进行的是实时视频通话，因此通信单元202可以同时执行上述两个过程，使得车载设备以及第二终端能同时接收到对方的音视频数据，并同时向对方发送音视频数据，从而保证实时通话的进行。

本发明实施例提供的实时通话处理装置中，在连接单元201建立与车载设备的第一通信连接以及与第二终端的浏览器的第二通信连接之后，通信单元202能够在接收车载设备发送的音/视频数据包时，将其发送至第二终端的浏览器，在接收到第二终端发送的音/视频数据包时，将其发送至车载设备，从而实现车载设备与其他终端之间进行视频或音频通话，有效扩大浏览器的使用范围，使其能够应用于车载领域中。

在具体实施时，连接单元201可以采用下述方式建立与第二终端浏览器之间的第二通信连接，具体包括：在接收到实时通话请求后，第一终端的浏览器向第二终端浏览器所连接的实时通话平台发送鉴权请求；在接收到实时通话平台返回的鉴权通过的消息后，登录实时通话平台；在登录了该平台之后，开始与第二终端的浏览器协商音/视频编解码方案；在协商成功后，连接单元201可以基于webRTC与第二终端的浏览器建立第二通信连接。

不难理解的是，连接单元201通过这样的鉴权挑战与第二终端的浏览器建立连接可以加强连接的安全性，确保连接至实时通话平台的终端均为安全可靠的终端，避免车载设备通过第一终端与不安全的设备进行视频或音频通话，为用户的信息安全提供了保障。

在具体实施时，通信单元202还用于在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

具体来说，在音/视频数据包的交互过程中，通信单元202为了告知车载设备以已经接受到上一个第二终端的浏览器的音/视频数据包，或为了告知第二终端的浏览器以已经接受到上一个车载设备的音/视频数据，需要向车载设备或第二终端浏览器发送数据包的确认信息。而这一确认信息如果在接收到每一帧数据包之后单独发送，势必会使得交互过程复杂化。因此，通信单元202在发送当前音/视频数据包的同时，还传输用于表示已成功接收上一音/视频数据包的确认信息，使得车载设备或第二终端浏览器在接收到下一数据包的同时也可以接收到上一数据包的确认信息，从而能够简化交互流程，有效提升数据交互的效率，提高通话的质量。

进一步地，通信单元202还用于若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

具体来说，在正常的环境下，通信单元202在向车载设备或者第二终端的浏览器发送数据包的过程中，会将音频数据以及视频数据一并发送给对方。然而在某些网络不好的环境下，若通信单元202检测获知通信连接的网络带宽小于预设值，则认为网络的带宽有限，不能够满足同时传输高质量视频数据和音频数据的传输要求，这时为了保证通话不被打断，需要优先保证音频的通话质量。因此此时第一终端的浏览器会丢弃待发送的音/视频数据包中的视频帧数据，保证音频数据优先传输。在这种情况下，虽然车载设备一侧以及第二终端侧均无法看见连贯流畅的视频画面，但是语音信号的交互还是可以顺畅进行的。

可以理解的是，上述这种丢弃视频帧数据的情况只是在网络状况不好时的一种过渡方式，在网络状况恢复时，也即通信单元202检测获知通信连接的网络带宽大于或等于预设值时，通信单元202将会保留视频帧数据，从而恢复为正常的高清流畅的通话。

由于本实施例所介绍的实时通话处理装置为可以执行本发明实施例中的实时通话处理方法的装置，故而基于本发明实施例中所介绍的实时通话处理方法，本领域所属技术人员能够了解本实施例的实时通话处理装置的具体实施方式以及其各种变化形式，所以在此对于该实时通话处理装置如何实现本发明实施例中的实时通话处理方法不再详细介绍。只要本领域所属技术人员实施本发明实施例中实时通话处理方法所采用的装置，都属于本申请所欲保护的范围。

图5为本发明实时通话处理装置的实体结构示意图。如图5所示，该实时通话处理装置包括：

处理器(processor)51、存储器(memory)52和总线53，其中，处理器51和存储器52通过总线53完成相互间的通信。处理器51可以调用存储器52中的逻辑指令，以执行如下方法：

在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

不难理解的是，上述实施例中的举例说明只是为了便于更好地理解本发明实施例提供的方法或装置，并不能构成对本发明的具体限定。且上述的各个优选实施方式之间不会相互影响，各个优选实施方式之间的任意组合所得到的方案均应该落入本发明的保护范围。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种实时通话处理方法，其特征在于，包括：

第一终端的浏览器在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；

第一终端的浏览器根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；

第一终端的浏览器在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第一终端的浏览器在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；

其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

第一终端的浏览器若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

4.根据权利要求1所述的方法，其特征在于，所述根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接，包括：

第一终端的浏览器向所述第二终端浏览器所连接的实时通话服务器发送鉴权请求消息；

第一终端的浏览器在接收到实时通话服务器返回的鉴权通过的响应消息后，登录所述实时通话服务器；

第一终端的浏览器与登录到所述实时通话服务器的第二终端的浏览器通过所述实时通话服务器协商音/视频编解码方案；

在协商成功后，第一终端的浏览器基于WebRTC与所述第二终端的浏览器建立第二通信连接。

5.根据权利要求4所述的方法，其特征在于，所述音视频编解码方案为所述WebRTC支持的I420/VP8编解码方案。

6.一种实时通话处理装置，应用于浏览器中，其特征在于，包括：

连接单元，用于在建立与车载设备的第一通信连接之后，接收车载设备发送的实时通话请求；还用于根据所述实时通话请求并基于webRTC建立与第二终端的浏览器的第二通信连接；

通信单元，用于在接收到所述车载设备发送的音/视频数据包时，通过所建立的第二通信连接发送到所述第二终端的浏览器；还用于在通过所述第二通信连接接收到第二终端的浏览器发送的音/视频数据包时，将所述音/视频数据包发送至所述车载设备。

7.根据权利要求6所述的装置，其特征在于，

所述通信单元，还用于在向通信连接的对端发送当前音/视频数据包的同时，还发送用于表示本方已成功接收上一个音/视频数据包的确认信息；

其中，所述通信连接的对端包括车载设备和第二终端的浏览器。

8.根据权利要求6或7所述的装置，其特征在于，

所述通信单元，还用于若检测获知所述第一通信连接和/或第二通信连接的网络带宽小于预设值，则丢弃待发送的所述音/视频数据包中的视频帧数据。

9.根据权利要求6所述的装置，其特征在于，所述连接单元，还用于：

向所述第二终端浏览器所连接的实时通话服务器发送鉴权请求消息；

在接收到实时通话服务器返回的鉴权通过的响应消息后，登录所述实时通话服务器；

与登录到所述实时通话服务器的第二终端的浏览器通过所述实时通话服务器协商音/视频编解码方案；

在协商成功后，基于webRTC与所述第二终端的浏览器建立第二通信连接。

10.根据权利要求9所述的装置，其特征在于，所述音视频编解码方案为所述WebRTC支持的I420/VP8编解码方案。