ICE流程中会话双方role冲突的解决方法

    ICE流程中定义了两种角色:controlling和controlled。不同的角色在candidate pair优先级的计算，pair nominate的决策上有所不同。一般流程下，会话的双发各自的角色选择是与会话协商的流程相关的。offerer是controlling，answerer是controlled。

    在一些特殊的流程下，可能会导致会话的双方都认为自己是controlling或者controlled。常见的一般为均认为自己是controlling，如下图所示。

    controller为B2BUA ，作为中间关联起A和B之间的呼叫。对于A和B来说，都是offerer，这样会导致均认为自己在ICE流程中扮演controlling的角色。

    为了解决上述情况，在connectivity check的阶段，发送的bind request要求携带role相关的STUN属性，ICE-CONTROLLED或者是ICE-CONTROLLING，这两个属性都会携带一个Tie breaker这样的字段，其中包含 一个本机产生的随机值。收到该bind request的一方会检查这两个字段，如果和当前本机的role冲突，则检查本机的tie breaker值和消息中携带的tie breaker值进行判定本机合适的role。判定的方法为Tie breaker值大的一方为controlling。如果判定本端变更角色，这直接修改；如果判定对端变更角色，则对此bind request发送487错误响应，收到此错误响应的一方变更角色即可。

ICE-CONTROLLING

ICE-CONTROLLED