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 策略。要指示此对话的外观号码, 代理将带有 'appearance' 参数的 Alert-Info 头字段添加到 INVITE。如果已存在 Alert-Info, 则代理将 'appearance' 参数添加到 Alert-Info 头字段。如果外观号码参数已存在 (与另一个 AOR 关联或错误地存在), 则重写该值并添加新的外观号码。Alert-Info 头字段中不得有多个外观参数。

如果不需要特殊铃声, 则应该按照 [RFC7462] 使用 Alert-Info 中的 urn:alert:service:normal 指示正常铃声。Alert-Info 头字段中存在的外观号码应该由 UA 按照第 5.3 节中的指南向用户呈现。如果 INVITE 转发到另一个 AOR, 则应该在转发到组外之前删除 Alert-Info 中的外观参数。

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

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

外观代理需要知道对 AOR 的所有传入请求, 以便占用外观号码。一种实现方法是让外观代理以更高的 q 值针对 AOR 进行注册。这将导致 INVITE 首先发送到外观代理, 然后提供给组中的 UA。