一种绕过udp穿透Nat进行Voip音视频通讯的方法与流程
本发明涉及一种voip音视频通讯方法。
背景技术：
由于互联网的通讯技术的快速发展，当前的voip(voiceoverinternetprotocol)通话显得越来越流行，目前voip通讯普遍基于udp(userdatagramprotocol，用户数据报协议)协议收发音视频数据包，由于nat(networkaddresstranslation，网络地址转换)在不同网络环境下的复杂性，开发人员需要根据不同类型进行处理，尤其是端口限制圆锥型nat和对称型nat，传统需要通过ice(interactiveconnectivityestablishment互动式连接建立)框架方式进行穿透，部署比较复杂，增加了额外成本，而且通讯时候有一定的延时！在此背景下，现发明一种通过xmpp(xmpp是一种基于标准通用标记语言的子集xml的协议，它继承了在xml环境中灵活的发展性)协议绕过nat穿透进行通讯方法，以克服部署复杂，通讯延时的缺陷。
技术实现要素：
本发明要解决的技术问题，在于提供一种绕过udp穿透nat进行voip音视频通讯的方法，通过xmpp协议控制voip的发起和接听，可以绕过传统的端口限制圆锥型nat和对称型nat进行ice方式进行穿透，实现方式比较简单，无需额外部署stun和turn服务器。
本发明是这样实现的：一种绕过udp穿透nat进行voip音视频通讯的方法，其特征在于：
客户端方面，将客户端连接互联网xmpp服务器，使xmpp服务器获取客户端的实际ip地址和端口号，后续则通过该ip地址和端口号实现长时间xmpp消息体的通讯而不受到nat的限制，且xmpp消息体通过xmpp服务器在两客户端之间转发；
voip服务端方面，在客户端通过xmpp消息约定好后，xmpp服务器主动去连接音视频服务器发送udp消息，这样voip服务端就知道客户端的实际ip地址和端口号并被路由网关受信，从而绕过端口限制圆锥型nat和对称型nat，客户端不进行点对点直连而使用会议室模式，通过xmpp消息协商指令，然后通过xmpp服务器转发两端的音视频数据流，使客户端进行音视频聊天通讯。
本发明，包括通话场景和挂断场景；
所述通话场景的具体过程如下：
s11、客户端a先请求音视频服务器，获得一个空闲会议室的房间号；
s12、客户端a登入音视频服务器成功后，然后先发送一个xmpp消息体给客户端b；
s13、客户端b接受到推送消息后登入音视频服务器，进入所述s1房间号对应的会议室房间，成功后发个回执给客户端a；
s14、客户端a收到客户端b的回执后，也进入所述s1房间号对应的会议室房间；
s15、客户端a和客户端b开始进行语音或视频通话；
所述挂断场景的具体过程如下：
s21、客户端a通话中挂断；
s22、客户端b收到挂断，界面退出，然后发回执消息体；
s23、客户端a正式挂断，通话界面退出；
进一步的，所述s13中，若客户端b处于和其他人通话中，则走忙线场景，具体过程如下：
若客户端b正处和其他人通话中，此时客户端b先判断客户端a发来的xmpp消息体的id与先前先前接收到的是否重复，若是，则后台拒绝接听，并发送表示忙线中的消息体，客户端a收到客户端b的xmpp消息体后显示该用户处于忙线中。
本发明具有如下优点：是绕开传统voip通话下对于处于限制型的nat,需要通过ice一整套部署方式，减少服务端部署的复杂度，借助xmpp消息体代替通话指令，降低了额外部署stun和turn服务器，减少了成本和工作的复杂度。
附图说明
下面参照附图结合实施例对本发明作进一步的说明。
图1为本发明方法在客户端方面发起通话的执行流程图。
图2为本发明方法在客户端方面接受通话的执行流程图。
图3为本发明方法在客户端方面发起挂断通话的执行流程图。
图4为本发明方法在客户端方面接受挂断通话的执行流程图。
具体实施方式
本发明的绕过udp穿透nat进行voip音视频通讯的方法，通过xmpp协议控制voip的发起和接听，可以绕过传统的端口限制圆锥型nat和对称型nat进行ice方式进行穿透，实现方式比较简单，无需额外部署stun和turn服务器。
从客户端方面而言，本发明将客户端(本发明的客户端也叫软电话端，包括处于nat内部或者外部的客户端)连接互联网xmpp服务器，使xmpp服务器获取客户端的实际ip地址和端口号，后续则通过该ip地址和端口号实现长时间xmpp消息体的通讯而不受到nat的限制，且xmpp消息体通过xmpp服务器在两客户端之间转发；
voip服务端方面，在客户端通过xmpp消息约定好后，xmpp服务器主动去连接音视频服务器发送udp消息，这样voip服务端就知道客户端的实际ip地址和端口号并被路由网关受信，从而绕过端口限制圆锥型nat和对称型nat，客户端不进行点对点直连而使用会议室模式，通过xmpp消息协商指令，然后通过xmpp服务器转发两端的音视频数据流，使客户端进行音视频聊天通讯。
本发明，包括通话场景、挂断场景和忙线场景；
如图1和图2所示，所述通话场景的具体过程如下：
s11、客户端a先请求音视频服务器，获得一个空闲会议室的房间号，假设房间号为3001；
s12、客户端a登入音视频服务器成功后，然后先发送一个xmpp消息体给客户端b；
保障机制(重发,10秒1次)
结束条件：a收到b的回执后结束重发或者6次结束重发或者接收方正在通话忙线中结束重发
<messageid＝"1"to＝"a@cbank"from＝"b@cbank/mobile"type＝"normal">
<body>{
"type":"88",
"action":"voipcall",
"from":"b@cbank",
"fromvoip":"bvoip",
"fromname":"bname",
"time":"timestamp",
"title":"有一个新来电",
"conferencenum":"3001",
"isvideoconference":"0"
}//0语音1视频
</body>
</message>。
s13、客户端b接受到推送消息(如果是正在通话走忙线场景)，然后登入音视频服务器，进入所述s1房间号对应的会议室房间，成功后发个回执给客户端a；
重发机制，15秒一次
结束条件：收到a的sip通话后结束重发或者4次结束重发；
<messageid＝"1"to＝"b@cbank"from＝"a@cbank/mobile"type＝"normal">
<body>{type":"88","action":"voipreceive"}
</body>
</message>
备注：b要做类似去重处理，如果收到a的2次同一个消息，不能回忙线中(voipbusy)，要判断前后消息的id是否一样，一样的话，不处理，不一样的话回忙线中。
s14、客户端a收到客户端b的回执后，也进入所述s1房间号对应的会议室房间；
s15、客户端a和客户端b开始进行语音或视频通话；
如图3和图4所示，所述挂断场景的具体过程如下：
s21、客户端a通话中挂断；
保障机制(重发，6秒一次)
结束条件,收到接受方的消息体时候结束重发，
<messageid＝"2"to＝"b@cbank"from＝"a@cbank/mobile"type＝"normal">
<body>{type":"88","action":"voiphangup"}
</body>
</message>。
s22、客户端b收到挂断，界面退出，然后发回执消息体；
<messageid＝"2"to＝"a@cbank"from＝"b@cbank/mobile"type＝"normal"><body>{type":"88","action":"voiphangupreceive"}</body></message>。
s23、客户端a正式挂断，通话界面退出；
所述忙线场景的具体过程如下：
s31、客户端a先请求音视频服务器，获得一个空闲会议室的房间号，假设房间号为3001；
s32、客户端a登入音视频服务器成功后，然后先发送一个xmpp消息体给客户端b；
s33、客户端b如果正处和其他人通话中，此时客户端b先判断客户端a发来的消息体的id是否重复，如果重复然后后台拒绝接听，并发送表示忙线中的消息体：
<messageid＝"2"to＝"b@cbank"from＝"a@cbank/mobile"type＝"normal">
<body>{type":"88","action":"voipbusy"}
</body>
</message>。
综上所述，本发明通过xmpp协议控制voip的发起和接听，可以绕开传统voip通话下对于处于限制型的nat,需要通过ice一整套部署方式，减少服务端部署的复杂度，借助xmpp消息体代替通话指令，实现方式比较简单，无需额外部署stun和turn服务器，降低了额外部署stun和turn服务器的成本，减少了成本和工作的复杂度。
虽然以上描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。
- 还没有人留言评论。精彩留言会获得点赞！