关键词：
SIPLifesize华为对通
摘要：
在使用SIP协议与外厂商终端对通过程中遇到诸多问题，特在此总结。
案例描述
为什么使用我司终端通过SIP协议呼叫华为终端IP地址呼不通?
为什么使用我司终端通过SIP协议呼叫华为终端SIP别名却是正常的?
案例分析
通过以上问题描述我们先做以下排查：
通过抓包查看我司终端通过SIP协议呼叫华为终端IP地址的呼叫过程。
通过抓包查看我司终端通过SIP协议呼叫华为终端SIP别名的呼叫过程。
1.1.1查看我司终端使用SIP协议呼叫华为终端的情况
我司终端通过SIP协议呼叫华为终端IP地址的呼叫过程如下：
场景说明：
KDV-H850的IP地址为192.168.60.51；华为终端的IP地址为192.168.60.100，KDV-H850主呼华为终端IP地址。
分析包走向，筛选条件为“ip.addr==192.168.60.51&&ip.addr==192.168.60.100”
wirkshark抓包
抓包结果只有TCP包，我们终端尝试了3次TCP请求，结果都被RST了？
我司终端通过SIP协议呼叫华为终端SIP别名的呼叫过程如下：
场景说明：
KDV-H900的IP地址为：192.168.73.10；华为终端的IP地址为：192.168.60.100；interworking的IP地址为：192.168.38.15
分析包走向，筛选条件为“sip”
sip条件筛选从包信息中大约能看到有TCP包和UDP包，那就从上到下的先分析TCP包：
TCP包流
从上面的筛选条件，我们能看到SIP协议中走TCP的只有192.168.73.10（35011）<----------->192.168.38.15（5060）之间，也就是KDV-H900和interworking之间。
我们再分析UDP包：
(ip.addr eq 192.168.73.10 and ip.addr eq 192.168.60.100)
and (udp.port eq 5060 and udp.port eq 5060)；备注（5060为SIP协议端口）
SIP协议
从筛选出来的UDP包中我们可以看到第一包，是KDV-H900发给华为的，也就说和华为第一次SIP建立连接是通过UDP的方式，对比第一次呼叫华为终端失败，是因为我们和华为建立连接是通过TCP的形式，那我们就有了以下结论：
结论1：华为端的5060端口只支持UDP协议监听
结论2：我们KDV-H900无论是使用IP还是SIP别买呼叫对端，首先发的是TCP包，但是呼叫SIP别名时，通过interworking的转换后变成了UDP呼叫，大约的流程如下：
第一个包：H900向interworking发送SIP的invite包（以TCP的形式），向interworking查询SIP别名对应的IP地址；
第二个包：interworking返回呼叫端的消息（以TCP的形式）：包含对端IP地址（192.168.5.220），端口（5060），transport方式（UDP）；
第三个包：H900将interworking返回的消息向Lifesize端请求建立会议（以UDP的形式），并成功建会。
详情见抓包的实际内容。
1.1.2查看华为终端使用SIP协议呼叫Lifesize终端的情况
为了佐证以上观点，我们继续接下来的实验，我们的实验使用的标杆是Lifesize终端，在Lifesize终端中SIP协议可以选择UDP和TCP两种方式（ps：似乎更专业）
场景前提：Lifesize的IP地址为192.168.59.123；华为终端的IP地址为192.168.60.100
场景1：Lifesize终端优选SIP协议并使用TCP，使用Lifesize呼叫华为终端的IP。
分析包走向，筛选条件为“ip.addr==192.168.59.123&&ip.addr==192.168.60.100”
“ip.addr==192.168.59.123&&ip.addr==192.168.60.100”
场景2：Lifesize终端优选SIP协议并使用TCP，使用Lifesize呼叫华为终端的SIP别名。
分析包走向，筛选条件为“SIP”
sip
分析结果：与我司终端呼叫华为的SIP别名结果一致，前面部分Lifesize与我们的interworking以TCP方式交互，后面部分Lifesize以UDP形式和华为终端交互。（PS：细心的童鞋可能发现我Lifesize明明优选的是TCP啊，为什么后面使用的都是UDP能，其实这一切都是通过interworking来进行协议转换的。）
场景3：Lifesize终端优选SIP协议并使用UDP，使用Lifesize呼叫华为终端IP。
首先我们做个怀疑看看Lifesize和华为终端之间有没有TCP连接，筛选条件”ip.addr==192.168.59.125&&ip.addr==192.168.60.100&&tcp”
ip.addr==192.168.59.125&&ip.addr==192.168.60.100&&tcp
没有任何包，嗯~可以相信Lifesize了。直接筛选“SIP”，将所有的SIP包筛选出来，且他们都是UDP的。
sip
结果是Lifesize与华为终端SIP连接成功。
场景4：Lifesize终端优选SIP协议并使用UDP，使用Lifesize呼叫华为终端SIP别名。
分析包走向，筛选条件为“SIP”
sip
结果与场景2相同。
以上四个场景同样说明了之前总结的两个结论：
结论1：华为端的5060端口只支持UDP协议监听。
结论2：我们KDV-H900无论是使用IP还是SIP别买呼叫对端，首先发的是TCP包，但是呼叫SIP别名时，通过interworking的转换后变成了UDP呼叫。
但是仔细看以上结论感觉interworking只会将呼叫SIP别名时，将包转换成UDP似的，既然Lifesize的SIP协议可以优选TCP和UDP，那我们便有了以下的标题，我司终端呼叫Lifesize。
1.1.3查看我司终端使用SIP协议呼叫Lifesize终端的情况
场景前提：KDV-H900地址为192.168.73.10，Lifesize终端地址为192.168.5.220，interworking地址为192.168.38.15
场景1：Lifesize终端SIP协议优选TCP，我司终端通过SIP协议呼叫Lifesize的SIP别名，筛选条件为“SIP”
sip
包分析：所有包的类型都是TCP的（wireshark可以通过包的颜色来区分）
场景2：Lifesize终端SIP协议优选UDP，我司终端通过SIP协议呼叫Lifesize的SIP别名，筛选条件为“SIP”
sip
这个结果和Lifesize与华为对通的场景2和场景4以及我司终端呼叫华为SIP别名是相同的。
总结这两个场景：interworking并不是盲目的将使用SIP呼叫时，一味的将TCP包转换成UDP包，而是终端在注册sipservice时，将终端的能力记在服务器中，然后再能力交互时将适当的协议类型传达下去。
结论1：我们KDV-H900无论是使用IP还是SIP别买呼叫对端，首先发的是TCP包，但是呼叫SIP别名时，需要通过interworking的转换，可以转换成UDP，也可以是TCP，这需要看对端和sipservice之间的协商结果。
结论2：华为端的5060端口只支持UDP协议监听。
看到上面详细的分析过程，笔者开始也是粗略的知道其中的部分过程，通过同事交流，逐字击打键盘，反复思考才得以还原，如果阅读的人发现其中还有漏洞，希望给以指教。
网友评论