3GPP定义的IMS ECT业务与Conf…

3GPP定义的两个IMS业务总纲性标准

3GPP TS 22.173

  IP Multimedia Core Network Subsystem (IMS) 
Multimedia Telephony Service and supplementary services;
Stage 1
    它定义了IMS业务的基本需求，重点在于列举了IMS所应支持的各补充业务功能列表、功能简单描述、各业务间冲突关系。
    其中提到了Explicit Communication Transfer (ECT)，Three-Party (3PTY)，CONFerence (CONF)。
    通过Annex E (informative):Bibliography references可知，各业务的功能主要继承了ETSI的ISDN业务标准。

（解释：可以看出，3GPP定义的 IMS补充业务体验主要来自于传统固网的用户体验。）

        各业务都有单独标准来定义其功能需求、签约激活模式、业务流程、各角色的功能细节及业务冲突关系。
    Three-Party前几年曾经看到过单独的标准，但最近几年合并到CONFerence (CONF)业务中。

3GPP TS 24.628

Common Basic Communication procedures using IP Multimedia (IM)
Core Network (CN) subsystem; 
Protocol specification 
        包括了各种放音模式的流程。放音模式在传统网络中的重要功能，各运营商往往对这部分功能有不同的要求。
  =========================================
Explicit Communication Transfer (ECT)
        其主要标准是：3GPP TS 24.629 
Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystem; 
Protocol specification 
  ECT业务分为Blind transfer(转接-盲转),Consultative transfer(转接-询问转)。

      ECT分为 端到端流程 与3PCC流程。

ECT标准中定义了四个流程
        1，端到端流程-盲转
    A与B通话后，B发对话内refer给A(request To: UE-A,Referred-To: UE-C, Referred-By: UE-B)，让A与C通话
    要求：AS-B收到refer后， 1）判断refer是用于ECT。
                                                                              2）把refer-to变成private-url，并保存原值(PUI C)    3)Referred-By 头与privacy头要保证正确性。
                AS-B收到A发来的invite及后续ACK时，1)判断req-uri是自己原来产生的private-url
                                                            2）把req-uri（to\route也可能改) 由private-url变为原值(PUI C).    3）Referred-By 头与privacy头要保证正确性。
                                AS-A收到refer后：存储refer-to头与Referred-By头。而当收到A发的invite（用原存的refer-to头来关联）时，更新Referred-By头或当Referred-By头错误时拒绝invite。
    异常流程：24.629的4.5.2.4.1.2.2A， 4.5.2.4.1.2.3最后两段， 24.628的 4.7.2.9.7
                                        当refer发出后，对端回403或503 或特定notify(消息体中指示420)，AS-B给业务用户回notify+202，此后按3PCC流程，发invite（盲转）或reinvite(询问转)给 对端。即端到端流程失败时，AS自动转换为3PCC流程与reinvite流程。
                                      A与B在原对话中交换allow时，AS就知道哪个UE是否支持refer（或运营商不愿意把refer发给对端，控制不执行 端到端流程）。则AS不用发refer给对端就可以自行开启3PCC流程。

2，端到端流程-询问转
    A与B通话，B也与C在通话中。B发对话内refer给A(字段同上，但含replace字段)，让A与C通话。
                                        AS-B收到refer，
                                                                行为同盲转，另外 删除并保存replace字段
                                        AS-B收到A发来的invite及后续ACK时，
                                                                行为同盲转，另外 补充replace字段。
                                        要求：AS-C及 AS-B与UE_C之间的各B2BUA网元均要替换replace头。

    异常流程同盲转

3，3PCC流程-盲转
    A与B通话后，B发refer给A，让A与C通话。
                        标准要求参考3GPP TS 24.628 Figure E.1与E.5。但其中的流程似乎是三方通话的且不完整，二者的区别似乎是invite中是否带null SDP。
                  如果参考 3PCC流程-询问转 的流程，很容易理解 3PCC流程-盲转 的流程

