7. Alert-Info 外观参数定义

本规范扩展 [RFC3261], 为 Alert-Info 头字段添加一个 'appearance' 参数, 并允许代理修改或删除 Alert-Info 头字段。

RFC 3261 中 ABNF [RFC5234] 的变更如下:

alert-param      =  LAQUOT absoluteURI RAQUOT *( SEMI
                      (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT

插入 'appearance' Alert-Info 参数的代理遵循常规的 Alert-Info 策略。为指示此对话的外观编号, 代理会在 INVITE 中添加带 'appearance' 参数的 Alert-Info 头字段。如果已存在 Alert-Info, 代理会向该 Alert-Info 头字段添加 'appearance' 参数。如果已经存在外观编号参数 (与另一个 AOR 关联或因误操作而存在), 则重写该值并加入新的外观编号。Alert-Info 头字段中 MUST NOT 存在多个 appearance 参数。

如果不需要特殊回铃音, SHOULD 按 [RFC7462] 使用 Alert-Info 中的 urn:alert:service:normal 指示常规回铃音。Alert-Info 头字段中存在的外观编号 SHOULD 由 UA 按照第 5.3 节的准则呈现给用户。如果 INVITE 被转发到另一个 AOR, 则在转发到组外之前 SHOULD 删除 Alert-Info 中的 appearance 参数。

外观参数应使用何值的确定可以在将传入请求分叉到所有已注册 UA 的代理处完成。

代理可以通过多种方式确定应使用何值来填充该参数。例如, 代理可以向该 AOR 的外观代理发起带 Expires: 0 的 SUBSCRIBE 请求以获取此信息, 从而获取正在使用的线路列表。或者, 它可以表现得像共享外观组中的一个 UA, 像其他 UA 一样向状态代理 SUBSCRIBE。这样可以确保无需按需轮询即可获得活动的对话信息。它还可以根据其向外观 AOR 分叉或从外观 AOR 接收的唯一 INVITE 请求数量来跟踪外观 AOR 的活动呼叫列表。另一种方式是代理先将传入的 INVITE 发送给外观代理, 外观代理重定向到共享外观组 URI 并转义适当的 Alert-Info 头字段, 以便代理递归并向组内其他 UA 分发。

外观代理需要了解发往该 AOR 的所有传入请求, 以便占用外观编号。实现这一点的一种方式是外观代理以更高的 q 值针对该 AOR 注册。这会导致 INVITE 首先被发送到外观代理, 然后再提供给组内的 UA。