3GPP定义的两个IMS业务总纲性标准
3GPP TS 22.173
Multimedia Telephony Service and supplementary services;
Stage 1
(解释:可以看出,3GPP定义的
IMS补充业务体验主要来自于传统固网的用户体验。)
各业务都有单独标准来定义其功能需求、签约激活模式、业务流程、各角色的功能细节及业务冲突关系。
Three-Party前几年曾经看到过单独的标准,但最近几年合并到CONFerence (CONF)业务中。
3GPP TS 24.628
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(转接-询问转)。
Core Network (CN) subsystem;
Protocol specification
Explicit Communication Transfer (ECT)
Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystem;
Protocol specification
ECT标准中定义了四个流程
2,端到端流程-询问转
3,3PCC流程-盲转
4,3PCC流程-询问转
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的头上。
注1:实际运营中,出于运营商加强管理(即 禁止 不在运营商管控 下的端到端业务)的需要,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:AS-A虽然是非业务用户的AS,但也需要识别ECT业务。
注1:实际运营中,出于运营商加强管理(即 禁止 不在运营商管控 下的端到端业务)的需要,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流程 其中之一)
端到端流程 细节点3:ECT Session Identifier URI 生命期的作用
端到端流程 细节点4:必须有办法能让AS-B实时根据ECT Session Identifier URI识别出这路invite与转接有关。
注:
端到端流程 细节点5:refer所在dialog内同时存在invite usage与refer usage 的需求。
端到端流程 细节点6:AS-A对于 UE-A新发起invite ,是否要检查呼出限制?
端到端流程 细节点7:refer流程失败后的异常处理。
端到端流程 细节点8:AS如何判断收到的refer是否用于ECT、会议或其它业务?
端到端流程 细节点9:ECT Session Identifier URI的正确路由
端到端流程 细节点10(重点):replace流程是否用reinvite流程代替。
注1:在部分业务场景中,replace也无法使用,比如旧呼叫发生了无应答前转业务,新呼叫发给被叫后,被叫会无法在本地找到旧呼叫的dialog id,而导致流程失败。
注2:
注3:标准化组织提出了draft-ietf-insipid-session-id-reqts-00.txt,也许session id头可以代替replace头的原作用,这个头不被B2BUA网元所修改,旧呼叫中产生并端到端的传递它,而新呼叫中可以携带旧呼叫同样的session id,一直透传给被叫终端,被叫终端据此可以bye掉旧呼叫。(这时,即使呼叫中间的信令路径有改变,或B2BUA网元不修改replace头,但两端终端仍是识别session id的,依靠它可以关联两个呼叫)
其它细节:ECT与ECT的嵌套,ECT与会议的嵌套,ECT与限制类业务的嵌套,。。。
=============================
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业务(会议业务,传统网络中也称为三方通话或多方通话)的细节。
3GPP TS 24.605
Protocol specification
与3GPP TS 24.147
Conferencing using the IP Multimedia (IM)
Core Network (CN) subsystem;
Stage 3
CONF标准包括了以下流程
1,建立会议:invite:conf factory uri,或invite:conf uri。 可能带uri list
2,加入会议(可由主席邀请,分端到端与3PCC。 也可由AS邀请。也可由成员自已加入会议。)
3,离开会议、踢出会议
4,成员订阅会议事件
5,BFCP协议(UE与MRFP之间,MRFC与AS未参与) 24.147中 8
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流程。