4，3PCC流程-询问转
    A与B通话，B也与C在通话中。B发refer给A，让A与C通话。

      在3PCC流程中，终端的要求较低，只要能发出refer信令来触发ECT业务即可（传统SIP终端只要增强refer信令支持即可，并且refer协议不用全部支持）。其它业务流程由AS控制。而端到端业务流程中，除了终端发refer来触发ECT业务外，其它业务流程中对终端、AS的要求都较高(比如终端收到refer发invite，根据ECT业务进程发notify等)。
      由于终端厂家、终端类型较多，终端的改造升级涉及面较广，工程、商务实施更困难。 实际组网时，运营商可能更倾向于3PCC过程，此外，端到端流程实现的难点较大，标准中也有若干要求实现较难或者说有可改进的空间，具体如下面各个细节。
      3GPP 端到端流程在细节上与RFC中的transfer流程区别已较大，因为3GPP标准对于计费、各厂商互通性、运营商管控 方面考虑较多。

ECT业务细节分析
端到端流程 细节点1：AS-A虽然是非业务用户的AS,但也需要识别ECT业务。
      从附录的两个端到端流程中可以看出，以盲转流程中的AS-A,AS-B为例：
        1) 不仅 ECT业务用户的AS（AS-B）需要识别出ECT业务特征来对信令头进行修改、缓存信令头并在收到后续invite时匹配原对话。 
        2) 而且非业务用户的AS（AS-A）也需要识别ECT业务，并缓存refer-to头与refer-by头。 目的可能是为了满足计费模型：它要求AS-A对于 UE-A发出的新invite呼叫 出的Rf ACR消息是：charge A-B，即主叫是A，被叫是B。
        而这路invite中，被叫号码是ECT Session Identifier URI(即private uri)，B号码只可能在refer-by头中携带，这个头并不是信令的强制字段。UE-A完全可以在 收到refer而产生的invite 中并不携带这个头。
        那么只能由AS-A来保存refer中的refer-by头，并插入后续收到的invite中并转发出去。这就带来二个需求：
    1) AS-A必须能检查收到的每个refer信令，判断它是否用于ECT业务（因为Rerfer也常用于其它业务，比如三方通话或会议）。当判断它是用于ECT业务时，要缓存refer-to头与refer-by头。
    2）缓存refer-to头的目的是用于： 当AS-A每收到一个初始invite时，都要检查其req-uri是否匹配了已缓存的refer-to头。如是，则在invite中插入对应的refer-by头（ 如果invite中没有这个头或其内容不正确的情况下）。
        这样，AS-A(实际上包括了IMS网内所有的补充业务AS)就需要理解ECT业务并对收到的每个refer\invite都作上述处理，影响了性能。但不这么做，计费模型中（B作为Rf ACR消息中被叫号码）这个需求就无法满足。
      如果UE-A是PSTN/ISDN用户终端的话，AS-A的角色将由MGCF来做。MGCF的性能也将受到影响（在架构上，MGCF不应该对 补充业务 流程有太多的干涉）。实际组网中，如果AS-B、MGCF是两个不同厂商的话，互通性要求会增加。
      代替方案（实用性较强的方案）：废除计费模型的要求（指 对于 UE-A发出的新invite呼叫 出的Rf ACR消息是：charge A-B ）， AS-A对于 UE-A发出的新invite 出的ACR中带特殊的标识。 AS-B也是如此。这样：计费服务器在根据icid关联AS-A\AS-B\AS-C的呼叫时，可以识别出这是一个因转接产生的呼叫，并将费用计在B的头上。 
注１：实际运营中，出于运营商加强管理（即 禁止 不在运营商管控 下的端到端业务）的需要，AS-A，AS-B 当判断出refer不是用于ECT、或会议或其它运营商管理下的业务流程时，AS应该拒绝这个refer请求。
注2：AS-C只需要作为一个普通的补充业务AS而存在，不需要理解ECT业务。
注3：refer-by在AS-B上也作为一个重要信息而需要保证正确性，原因可能是因为 B用户在发起refer之前可能处于多路呼叫中，比如B同时与A、D在二路呼叫中，B发refer把A用户转接给C。AS-B在收到UE-A根据refer产生的新invite时，需要与B用户原有的 A-B 这路呼叫关联起来，refer-by是关键的呼叫查找信息（refer-by中还应该携带GRUU信息).

