借助sip呼叫浅析sip server

本人刚刚入门通信行业的测试，针对目前学习，了解的sip server分类做一些介绍，如果错误，请指正。

我正在学习sip呼叫流程，用3CX服务器抓到的包是这样的

用公司的sip server（简称A server）抓到的是这样的

对比发现，两台服务器对于invite和100trying的处理是不同的：3CX是先转发再响应，A server先响应再转发。起初以为这是由于服务器的不同处理机制导致的。后来了解服务器分为代理服务器和软交换功能的服务器之分。代理服务器对于请求会先转发再响应，过滤calID（会话标识符）会发现是一通电话，看上面的3CX其实是很像代理服务器的（实际并不是，后面讲）；软交换功能比如A server，先响应再转发，过滤callID会发现是两通电话，即主叫和server是一通，被叫和server是另一通。

这样的话，前面的invite和100trying就说通了。但是！如果3CX仅是起到代理服务器的功能的话，那么后面的bye请求先响应再转发与之前分析的矛盾。后来请教大牛，告诉我过滤rtp包。发现3CX的rtp包是由主叫发送给被叫，没经过服务器。A server的rtp包主叫发给A server，再由server转发给被叫。对于A server完全是两通电话，rtp包经过server转发是相互印证了的。但是3CX一直很矛盾,表现为：1.invite和100trying是先转发再响应的代理服务器类型2.BYE信令是先响应再转发的软交换功能服务器3.过滤rtp包，发现未经过server的代理服务器类型。原来这里的3CX是将通话半处理成两个通话。它只是在sip信令（sdp除外）上处理成两个呼叫，（100trying和invite别太纠结，信令这种东西，每个公司有自己的做法，只要流程通了就OK，实际上，发100trying是为了防止主叫在一段时间没收到响应疯狂的发invite请求，告诉主叫一声，爸爸在处理请求，别急~如果速度够快，秒接，你不发100trying也行，显然这种情况不符合常理）但sdp还是用实际被叫的，所以，主叫是能看到被叫的sdp信息。如果是代理服务器，信令和sdp都是透传的，相当于一通呼叫。    3CX这种信令不透传，sdp透传的情况如果入到两个不在同一子网的主机呼叫，由于信令通过sip server转发是通的，但是由于不在同一个子网，rtp包发不过去。导致信令通，语音不通的情况。但是A server由于全是经过它转发，不会出现这种情况。但是！！！服务器转发这么多rtp包，对于它是一种负担，消耗服务器资源。 3CX这种不过rtp包不过它的情况节省服务器资源。 实际上，有些服务器是支持这种rtp包过不过服务器的选项，可供选择，比如ondo sip server。

总结：判断服务器类型可以通过拨打一通电话，用wireshark抓包。过滤callID。如果过滤之后发现是两个IP之间的传递，则为软交换功能服务器。若为三个IP，则为proxy server。然后在过滤rtp，查看实际的媒体流传递路径。是否经过服务器。