sip命令与音视频rtp通话完整流程分析
2014-10-05 20:31
639 查看
转载地址:http://blog.chinaunix.net/uid-15063109-id-132137.html
根据asterisk的代码,推测出sip server的工作流程如下:
1 客户端A通过sip发INVITE时,带的是内网IP和端口。
2 服务器收到后,转发给客户端B时,先创建两个音视频端口port1,port2,加到客户端A sdp中,然后发给B。
3 B收到后,肯定是同意了.如果拒绝,以下就不走了。
4 B本地也创建两个端口,连接port1,port2,带stun协议,返回自己的公网IP和端口。(这一步可选)
5 B向服务器回复同时,sdp上带本地的IP和端口。(这一步必须)
6 服务器收到B同意的回复后,再创建两个端口port3,port4,同时加到sdp中,返回给客户端A。
7 客户端A收到sdp后,得到其中的两个端口,然后本地也创建两个端口,分别向服务器的两个端口发数据,(也可以直接向对方的IP和端口发,但对方是内网的,可能收到,也可能收不到,稍后再讨论怎么P2P)。
8 客户端B应该也要创建两个端口,向服务器的端口发数据。(如果执行过4,这一步直接发数据就行了)。
9 因为端口是一一对应关系,服务器端根据端口号可以知道是哪个用户发来的,并发往表现哪里的。
10 用户发bye,或掉线,服务器通知对方结束会话,同时close掉这4个端口。
以上,服务器创建rtp端口的同时,还要创建rtcp端口。
上面的流程是服务器直接在两点间中转,不包括经过多服务器间流转。
如果要做到两客户端之间直接点对点,AB双方的音视频端口,应该先连stun,取到自己的外网IP和端口后,再发INVITE,这时SDP中带的是自己的外网IP和端口,双方直接传很大可能是收的到的。
大致流程应该是这样的,可能还有些出入,毕竟是看代码得出的结论,不是看RFC协议。
只能说发明SIP和RTP的人,大脑复杂度远超普通人。当初以为HTTP已经够麻烦的了,不过人家也不过只用了一个端口就可以传所有数据。rtp的创始人应该是电信背景,可能认为每个端口号相当于电信中的每一路通话了
根据asterisk的代码,推测出sip server的工作流程如下:
1 客户端A通过sip发INVITE时,带的是内网IP和端口。
2 服务器收到后,转发给客户端B时,先创建两个音视频端口port1,port2,加到客户端A sdp中,然后发给B。
3 B收到后,肯定是同意了.如果拒绝,以下就不走了。
4 B本地也创建两个端口,连接port1,port2,带stun协议,返回自己的公网IP和端口。(这一步可选)
5 B向服务器回复同时,sdp上带本地的IP和端口。(这一步必须)
6 服务器收到B同意的回复后,再创建两个端口port3,port4,同时加到sdp中,返回给客户端A。
7 客户端A收到sdp后,得到其中的两个端口,然后本地也创建两个端口,分别向服务器的两个端口发数据,(也可以直接向对方的IP和端口发,但对方是内网的,可能收到,也可能收不到,稍后再讨论怎么P2P)。
8 客户端B应该也要创建两个端口,向服务器的端口发数据。(如果执行过4,这一步直接发数据就行了)。
9 因为端口是一一对应关系,服务器端根据端口号可以知道是哪个用户发来的,并发往表现哪里的。
10 用户发bye,或掉线,服务器通知对方结束会话,同时close掉这4个端口。
以上,服务器创建rtp端口的同时,还要创建rtcp端口。
上面的流程是服务器直接在两点间中转,不包括经过多服务器间流转。
如果要做到两客户端之间直接点对点,AB双方的音视频端口,应该先连stun,取到自己的外网IP和端口后,再发INVITE,这时SDP中带的是自己的外网IP和端口,双方直接传很大可能是收的到的。
大致流程应该是这样的,可能还有些出入,毕竟是看代码得出的结论,不是看RFC协议。
只能说发明SIP和RTP的人,大脑复杂度远超普通人。当初以为HTTP已经够麻烦的了,不过人家也不过只用了一个端口就可以传所有数据。rtp的创始人应该是电信背景,可能认为每个端口号相当于电信中的每一路通话了
根据asterisk的代码,推测出sip server的工作流程如下:
1 客户端A通过sip发INVITE时,带的是内网IP和端口。
2 服务器收到后,转发给客户端B时,先创建两个音视频端口port1,port2,加到客户端A sdp中,然后发给B。
3 B收到后,肯定是同意了.如果拒绝,以下就不走了。
4 B本地也创建两个端口,连接port1,port2,带stun协议,返回自己的公网IP和端口。(这一步可选)
5 B向服务器回复同时,sdp上带本地的IP和端口。(这一步必须)
6 服务器收到B同意的回复后,再创建两个端口port3,port4,同时加到sdp中,返回给客户端A。
7 客户端A收到sdp后,得到其中的两个端口,然后本地也创建两个端口,分别向服务器的两个端口发数据,(也可以直接向对方的IP和端口发,但对方是内网的,可能收到,也可能收不到,稍后再讨论怎么P2P)。
8 客户端B应该也要创建两个端口,向服务器的端口发数据。(如果执行过4,这一步直接发数据就行了)。
9 因为端口是一一对应关系,服务器端根据端口号可以知道是哪个用户发来的,并发往表现哪里的。
10 用户发bye,或掉线,服务器通知对方结束会话,同时close掉这4个端口。
以上,服务器创建rtp端口的同时,还要创建rtcp端口。
上面的流程是服务器直接在两点间中转,不包括经过多服务器间流转。
如果要做到两客户端之间直接点对点,AB双方的音视频端口,应该先连stun,取到自己的外网IP和端口后,再发INVITE,这时SDP中带的是自己的外网IP和端口,双方直接传很大可能是收的到的。
大致流程应该是这样的,可能还有些出入,毕竟是看代码得出的结论,不是看RFC协议。
只能说发明SIP和RTP的人,大脑复杂度远超普通人。当初以为HTTP已经够麻烦的了,不过人家也不过只用了一个端口就可以传所有数据。rtp的创始人应该是电信背景,可能认为每个端口号相当于电信中的每一路通话了
根据asterisk的代码,推测出sip server的工作流程如下:
1 客户端A通过sip发INVITE时,带的是内网IP和端口。
2 服务器收到后,转发给客户端B时,先创建两个音视频端口port1,port2,加到客户端A sdp中,然后发给B。
3 B收到后,肯定是同意了.如果拒绝,以下就不走了。
4 B本地也创建两个端口,连接port1,port2,带stun协议,返回自己的公网IP和端口。(这一步可选)
5 B向服务器回复同时,sdp上带本地的IP和端口。(这一步必须)
6 服务器收到B同意的回复后,再创建两个端口port3,port4,同时加到sdp中,返回给客户端A。
7 客户端A收到sdp后,得到其中的两个端口,然后本地也创建两个端口,分别向服务器的两个端口发数据,(也可以直接向对方的IP和端口发,但对方是内网的,可能收到,也可能收不到,稍后再讨论怎么P2P)。
8 客户端B应该也要创建两个端口,向服务器的端口发数据。(如果执行过4,这一步直接发数据就行了)。
9 因为端口是一一对应关系,服务器端根据端口号可以知道是哪个用户发来的,并发往表现哪里的。
10 用户发bye,或掉线,服务器通知对方结束会话,同时close掉这4个端口。
以上,服务器创建rtp端口的同时,还要创建rtcp端口。
上面的流程是服务器直接在两点间中转,不包括经过多服务器间流转。
如果要做到两客户端之间直接点对点,AB双方的音视频端口,应该先连stun,取到自己的外网IP和端口后,再发INVITE,这时SDP中带的是自己的外网IP和端口,双方直接传很大可能是收的到的。
大致流程应该是这样的,可能还有些出入,毕竟是看代码得出的结论,不是看RFC协议。
只能说发明SIP和RTP的人,大脑复杂度远超普通人。当初以为HTTP已经够麻烦的了,不过人家也不过只用了一个端口就可以传所有数据。rtp的创始人应该是电信背景,可能认为每个端口号相当于电信中的每一路通话了
相关文章推荐
- android sip通话实现流程分析
- 第二人生的源码分析(三十七)消息处理的完整流程
- Genesys (SIPServer 7.6)完整呼叫流程
- sipdroid的videocamera类,流程分析及RTP/RTCP介绍
- 基于Linux与Busybox的Reboot命令流程分析
- openstack - nova diagonstics 命令流程分析
- 第二人生的源码分析(三十七)消息处理的完整流程
- 最近在忙活视频通话(sip)
- Flex4 实现视频通话完整实例 二 服务器端
- Flex4 实现视频通话完整实例 一 客户端
- live555 接收rtsp视频流流程分析
- oracle一个事务的完整流程分析
- 一个完整的SIP呼叫流程
- 内核启动流程分析(基于韦东山视频修改)
- 流媒体分析之sipdroid的videocamera类,流程分析及RTP/RTCP介绍
- 蔡军生先生第二人生的源码分析(三十七)消息处理的完整流程
- jain-sip-applet-phone与GrandStream V3005 IP电话不能正常视频通话的问题解决方法(IP电话一直显示“对方保持”/“呼叫”)
- ORACLE 事务的完整流程的分析
- RTP通话:视频流(H.264)的传输
- 【完整的数据分析流程】