端到端流程 细节点2：AS-B根据某种信息来判断当前是处于哪个流程中（端到端流程、3PCC流程 其中之一）
            在端到端流程、3PCC流程中，UE-B发出的refer在信令上是完全一样的，但AS-B在 端到端流程、3PCC流程 中收到refer后的处理却是完全不一样的。
                由于AS-B在端到端流程、3PCC流程中都作为一个重要的角色而存在，AS-B需要有办法识别出当前是在执行哪个流程。
      办法可能是 AS-B上预定义的配置或终端上根据配置来携带特定的信令头通知AS-B。 
      或者根据 “refer流程失败后的异常处理”来认为 端到端流程 优先于3PCC流程，即AS-B总是先按端到端流程来执行。

端到端流程 细节点3：ECT Session Identifier URI 生命期的作用
          ECT Session Identifier URI必须有很短的生命期，在超出生命期之后，如果AS-B收到一个被叫号码是这个ECT Session Identifier URI的呼叫，应该拒绝它。 
    原因是：1)，UE-A收到refer后多长时间产生invite？虽然没有标准明确定义其时间，但无疑应该是很快的，否则在用户体验上，UE-B可能因为长期没有收到refer成功的notify通知，而认为转接失败。        2)，AS-B在收到refer时，要检查从B到C的呼出限制类业务， 如果新的invite在较长时间后才收到，在这段时间内，可能通过某种接口修改了B的呼出限制业务。如果有生命期概念的话，对于这个新的invite就不需要再判断一次B的呼出限制类业务了（确实标准中也没有作这个要求，可能就是有生命期的考虑）

端到端流程 细节点4：必须有办法能让AS-B实时根据ECT Session Identifier URI识别出这路invite与转接有关。
      流程要求：AS-B在收到 UE-A产生的新invite 时，要根据req-uri=ECT Session Identifier URI来定位与原refer对话有关，并找到原对话中缓存的信令头。
      这个过程必须是很快(实时)，并且不应该让系统产生较多的 全局数据 开销。
      如果按照原有的分发机制，要么让 原refer对话存储为全局数据，要么让系统到所有 服务器\板卡\.. 上都去找一次。所以 这个新的分发机制必须仔细设计。
注：
                在大容量的电信设备中，多是采用了多服务器、多板卡、多CPU、多存储器、多进程  的设计。不同用户、不同对话的实时数据会存在不同的 服务器\板卡\CPU...上，所以这种设备需要根据网络业务流程的特点来仔细的设计 分发 功能（比如IMS中的隐式注册集、别名组就是分发机制设计的重要基础，而传统网络中并没有类似的概念，所以两种网络对于 一机多号业务 的实现机制可能是不同的），目的是为：1），新收到的业务流 要实时分发到某个 服务器\板卡\CPU.. 上，以保持各服务器\板卡\CPU..的负荷均衡。 2），建立对话过程中和对话后收到的 对话内业务流 能实时分发到 同一个服务器\板卡\CPU.. 上。
        以下场景的可靠性与系统性能是较差的：初始invite发到2号服务器上处理，而对话内refer 却发到 3号服务器上处理。这样不仅带来较多的 服务器间 消息交互，各服务器上也可能要存在较多的全局数据，这就失去了 分发功能 的意义。

端到端流程 细节点5：refer所在dialog内同时存在invite usage与refer usage 的需求。
                按盲转流程，在UE-B收到refer的202响应时，就发bye，这会终止invite usage，但为了让UE-B继续接收notify，两个终端、AS-A、AS-B、CSCF（也可能有MGCF）上都要维持对话与refer usage的存在。 （可参见 RFC5057 Multiple Dialog Usages in SIP）。这就要求这些设备、终端上要支持 对话内多usage，在数据结构与分发上作较多考虑。
          如果UE-B在收到表示转接呼叫成功(terminated)的notify时再发bye，则上述设备、终端不需要支持 对话内多usage。
            由终端自己决定如何处理。则如终端只支持后者，则网络设备的要求会简单的多。

端到端流程 细节点6：AS-A对于 UE-A新发起invite ，是否要检查呼出限制？  业务类型判断是否按A与B、还是A与ECT Session Identifier。
      标准中未提及上述细节，如果仍按charge:A-B的计费要求来做的话，为了与计费一致可能要作上述处理。

