我面临以下情况：我们必须向本地(REGISTED)用户(iOS应用程序pjSIP)发起彼此之间的本地呼叫。当其中一个用户(比方说用户B)在成功注册几分钟后关闭应用程序时，问题就出现了。现在，当用户A试图呼叫用户B时，我们看到INVITE已发送，但用户B没有回复(例如180振铃)。
注意：当我们向用户B发送邀请时，他会收到推送通知到他的设备，在什么情况下他会打开应用程序(并重新注册)
我们的目标是：1.在我们发送INVITE之前确定用户B(例如被呼叫者)是否可以访问，以防用户B应用程序关闭并且他的扩展仍然是REGISTED2.能够在用户B注册后立即向其发送邀请
我们试图从多个方面解决这个问题：1.限定-试图减少注册周期的限定时间，以便用户B将尽快不可用(我们将在拨号前检查设备状态)，但这可能会在我们的网络上导致大量OPTIONS，而且无法解决目标#22.AMI服务-它可以捕获事件，如：用户A拨打用户B，用户B正在振铃(180振铃)，并将这些状态保存到ASTDB。所有这些逻辑都将在我们启动拨号之前进行预处理。这个解决方案很笨拙，而且需要观察另一个服务
经过一些研究，我得出的结论是，最合适的解决方案是存储每个扩展的最后一次OPTIONS回复的时间(需要在chan_sip.c中进行补丁)。在用户a拨号之前，重新触发用户B的sip选项资格请求。如果原始值(例如，在我们重新触发OPTIONS之前)等于在我们触发OPTIONS之后的值，则意味着用户B尚未回复OPTIONS。
我附上我为完成这项任务所做的修改。我想知道这个问题的解决方案是否合适和有效，当然还有没有更好的方法来预制它。
这是chan_sip中的更改(使用星号11.7)我只在以下几行中进行了更改：23492至23500
23485 /*! brief Handle qualification responses (OPTIONS) */
23486 static void handle_response_peerpoke(struct sip_pvt *p, int resp, struct sip_request *req)
23487 {
23488 struct sip_peer *peer = /* sip_ref_peer( */ p->relatedpeer /* , "bump refcount on p, as it is being used in this function(handle_response_peerpoke)")*/ ; /* hope this is already refcounted! */
23489 int statechanged, is_reachable, was_reachable;
23490 int pingtime = ast_tvdiff_ms(ast_tvnow(), peer->ps);
23491
23492 time_t result = time(NULL);
23493 result = (int)result;
这是应该如何实现拨号计划与补丁：
Dial(SIP/${dest},10,Rgb(check_extension,s,1));
I'm sending the call to context before inviting ( with the "b" option)
context check_extension {
s => {
Set(IS_REACHABLE=0);
Verbose(KOLA/LastQualify/${DEST}); // Display User B initial quliafy
Set(INITIAL_QUALIFY=${DB(KOLA/LastQualify/${DEST})}); // Store it
for(loop=0;${loop}<60;dialLoop=${loop}+1) { // Loop untill the qualify will be changes
System(/usr/sbin/asterisk -rx "sip qualify peer ${DEST}");
Wait(2); // we need to wait a while for a response
Set(LAST_QUALIFY=${DB(KOLA/LastQualify/${DEST})}); // set the new qualify
if (${LAST_QUALIFY} > ${INITIAL_QUALIFY}) { // if the new qualify is newer, User B is reachable
Set(IS_REACHABLE=1);
break;
}
}
if (${IS_REACHABLE} = 0) {
Verbose(Peer is not reachable);
Hangup();
}
}
}
最好的选择是不要使用星号。
使用kamailio或opensips项目，它可以处理数千个选项包。
此外，你已经重写了你的应用程序，所以当它关闭时，UNREGISTER，如sip RFC中所述。
总结一下：您正在使用有缺陷的应用程序，并在星号上做它没有设计好的事情(大量用户有选项)。所以正确的答案-使用正确的工具完成这项任务。