5.3. 共享外观用户代理

支持共享外观功能的 UA 使用对话状态包 [RFC4235] 以及共享外观扩展和第 13 节中定义的 'shared' Event 头字段参数。

UA 使用第 5.2 节中的对话包扩展以及 SUBSCRIBE [RFC6665]、NOTIFY [RFC6665] 和 PUBLISH [RFC3903]。对话事件包的 SUBSCRIBE、NOTIFY 和 PUBLISH 请求包含本规范要求的 'shared' Event 头字段参数。

'shared' Event 头字段参数的存在告诉外观代理该 UA 支持本规范。

初始化时, UA 必须订阅 AOR 的对话事件包并根据 SIP 事件框架 [RFC6665] 刷新订阅。如果 SUBSCRIBE 请求失败, 则可能不存在外观代理, 并且此功能对于此 AOR 不活动。UA 可以定期重试订阅以查看条件是否已更改, 间隔不得短于四小时。

选择四小时是为了将订阅测试限制为每个 UA 每天六次。增加此间隔会减少此失败流量, 但需要更长时间才能发现新激活的外观代理。

UA 还可以使用 NOTIFY 中 'shared' Event 头字段参数的存在来发现 AOR 的外观代理的存在。

实现共享外观功能、呼叫接听、加入和桥接的 UA 必须支持发送带有 Replaces [RFC3891] 或 Join [RFC3911] 的 INVITE。用户代理客户端 (UAC) 需要在 Replaces 或 Join 头中包含 to-tag 和 from-tag 信息, 以便用户代理服务器 (UAS) 根据 RFC 3891 和 3911 中的规则匹配正确的对话。

所有实现共享外观功能并支持 INVITE 的 UA 必须支持接收带有 Replaces [RFC3891] 或 Join [RFC3911] 头字段的 INVITE。

在发布或通知对话包信息时, UA 包含发布时可用的最大对话标识集, 但如果 UA 希望阻止其他 UA 加入或接听呼叫, 则可以省略信息。对话标识包括本地和远程目标 URI、call-id、to-tag 和 from-tag。虽然此对话标识信息在 [RFC4235] 中是可选的, 但它在共享外观功能中是必不可少的, 允许呼叫控制操作。在将呼叫置于保持状态时, 使用 "+sip.rendering=no" 功能标签在对话包通知中指示这一点。使用完整的 SDP 会话描述会迫使端点进行大量额外的解析, 不必要地使代码复杂化并引发错误。

准确呈现组中其他 UA 的空闲/活动/警报/保持状态是共享外观功能的重要组成部分。

不需要占用特定外观号码 (或不关心) 的 UA 将像平常一样发送 INVITE 来拨打出站呼叫。

如果呼叫是紧急呼叫, UA 绝对不能在发送 INVITE 之前等待确认的占用。相反, 紧急呼叫必须在不等待 PUBLISH 事务的情况下进行。

如果 UA 需要特定的外观号码, UA 必须发送对话包 PUBLISH 请求并在发送 INVITE 之前等待 2xx 响应。在以下情况下需要这样做:

当用户为出站呼叫占用特定外观号码时 (例如, 占用外观并"摘机", 如果 UA 的用户界面使用此隐喻)。
当用户请求不对出站呼叫使用外观号码时 (即, 在咨询呼叫期间、"服务媒体"呼叫 (如保持音乐 [RFC7088]) 期间, 或对于不被视为共享外观组一部分的呼叫)。
当用户选择加入 (或桥接) 现有呼叫时。
当用户选择替换 (或接管) 现有呼叫时。

请注意, 当 UA 在建立对话之前占用外观时 (上述列表中的 1 和 2), 并非所有对话信息都可用。特别是, 当 UA 在知道目标 URI 之前发布尝试占用外观时, 可能只有最少或没有对话信息可用。例如, 在某些情况下, 只有呼叫的本地目标 URI 是已知的: 没有任何对话信息。如果初始 PUBLISH 中不存在 From 标签和 Call-ID, 则一旦此信息可用, 就必须发送新的 PUBLISH。

第一次发布将导致外观代理为此 UA 保留外观号码。如果发布没有任何对话标识符 (例如, Call-ID 或 local-tag), 则外观代理无法将外观号码分配给 UA 的特定对话, 直到包含某些对话标识符的第二次发布。

在早期对话状态期间, 此发布状态按 [RFC3903] 中所述进行刷新, 否则外观代理可能会重新分配外观号码。一旦对话转换到确认状态, 就不需要发布刷新。

本规范假设外观代理除了 UA 发布之外还有其他方法来了解 UA 对话的状态。在本规范中, PUBLISH 用于指示所需和预期的外观号码操作。一旦对话从早期转换到确认, 此角色结束; 因此, 不需要发布刷新。

外观号码是与 AOR 相关的活动和待处理对话的简写标签。使用此扩展构建的许多功能和服务依赖于向人类用户正确呈现此信息。此外, 该功能的组性质意味着不同供应商和不同型号之间的呈现必须相似。否则将大大降低这些协议扩展的价值和有用性。在为此功能正确设计的用户界面中, 每个活动和待处理对话的外观号码都明确 (即, 通过外观号码) 或隐式 (使用使用户清楚编号和顺序的用户界面隐喻) 呈现给用户。每个对话的远端身份 (例如, 远程方身份) 不是外观号码的有用替代品。每个外观的状态也要呈现 (空闲、活动、忙碌、加入等)。UA 可以通过包含其他 SIP 对话标识符的一个或多个 <joined-dialog> 元素的存在来判断一组对话是加入 (桥接或混合) 在一起的。对话的外观号码可以通过包含来自外观代理的 <appearance> 元素的对话包通知或来自传入 INVITE 中的 'appearance' Alert-Info 参数来学习。如果它们冲突, 对话包通知优先。

用户可能选择外观号码但随后放弃拨打呼叫 (挂机)。在这种情况下, UA 通过使用 [RFC3903] 中所述的 PUBLISH 删除事件状态来释放外观号码。不这样做将需要外观代理进行不必要的操作并占用本可以由共享外观组中的其他 UA 使用的外观号码。

UA 应该仅在可能接听传入呼叫时才针对 AOR 注册。如果 UA 主要是监视共享外观组呼叫的状态并接听或加入呼叫, 则 UA 应该仅订阅 AOR 而不针对 AOR 注册。如果监视 UA 注册而不仅仅是订阅, 它会产生大量不必要的网络流量。

所有已订阅的 UA 都将接收传入 INVITE 的尝试状态的对话包 NOTIFY。

UA 绝对不能在 INVITE 或其他请求中向 Alert-Info 头字段插入 'appearance' 参数。

外观代理单独负责执行此操作。