端到端流程 细节点7：refer流程失败后的异常处理。
      标准中提及： 当refer发出后，对端回403或503 或特定notify(消息体中指示420)，AS-B给业务用户回notify+202，此后按3PCC流程，发invite（盲转）或reinvite(询问转)给 对端。即端到端流程失败时，AS自动转换为3PCC流程与reinvite流程。       A与B在原对话中交换allow时，AS就知道哪个UE是否支持refer（或运营商不愿意把refer发给对端，控制不执行 端到端流程）。则AS不用发refer给对端就可以自行开启3PCC流程。
    这可能是说明了 端到端流程 优先于3PCC流程。此处在处理细节上实际上可能无法覆盖上所有业务流程，如哪个响应码表示refer失败。

端到端流程 细节点8：AS如何判断收到的refer是否用于ECT、会议或其它业务？
      目前的业务标准中，refer可以用于ECT或3PTY业务。从AS收到的Refer信令看是非常类似的。
        区别1：，会议主席将某人加入会议的refer请求中，refer-to是Conference URI，不是非用户PUI。这个refer发出后。对于ECT业务流程中涉及的AS（AS-B，AS-A）来说，AS-B\AS-A收收到refer-to是Conference URI，它必须能了解到这个URI确实是一个会议的URI，而不是一个普通用户的URI（ 即盲转流程中的 C的URI）或 ECT Session Identifier URI(如果AS-A按标准要求要识别ECT业务的话）。  除此之外的情况下，refer都应该拒绝，因为它不在运营商管控之下，可能是终端或其它SCP利用了IMS网络的资源进行通信的行为。
      而在会议业务中，会议AS如果收到一个refer(refer-to=ECT Session Identifier URI)的话，它也要能判断这个refer是用于ECT，而不是非运营商控制的业务。除此之外的情况下，refer都应该拒绝，原因同上。
        ECT的两个AS（AS-A、AS-B）与会议AS都是单独组网的AS，运营商不会允许 非自己控制 的业务流程经过IMS核心网。三个AS必须能判断出每个refer是用于ECT、会议或其它业务。比如判断出refer用于ECT，而用户未签约ECT的话，refer应被拒绝。如果判断出refer不是用于ECT、会议或其它运营商控制下的业务，则这个refer也应被拒绝。
      可使用的方法是：1)，通过管理手段让三个AS了解到用户PUI、conf uri、ECT session identifier uri的数据，2)，直接通过Uri本身的某些特征，如特定号码段来区分上述三种uri类型。3) 或者通过HSS将上述三种URI数据存储并下载到AS中。
      区别2：ECT标准中只要求对话内refer。而3PTY标准中提到了对话内refer与对话外refer。但早期的ECT标准与RFC中也提到了对话外refer的用法。AS必须能判断出 收到的对话外refer是用于ECT 的业务场景，此时不符合业务流程，应拒绝之。判断方法类似上面的描述。     

端到端流程 细节点9：ECT Session Identifier URI的正确路由
          ECT Session Identifier URI必须能作为被叫号码在IMS网络中被正确路由到AS-B。

          方法是：1)  可以把它作为PSI在HSS中放号，I-CSCF据此来判断下一跳S-CSCF，而S-CSCF也可以据此来判断下一跳AS。 2) 也可以在URI中的域名指示AS-B，各网元按域名路由。3)  也可以在URI的user part部分携带特定的号码段，在P/I/S-CSCF上配置按号码段路由。
      与 端到端流程 细节点4 结合可见 ECT Session Identifier URI 必须经过仔细的设计。

