传统中继 sip trunk中继 安全可靠：SIP Trunk设备和ITSP之间只需建立唯一的、安全的、具有QoS保证的SIP Trunk链路。通过该链路来承载企业的多路并发呼叫，运营商只需对该链路进行鉴权，不再对承载于该链路上的每一路SIP呼叫进行鉴权。 节约硬件成本：企业内部通信由企业IP-PBX负责。企业所有外出通信都通过SIP Trunk交由ITSP，再由ITSP中的设备发送到PSTN网络，企业不再需要维护原有的传统PSTN中继链路，节省了硬件和维护成本。 节约话费成本：企业可以通过设置目的地址任意选择并连接到多个ITSP，充分利用遍布全球各地的ITSP，节省通话费用。 功能强大：部署SIP Trunk设备后，全网可以使用SIP协议，可以更好的支持语音、会议、即时消息等IP通信业务。 处理信令和媒体：SIP Trunk设备不同于SIP代理服务器。SIP Trunk设备接收到用户的呼叫请求后，会代表用户向ITSP发起新呼叫请求。在转发过程中，SIP Trunk设备不但要对信令消息进行中继转发，对RTP媒体消息也需要进行中继转发。在整个过程中，SIP Trunk设备两端的设备（企业内部和企业外部设备）均认为和其交互的是SIP Trunk设备本身。 参考 http://www.h3c.com/cn/d_201009/688762_30003_0.htm https://getvoip.com/blog/2013/01/24/differences-between-sip-trunking-and-hosted-pbx/ https://www.onsip.com/blog/hosted-pbx-vs-sip-trunking https://baike.baidu.com/item/sip%20trunk/1499860

RFC3261并没有介绍关于Path头的定义，因为这个头是在RFC3327中定义的，Path头作为一个SIP的扩展头。 RFC3327的标题是：Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts。 从这个标题可以看出，Path头是作为Register请求的一个消息头，一般这个头只在注册消息上才有。 这个头的格式如下。 Path: <sip:P1.EXAMPLEVISITED.COM;lr> 从功能上说，Path头和record-route头的功能非常相似，但是也不同。 看下面的一个场景，uac通过p1和p2, 将注册请求发送到uas, 在某一时刻，uac作为被叫，INVITE请求要从uas发送到uac, 这时候，INVITE请求应该怎么走？ 假如我们希望INVITE请求要经过p2,p2,然后再发送到uac, Path头的作用就是这个。 注册请求经过P1时，P1在注册消息上加上p1地址的path头 注册请求经过P2时，P2在注册消息上加上p2地址的path头 注册请求到达uas时，uas从Contact头上获取到uac的地址信息，然后从两个Path头上获取到如下信息：如果要打电话给uac, Path头会转变为route头，用来定义INVITE请求的路径。 简单定义：Path头用来一般在注册消息里，Path头定义了uac作为被叫时，INVITE请求的发送路径。 参考

sequenceDiagram title French Words I Know autonumber participant a participant p1 participant p2 participant p3 participant b a->>p1 : INVITE route: p1, via: a p1->>p2: INVITE via: a,p1, rr: p1 p2->>p3: INVITE via: a,p1,p2 rr: p1,p2 p3->>b: INVITE via: a,p1,p2,p3 rr: p1,p2,p3 b-->>p3: 180 via: a,p1,p2,p3 rr: p1,p2,p3 p3-->>p2: 180 via: a,p1,p2 rr: p1,p2,p3 p2-->>p1: 180 via: a,p1 rr: p1,p2,p3 p1-->>a: 180 via: a rr: p1,p2,p3 b-->>p3: 200 OK via: a,p1,p2,p3 rr: p1,p2,p3 p3-->>p2: 200 Ok via: a,p1,p2 rr: p1,p2,p3 p2-->>p1: 200 Ok via: a,p1 rr: p1,p2,p3 p1-->>a: 200 Ok via: a rr: p1,p2,p3 a->>p1 : ACK via: a, route: p1,p2,p3 p1->>p2: ACK via: a,p1, route: p2,p3 p2->>p3: ACK via: a,p1,p2 route: p3 p3->>b: ACK via: a,p1,p2,p3 rr代表record-route头。...

