概述
SIP流程中，A路没有收到摘机的200 OK响应消息可以通话吗？
客户反馈的问题千奇百怪，公共互联网的问题同样百转千回，让你欲罢不能，头秃方休。
客户报故障，问题描述是这样的，我用号码A打给号码B，明明B接通说话了，话单记录中却显示“未接通”。。。
查服务器，查日志，查网络，查信令，一顿操作之后发现，B没有返回200 OK摘机消息给A，通话确实未接通，话单记录没错。
那难道是客户撒谎了？一番核实之后，客户200%确定通话接通了，马上就签合同了。
好吧，回到最初的问题了，SIP没有摘机消息可以通话吗？
环境
centos：CentOS release 7.0 (Final)或以上版本
freeswitch：v1.8.7
GCC：4.8.5
可能性分析
首先画出客户呼叫流程的节点图。
A->fs1->运营商A->运营商B->B
A：本地话单未接通，但是有和B通话。
fs1：话单和信令都显示未接通。
运营商A：和运营商A沟通，反馈话单未接通，B方向发过来480。
运营商B：和运营商B沟通，反馈话单已接通，有通话时长30秒。
B：未知。
经过各个节点的沟通之后，发现问题出在运营商A和运营商B节点之间，俩个节点的通话状态不一致，摘机消息很大可能在中间丢失了。
节点A，fs1，运营商A，话单未接通。
节点运营商B，B（推测），话单已接通。
但是还有一个问题，为什么A反馈通话是正常的，明明没有收到摘机消息啊。
回到信令层面，B返回的振铃消息是183（SDP）。
SIP信令中振铃消息有俩种，180和183（SDP），俩者的区别在于有没有带媒体（SDP）。
180消息仅仅是一个通知消息，B告诉A我收到呼叫请求了，然后A本地产生振铃音。
183消息带有媒体信息（SDP），fs需要建立早期媒体通道（early media），并转发RTP媒体。
那么，摘机消息丢失的情况下，用户可以用183的早期媒体通道实现通话吗？
模拟场景配置
为了回答上面的问题，我们使用俩台fs来模拟一下问题场景。
A->fs1A->fs2->fs1B->B
fs1：注册服务器，10.55.55.138。
fs2：业务服务器，10.55.55.137。
A和B注册在fs1上，A发起呼叫B，fs1B先回复183消息，B摘机，并在fs2->fs1A回复200 OK的时候，丢弃200消息。
fs2，10.55.55.137，服务器dialplan配置如下。
<include>
<context name="public">
<extension name="test" continue="false">
<condition field="destination_number" expression="^(\d+)$">
<action application="bridge" data="{sip_invite_call_id=${sip_call_id}}sofia/external/$1@10.55.55.138:5090" />
</condition>
</extension>
</context>
</include>
fs1，10.55.55.138，服务器dialplan配置如下。
<include>
<context name="default">
<extension name="test" continue="false">
<condition field="destination_number" expression="^(\d+)$">
<action application="bridge" data="sofia/external/$1@10.55.55.137:5080" />
</condition>
</extension>
</context>
<context name="public">
<extension name="test1">
<condition field="destination_number" expression="^(\d+)$">
<action application="pre_answer" />
<action application="playback" data="/usr/local/freeswitch/sounds/test-cailing.wav" />
<action application="bridge" data="user/$1" />
</condition>
</extension>
</context>
</include>
为了丢弃掉200 OK消息，在fs1（10.55.55.138）配置防火墙规则如下。
sudo iptables -I INPUT -m string --string "200 OK" --algo kmp --to 65535 -s 10.55.55.137/0 -p udp --dport 5080 -j DROP
测试
使用A（1001）注册到fs1。
使用B（1002）注册到fs1。
在A路侧开启wireshark抓包。
在fs2（10.55.55.137）开启sngrep抓包。
使用A（1001）呼叫B（1002）。
B（1002）摘机，A（1001）未收到摘机消息，但是AB可以正常通话。
最后附上sngrep和wireshark的抓包截图。图左边看到200消息丢弃的过程，图右边看到A路侧收发的语音媒体流正常。
总结
SIP没有摘机消息也可以通话，但是有时间上限。
互联网场景下，什么都有可能发生。
并没有什么事情是非黑即白的，不要轻易下结论。
空空如常
求真得真
标签：话单,SIP,fs1,摘机,通话,消息,接通 来源： https://www.cnblogs.com/qiuzhendezhen/p/16596311.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。