端到端流程 细节点10(重点)：replace流程是否用reinvite流程代替。
          在询问转、Conf中使用了replace头。终端在收到一个新呼叫（且含replace头)时，从repalce头中取出dialog id，将本地同样dialog id的另一路呼叫bye掉。 这就是replace呼叫的意义:用一个新呼叫来替换原有的SIP呼叫。
      而reinvite流程，则是终端会在原有呼叫中收到一个reinvite，媒体切换成功后从终端角度来说，也实现了与另一个用户通话的目的。
          两个流程的设计出发点可能与 业务流程控制方 的设计有关：replace头由另一个终端在信令中携带，常用于端到端流程。 而reinvite流程则常用于3PCC流程，完全由AS控制。
        replace头对于网络组网有如下影响：
    1，两个终端（被叫有可能是MGCF）都应该支持replace头。标准中又规定了 被叫终端因为不支持replace头而返回失败响应后，AS应该控制转为reinvite的流程。
      另外，当被叫是MGCF时（原呼叫发给MGCF1），而新呼叫(refer或invite)发给同样被叫号码（带replace头），这个新呼叫可能被BGCF选择到另一个MGCF2。这样MGCF2上是找不到旧呼叫的，导致这个流程失败。这在标准中也有论述。
        解决的办法是让新呼叫发给MGCF1的Contact地址，（实际上也不适用，因为RFC允许B2BUA网元修改Contact）
    2, SIP消息经过的各网元可能是B2BUA的，则它们应该把信令中的replace头中替换dialog id。这对各网元设备的要求较高。（replace头在RFC中提出，各个业务RFC中更适用于 网络网元是proxy 的情况，3PCC流程也较少。这可能是因为很多RFC更倾向于 IP网无核心控制 的思路，这种思路适用于proxy网元与replace头）
      3，即使各网元都支持替换dialog，仍要求：旧呼叫(invite)与新呼叫(invite或refer)经过的网络路径（指SIP层网元的SIP消息路径）必须是完全一样，否则新呼叫经过的某网元如找不到旧呼叫的dialog时，就会引起dialog id替换失败，上面提到BGCF选择MGCF就是一例。IMS也允许I-CSCF根据 网元能力、负荷分担 的要求选择下一跳的S-CSCF，这也可能引起类似情况（还有：P-CSCF选择S/I-CSCF，AS选择下一跳 I/S-CSCF）。
    4，反向replace问题无法解决：业务AS分MO、MT两种。某用户的MO、MT AS经常可能不是同一个。举例：
                A发起呼叫到B。经过AS 1（MO侧）、AS2（MT侧）。B发起新呼叫或新refer到A（带replace头），呼叫经过AS3（MO侧）、AS4（MT侧）。 这种组网从IMS业务角度是合理的（用户A的MO AS是AS1、MT AS是AS4)。
      按上面的分析，AS3\AS4上没有旧呼叫的dialog id，无法替换它。使得replace流程失败。
      解决办法是让新呼叫必须经过旧呼叫的路径（AS1、AS2）。这不但违背了IMS网络的基本原则（MO、MT AS分开），也必须让新呼叫在发出端（如终端或发起侧AS）就能关联到旧呼叫（比如让终端记录旧呼叫的record route头，反放到新呼叫中的route头中，这种办法也需要B2BUA网元替换route头）
注1：在部分业务场景中，replace也无法使用，比如旧呼叫发生了无应答前转业务，新呼叫发给被叫后，被叫会无法在本地找到旧呼叫的dialog id，而导致流程失败。
注2：
          3GPP ECT标准通过让AS-B修改refer-to头为自己，保证了UE-A侧发出的新invite一定可以到达自己，这解决了 UE-A到AS-B 侧的部分replace问题（类似于 上述提到的新呼叫发给 MGCF1的Contact地址）。但从 AS-B侧到UE-C 侧的呼叫仍面临上述repalce问题。
注3：标准化组织提出了draft-ietf-insipid-session-id-reqts-00.txt，也许session id头可以代替replace头的原作用，这个头不被B2BUA网元所修改，旧呼叫中产生并端到端的传递它，而新呼叫中可以携带旧呼叫同样的session id，一直透传给被叫终端，被叫终端据此可以bye掉旧呼叫。(这时，即使呼叫中间的信令路径有改变，或B2BUA网元不修改replace头，但两端终端仍是识别session id的，依靠它可以关联两个呼叫)

其它细节：ECT与ECT的嵌套，ECT与会议的嵌套，ECT与限制类业务的嵌套，。。。
      比如当ECT AS（AS-B）发现对话内refer的refer-to=conference focus时，这个refer是用于会议呼叫而非ECT业务。此时应拒绝refer。注：前提是ECT AS能知道Conf AS的地址或标识信息。

=============================

Conference (CONF)
3GPP TS 24.605 
  Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; 
Protocol specification 
与3GPP TS 24.147
Conferencing using the IP Multimedia (IM)
Core Network (CN) subsystem;
Stage 3
        定义了Conf业务（会议业务，传统网络中也称为三方通话或多方通话）的细节。