SIP是VoIP的基石，相当于HTTP协议在Web服务器里的角色。如果你熟悉HTTP协议，那么你可以在SIP协议中找到许多和HTTP中熟悉的东西，例如请求头，请求体，响应码之类概念，这是因为SIP协议的设计，很大程度上参考了HTTP协议。 如果想要学习VoIP，那么SIP协议是你务必掌握敲门砖。 1. SIP组件 UAC: 例如sip终端，软电话，话机 UAS: sip服务器 UA: ua既可以当做uac也可以当做uas 代理服务器 重定向服务器 注册服务器 网关 PSTN 公共交换电话网 2. SBC 边界会话控制器 SBC是Session Border Controller的缩写，具有一下几个功能。 拓扑隐藏：隐藏所有内部网络的信息。 媒体流管理：设置语音流编码规则，转换等 增加能力：例如Refer, 3CPP 维护NAT映射： 访问控制 媒体加密：例如外部网络用SRTP, 内部网络用RTP 3. sip注册过程 下面简化注册逻辑，省略了验证和过期等字段： 对于分机来说，注册服务器的地址是需要设置的 分机向注册服务器发请求，说：你好，注册服务器，我是8005，我的地址是200.180.1.1，以后你可以用这个地址联系我。 注册服务器回复：好的，注册成功 4. sip服务器的类型 4.1. 代理服务器 4.2. 重定向服务器 4.3. 背靠背UA服务器 背靠背UA服务器有两个作用 隐藏网络拓扑结构 有些时候，路由无法到达，只能用背靠背UA服务器 5. 常用sip请求方法 比较常用的是下面的 常用的几个是：register, invite, ack, bye, cancel。除了cancel和ack不需要认证外，其余的请求都需要认证。 register自不必说，invite和bye是需要认证的。 对于我们不信任的ua，我们不允许他们呼叫。对于未认证的bye，也需要禁止。后者可以防止恶意的bye请求，挂断正常的呼叫。 invite除了re-invite的情况，其余的都属于初始化请求，需要着重关心的。而对于bye这种序列化请求，只需要按照record-route去路由。 6. sip响应状态码 7. sip对话流程图 从上图可以看出，从invite请求到200ok之间的信令，都经过了代理服务器。但是200ok之后的ack，确没有经过代理服务器，如果想要所有信令都经过代理服务器，需要在sip消息头record-routing 指定代理服务器的地址 8. 请求与响应报文 9. 事务与对话的区别 重点： 从INVITE请求到最终的响应（注意1xx不是最终响应，非1xx的都是最终响应）之间，称为事务。一个事务可以带有多个消息组成，并经过多个ua。 ack请求比较特殊，但是ack不是事务。如果被叫接通后，超时未收到主叫方的ack, 会怎样？是否会再次发送200OK tcp三次握手建立连接，sip：invite->200ok->ack，可以理解为三次握手建立对话。 bye请求和200ok算作一个事务 dialog建立的前提是呼叫接通，如果呼叫没有接通，则没有dialog。 dialog可以由三个元素唯一确定。callId, from字段中的tag, to字段中的tag。 10....

1. 概念理解 务必要能理解SIP的重要概念，特别是事务、Dialog。参考https://www.yuque.com/wangdd/opensips/fx5pyy 概念是非常重要的东西，不理解概念，越学就会越吃力 2. 时序图 时序图是非常重要的，培训时，一般我会要求学员务必能够手工绘制时序图。因为只有能够手工绘制时序图了，在排查问题时，才能够从抓包工具给出的时序图中分析出问题所在。 RFC3665 https://datatracker.ietf.org/doc/html/rfc3665 中提供了很多经典的时序图，建议可以去临摹。

OPS <<<----------------------------- ingress 内网 | 公网 ｜ | 192.168.2.11 | 1.2.3.4 INNER_IP | OUTER_IP | | ------------------------------>>> egress 常见共有云的提供的云服务器，一般都有一个内网地址如192.16.2.11和一个公网地址如1.2.3.4。 内网地址是配置在网卡上的；公网地址则只是一个映射，并未在网卡上配置。 我们称从公网到内网的方向为ingress，从内网到公网的方向为egress。 对于内网来说OpenSIPS的广播地址应该是INNER_IP, 所以对ingress方向的SIP请求，Via应该是INNER_IP。对于公网来说OpenSIPS的广播地址应该是OUT_IP, 随意对于egress方向的SIP请求，Via应该是OUTER_IP。 我们模拟一下，假如设置了错误的Via的地址会怎样呢？ 例如从公网到内网的一个INVITE, 如果Via头加上的是OUTER_IP， 那么这个请求的响应也会被送到OPS的公网地址。但是由于网络策略和防火墙等原因，这个来自内网的响应很可能无法被送到OPS的公网地址。 一般情况下，我们可以使用listen的as参数来设置对外的广告地址。 listen = udp:192.168.2.11:5060 as 1.2.3.4:5060 这样的情况下，从内网发送到公网请求，携带的Via就被被设置成1.2.3.4。 但是也不是as设置的广告地址一定正确。这时候我们就可以用OpenSIPS提供的核心函数set_advertised_address或者set_advertised_port()来在脚本里自定义对外地址。 例如： if (请求来自外网) { set_advertised_address("192.168.2.11"); } else { set_advertised_address("1.2.3.4"); }

