华琪软通国内电话信息领域中的领跑者
设为首页 | 加入收藏 | 联系我们
你所在的位置: 首页 > 公司新闻
华琪软通HaKey SoftComm

公司新闻

 任何一个软交换,或者B2BUA的IPPBX都非常重视来电显示的管理。很多业务需要获取到正确的来电显示号码,并且根据此号码做后续的业务支持。一台IPPBX也需要针对来电显示进行呼叫路由,和CRM第三方集成,VIP服务支持等业务。在本章节中,我们重点针对Caller ID做一些简单分享,包括From字段的处理,匿名caller id的处理和callerid 更新等内容。来电显示管理

Caller ID(来电显示号码)被认为是出现在From头字段的用户。使用显示名称和URI部分显示呼叫方身份。
在SIP RFC3261规范中,更改From头URI几乎是被禁止的,因为它会按照SIP的以前的规范中来执行dialog匹配。在新的RFC规范中,仅使用From头 tag标签参数进行对话匹配,因此更改显示名称或URI不会影响dialog的匹配。但是RFC3261要求保持向后兼容性,防止有非RFC3261兼容的SIP设备进行通信。
SIP协议支持了一些SIP扩展规范,它们分别是P-Asserted-Identity、P-Preferred-Identity和Privacy,用于携带呼叫者的声明的身份以及其隐私标识(例如匿名呼叫,是否可以对被叫方显示)。注意,这些扩展规范可能没有在所有SIP电话终端中实现支持。
FROM字段变量
整个“From”头部的内容可以通过$hdr(From)来获取。还有几个其他的变量可以获取头部内部的属性:
● $fu -在From头字段的URI
● $fU - 在From头字段URL中的username用户名
● $fd - 在From头字段的URL中的domain
● $fn -在From头字段中的显示名称
● $ft -在From头字段中的tag参数

在以前的版本中,这些变量是只读变量,但是在Kamailio的新版本中允许给 $fu、$fU、$fd 和 $fn进行赋值从来。但是,用户为这些变量赋新值时必须非常小心,因为在SIP解析器的处理中使用了新的文本块处理机制。这些具体的处理机制我们将在后面的章节中介绍。

这种处理机制表示执行赋值操作后不会立即删除旧值,并且马上设置新的值。相反,它会标记旧值以进行删除,并将新值添加到需要更新的SIP消息内容的操作列表中。

如果用户需要通过多次赋值更新From头的其中一个属性的话,用户可以在每次操作后使用msg_apply_changes()进行处理:

  •  
$fU="newuser”; msg_apply_changes();br

通过这样的处理会降低系统的执行性能,(如果使用不会太频繁的话,这种操作也不会引起其它问题),但是相对来说,其最终结果会更安全。

FROM头字段更新和自动还原

本节讨论的方法可能是更新From头字段属性的推荐的主要方法。当消息向下游节点传输时,显示名称和URI更改为新的值,当消息向上游发送时,这些消息值将还原为原始值。

UAC模块提供自动替换和恢复From头字段的功能。该模块依赖于rr模块,将在Record-Route头字段中的原始From值存储为一个cookie。执行From头字段更新的函数是:

  •  
uac_replace_from(dysplayname, uri)br
显示名称参数是可选的,两个参数都可以包含伪变量。

一个典型的用例是将来电显示号码执行规范化处理,使其支持国际号码格式,以便这个呼叫可以从电话终端的呼叫历史记录中返回。

下一个例子展示了来自德国(国家代码49)柏林(区号30)的来电号码的规范化处理,其号码转换为国际格式,并用新值替换From头部的显示名称和用户名。

  •  
loadmodule “rr.so” loadmodule “uac.so” .... $var(caller) = $fU; // 设置为用户名称if($var(caller) =~ ”^[0-9]{5,15}$” || $var(caller) =~ ”^\+[1-9][0-9]{5,15}$”) { if($var(caller) =~ ”^[1-9]”) { $var(caller) = “+4930” + $rU; // 添加国家区号和地区区号 } else if ($var(caller) =~ ”^0[1-9]”) { $var(caller) = “+49” + $(var(caller){s.strip,1}); } else if ($var(caller) =~ ”^00[1-9]”) { $var(caller) = “+” + $(var(caller){s.strip,2}); } else if ( ! ( $var(caller) =~ ”^\+” ) ) { xlog(“invalid caller ID number $fU\n”); send_reply(“404”, “Not found”); exit; } } else { xlog(“invalid caller ID number $fU\n”); send_reply(“403”, “Not allowed”); exit; } uac_replace_from(“$var(caller)”, “sip:$var(caller)@$fd”);br

这里,规范化处理是通过$var(caller)来完成,此变量在初始阶段设置为From头字段的用户名称。这里要注意,用户一定不能将多个值赋值到$fU或将多个赋值自动到其他与From头字段相关的伪变量。因为如果发生这样的处理的话,将导致这些值的最终结果是合并而不是替换(这里一定要明确,这是和SIP解析器的块内容机制相关)。如果dialog模块已加载,则UAC将在dialog变量中存储原始值和新的值,而不是存储在Record-Route头中的cookie。

匿名CALLER ID的处理
另一个典型的用例是设置匿名呼叫方的ID,支持这样的处理需为每个初始INVITE执行即可:
  •  
uac_replace_from(“Unknown”, “sip:anonymous@invalid”);br

当然,显示名称和URI可以设置为用户自己想要的任何值来进行匿名处理。

通过赋值执行CALLER ID的更新

使用UAC模块会增加一些开销,因为需要为From头字段属性值存储初始值和新的值,这些From字段属性值是在Record-Route头字段cookie或dialog模块中的变量中。在许多部署环境中,仅符合RFC3261规范的设备是允许的,这表示仅更新From头属性,不还原这些值的话不会出现其它任何伤害。

对于这样的情况,用户仅需要替换第一个INVITE的From头属性即可,因为这是其中的一个设置,这个设置是在设备的历史呼叫记录中已设置了呼叫方主叫ID的那个。与前面章节中关于呼叫方主叫ID规范化处理的的例子相比较,uac_replace_from(...)函数需要被替换为以下处理方式:

  •  
$fn = $var(caller);$fu = “sip:” + $var(caller) + “@” +$fd;br

对于匿名呼叫的处理来说,如果想处理没有携带任何SIP消息来指示呼叫方的话,用户可以在转发到下一跳之前,执行以下对所有请求(初始或dialog内)的操作:

  •  
if(!has_totag() || is_direction(“downstream”)) {$fn = “Unknown”;$fu = “sip:anonymous@invalid”;}br
函数is_direction(...) 通过rr模块导出的,可以检测呼叫请求的方向,检测是从呼叫方到被呼叫方(下游)还是从被呼叫方到呼叫方(上游)。

 

 

立即咨询