CONF标准包括了以下流程
1，建立会议：invite:conf factory uri，或invite:conf uri。 可能带uri list
        1.1 主席直接建立会议
        1.2 主席位于二路通话或一路通话中，并保持它们，主席建立会议。
        1.3 主席直接用conf uri来建立会议。 24.147的5.3.2.3.2，A.3.3图
                        按PSI触发，在MT侧做业务。

2，加入会议(可由主席邀请，分端到端与3PCC。 也可由AS邀请。也可由成员自已加入会议。)
        2.1 3PCC流程：主席发 对话内refer 给AS（req-uri=conf id），refer-to=远端用户，AS产生invite给远端用户。
                                        如会议建立前已有一路通话的话,refer中要带replace头。

  2.2 端到端流程：主席发 对话外refer 给远端用户(refer-to=conf id)(当是二方转三方时，这个refer是对话内refer)，后者UE收到后，发invite给conf id，以加入会议。
      见24.605的A.2.1， 24.147 的5.3.1.4.1, A.4.3.1.2图（是对话外refer）
                异常过程：见 24.605的4.5.2.1.2      的note2 与 4.5.2.2A      的最后一句话。 24.628的 4.7.2.9.7
                                当refer发出后，对端回403或503，AS给业务用户回notify+202，此后按3PCC流程，发invite（盲转）或reinvite(询问转)给 对端。即端到端流程失败时，AS自动转换为3PCC流程与reinvite流程。
                                A与B在原对话中交换allow时，AS就知道哪个UE是否支持refer（或运营商不愿意把refer发给对端，控制不执行 端到端流程）。则AS不用发refer给对端就可以自行开启3PCC流程。
          refer中如带replace也对路径上的B2BUA网元有要求。

        2.3 3PCC流程：主席在建立会议的invite中带uri list，AS分别发invite或re-invite（如是二方或一方转三方的话）给各uri。

        2.4 (这个流程在24.605中没有提到)AS主动发refer给UE，UE再发invite给AS以加入会议。3GPP 24.147的A.4.3.1.4图、5.3.2.5.5，5.3.2.5.1最后一句 

        2.5 (这个流程在24.605中没有提到)普通成员主动发invite给conf id， 24.147的5.3.1.4.1

3，离开会议、踢出会议
  3.1 主席或成员 主动发bye给AS。主席发bye则会议结束。
  3.2 主席踢人：发refer给AS，method=bye. 用refer-to表示踢一个人或所有人（会议结束）。
  3.3 AS主动bye用户（由本地管理员触发） 24.147的5.3.2.6.2.1， A.6.4.1图

4，成员订阅会议事件 
        主席在会议建立时收到conf id时发起订阅。
        成员在加入会议后，向conf id发起订阅。

5，BFCP协议（UE与MRFP之间，MRFC与AS未参与） 24.147中 8      Protocol for floor control for conferencing
    发言控制的流程：
    普通用户a申请发言，-> Flow control controler(即MRFP)
  controler 通知 会议主席。
  会议主席允许发言 -> controler
  controler通知 用户a及会议中其它用户。

    Conf业务同样分为端到端流程与3PCC流程。其区别同ECT业务。

Conf业务细节分析
许多细节问题同ECT业务。另外
细节1：Conf factory uri与conf uri的仔细设计，以用于IMS网内路由到会议AS。原因与设计原则同ECT业务。
细节2：端到端流程，普通成员发invite加入会议时，可能存在冒充问题，因为只要知道了conf uri就可以加入会议。如果主席没有订阅的话，就不知道会议中有哪些人。这是一个安全隐患。 可行的方法是：1）会议功能中要求 主席终端 必须订阅会议事件。这样主席用户可以知道哪些人加入了会议。 2） 每当一个用户加入会议，就向会议中所有成员放音，提示xx号码加入了会议。 
细节3：replace问题，同ECT业务。

细节4：端到端流程中， 因为终端发出refer的req-uri是另一个终端，这个呼叫实际上不会经过conf AS(不管是对话内，还是对话外refer）.

conf标准中的“If the AS determines that the REFER request shall not be sent to the remote UE and the AS decides to apply 3pcc the AS shall follow the special REFER handling procedures in 3GPP TS 24.628 [11]” 这句话不对。单从这句话看，这个AS一定是指端到端流程中的Conf AS，但已分析出refer不会经过conf AS，自然也不可能将之转化为3PCC流程。

通过 Wiz 发布