共享分机注册信息有两种方式 集群使用相同的数据库，多个节点实时读取数据 优点：使用简单，即使所有节点重启，也能立即从数据库中恢复分机注册数据 缺点：对数据库过于依赖，一旦数据库出现性能瓶颈，则会立即影响所有的呼叫 是用cluster模块，不使用数据库，通过opensips自带的二进制同步方式 优点：不用数据库，消息处理速度快，减少对数据库的压力 缺点：一旦所有节点挂掉，所有的分机注册信息都会损失。但是挂掉所有节点的概率还是比较小的。 今天要讲的方式就是通过cluster的方式进行共享注册信息的方案。 假设有三个节点： 在其中一个节点上注册的分机信息会同步给其他的节点 假设其中节点a重启了，节点a会自动选择b或者c来拉取第一次初始化的分机信息 举例来说： 8001分机在b上注册成功 b把8001的注册信息通过cluster模块通知给a和c 8002分机在a上注册成功 a把8002的注册信息通过cluster模块通知给b和c 此时整个集群有两个分机8001和8002 节点c突然崩溃重启 节点c重启之后，向b发出请求，获取所有注册的分机 节点b像节点c推送全量的分机注册信息 此时三个节点又恢复同步状态 cluster表设计: 空的字段我就没写了，flags字段必须设置为seed, 这样节点重启后，才知道要像哪个节点同步全量数据 id,cluster_id,node_id,url,state,flags 1,1,1,bin:a:5000,1,seed 2,1,2,bin:b:5000,1,seed 3,1,3,bin:c:5000,1,seed 脚本修改： # 增加 bin的listen, 对应cluster表的url listen=bin:192.168.2.130:5000 # 加载proto_bin和clusterer模块 loadmodule "proto_bin.so" loadmodule "clusterer.so" modparam("clusterer", "db_url", "mysql:xxxx") # 设置数据库地址 modparam("clusterer", "current_id", 1) # 设置当前node_id modparam("usrloc", "working_mode_preset", "full-sharing-cluster") modparam("usrloc", "location_cluster", 1) # 设置当前的集群id 其他操作保持原样，opensips就会自动同步分机数据了。

这个报错比较容易出现在tcp转udp的场景，可以看以下的时序图 ab之间用tcp通信，bc之间用udp通信。在通话建立后，c给b发送了bye请求，但是b发送给了c 477。正常来说b应该把bye转发给a. 那么问题出在哪里呢？ 问题就出在update请求的响应上，update的响应200ok中带有Contact头，如果是Contact是个nat的地址，没有经过fixed nat, 那么b是无法直接给nat内部的地址发送请求的。 处理的办法也很简单，就是在收到a返回的200ok时，执行fix_nated_contact() 遇到这种问题，往往进入一种思维误区，就是在INVITE请求成功后，fix了nat Contact后，Contact头是不会变的。 但是实际上，很多SIP请求，例如NOTIFY, UPDATE都会携带请求和响应都会携带Contact, 如果只处理了INVITE的Contact头，没有处理其他携带Contact的sip请求或者响应，就必然也会遇到类似的问题。 我们知道SIP的Contact后，决定了序列化请求的request url。如果Contact处理的有问题，必然在按照request url转发的时候出现问题。 综上所述：无论请求还是响应，都要考虑这个消息是否携带了Contact头，以及是否需要fix nat Contact。

1. 拓扑隐藏功能 删除Via头 删除Route 删除Record-Route 修改Contact 可选隐藏Call-ID 如下图所示，根据SIP的Via, Route, Record-Route的头，往往可以推测服务内部的网络结构。 我们不希望别人知道的我们的内部网络结构。我们只希望只能看到C这个sip server。经过拓扑隐藏过后 用户看不到关于a、b的via, route, record-route头 用户看到的Contact头被修改成C的IP地址 可以选择把原始的Call-ID也修改 当然，拓扑隐藏除了可以隐藏一些信息，也有一个其他的好处：减少SIP消息包的长度。如果SIP消息用UDP传输，减少包的体积，可以大大降低UDP分片的可能性。 所以，综上所述：拓扑隐藏有以下好处 隐藏服务内部网络结构 减少SIP包的体积 2. 脚本例子 拓扑隐藏的实现并不复杂。首先要加载拓扑隐藏的模块 loadmodule "topology_hiding.so" 2.1 初始化路由的处理 在初始化路由里，只需要调用topology_hiding() U 表示不隐藏Contact的用户名信息 C 表示隐藏Call-ID # if it's an INVITE dialog, we can create the dialog now, will lead to cleaner SIP messages if (is_method("INVITE")) create_dialog(); # we do topology hiding, preserving the Contact Username and also hiding the Call-ID topology_hiding("UC"); t_relay(); exit; 2....

wireshark安装之后，tshark也会自动安装。tshark也可以单独安装。 如果我们想快速的分析语音刘相关的问题，可以参考下面的一个命令。 语音卡顿，常见的原因就是网络丢包，tshark在命令行中快速输出语音流的丢包率。 如下所示，rtp的丢包率分别是2.5%和4.6%。 tshark -r abc.pcap -q -z rtp,streams ========================= RTP Streams ======================== Start time End time Src IP addr Port Dest IP addr Port SSRC Payload Pkts Lost Min Delta(ms) Mean Delta(ms) Max Delta(ms) Min Jitter(ms) Mean Jitter(ms) Max Jitter(ms) Problems? 2.666034 60.446026 192.168.69.12 18892 192.168.68.111 26772 0x76EFFF66 g711A 2807 72 (2.5%) 0.011 20.592 120.002 0.001 0.074 2.430 X 0.548952 60.467686 192.168.68.111 26772 192.168.69.12 18892 0xA655E7B6 g711A 2215 106 (4....