呼叫处理方法、装置及系统.pdf

本发明公开了呼叫处理方法、装置及系统，其中，该方法包括：采用接入切换控制功能ATCF判断ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；在ATCF至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。通过本发明解决了相关技术中ATCF确定采用的锚定媒体切换并没有起到相应的作用，从而使ATCF能够更好的确定在什么情况下采用锚定媒体的方式。

权利要求书1.  一种呼叫处理方法，其特征在于，包括：接入切换控制功能ATCF判断所述ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；所述ATCF至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。2.  根据权利要求1所述的方法，其特征在于，还包括：所述ATCF接收来自所述一个或多个网元的消息，其中，所述消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。3.  根据权利要求2所述的方法，其特征在于，所述ATCF接收来自所述一个或多个网元的所述消息包括：所述ATCF将接收到的注册请求消息和/或呼叫请求消息发送给所述一个或多个网元；所述ATCF接收来自所述一个或多个网元的注册响应消息和/或呼叫响应消息，其中，所述注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。4.  根据权利要求1所述的方法，其特征在于，所述ATCF判断所述一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫包括：所述ATCF在向所述一个或多个网元发送注册请求消息之后，接收来自所述一个或多个网元的注册响应消息；所述ATCF根据所述注册响应消息中携带的路由信息和/或所述ATCF本地策略进行所述判断。5.  根据权利要求1至4中任一项所述的方法，其特征在于，还包括：所述ATCF将切换呼叫路由到所述一个或多个网元；所述一个或多个网元根据所述被切换呼叫的标识将所述被切换呼叫的媒体资源移交给所述切换呼叫。6.  根据权利要求5所述的方法，其特征在于，所述一个或多个网元将所述被切换呼叫的媒体资源移交给所述切换呼叫包括：所述一个或多个网元将所述被切换呼叫的媒体资源中的部分移交给所述切换呼叫；将未移交的媒体资源保留给原呼叫使用。7.  根据权利要求1至4中任一项所述的方法，其特征在于，还包括：所述ATCF在判断结果为否的情况下，不进行锚定媒体创建呼叫或/和不进行锚定媒体切换呼叫。8.  一种呼叫处理装置，其特征在于，位于接入切换控制功能ATCF中，所述装置包括：判断模块，用于判断所述ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；处理模块，用于至少根据为“是”的判断结果，锚定媒体创建呼叫和锚定媒体切换呼叫。9.  根据权利要求8所述的装置，其特征在于，还包括：接收模块，用于接收来自所述一个或多个网元的消息，其中，所述消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否可以用于切换呼叫的信息。10.  根据权利要求9所述的装置，其特征在于，所述接收模块包括：发送单元，用于将接收到的注册请求消息和/或呼叫请求消息发送给所述一个或多个网元；第一接收单元，用于接收来自所述一个或多个网元的注册响应消息和/或呼叫响应消息，其中，所述注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否可以用于切换呼叫的信息。11.  根据权利要求8所述的装置，其特征在于，处理模块包括：第二接收单元，用于在向所述一个或多个网元发送注册请求消息之后，接收来自所述一个或多个网元的注册响应消息；判断单元，用于根据所述注册响应消息中携带的路由信息和/或所述ATCF本地策略进行所述判断。12.  根据权利要求8至11中任一项所述的装置，其特征在于，所述处理模块还用于在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。13.  一种呼叫处理系统，其特征在于，包括权利要求8至12中任一项所述的装置，所述装置还包括：路由模块，用于将切换呼叫路由到所述一个或多个网元；所述系统还包括：所述一个或多个网元，用于根据所述被切换呼叫的标识将所述被切换呼叫的媒体资源移交给所述切换呼叫。14.  根据权利要求13所述的系统，其特征在于，所述一个或多个网元用于将所述被切换呼叫的媒体资源中的部分移交给所述切换呼叫；将未移交的媒体资源保留给原呼叫使用。

说明书呼叫处理方法、装置及系统
技术领域
本发明涉及通信领域，更具体的涉及呼叫处理方法、装置及系统。
背景技术
IP多媒体子系统（IP Multimedia Core Network Subsystem，简称IMS）是由第三代合作伙伴计划（3rd Generation Partnership Project，简称3GPP）组织提出的一种基于IP的网络架构，其构建了一个开放而灵活的业务环境，支持多媒体应用，并为用户提供丰富的多媒体业务。
目前，移动通信以电路交换（Circuit Switched，简称CS）网络为主，如全球移动通信系统(Global System for Mobile Communications，简称GSM)和码分多址（Code Division Multiple Access，简称CDMA）等。在TS24.292、3GPP TS23.237和3GPP TS24.237等规范中已经有使用接入切换控制功能（Access Transfer Control Functionality，简称ATCF）实现分组交换（Packet Switch，简称PS）和CS之间切换的信令和流程描述，例如使用增强的单一无线语音连续呼叫（Enhanced Single Radio Voice Call Continuity，简称为eSRVCC）技术。
然而，在相关技术中存在的问题是：使用eSRVCC技术进行锚定媒体切换，漫游用户发生切换，如果用户的拜访域网元接入切换控制功能（Access Transfer Control Functionality，简称ATCF）与其归属域之间有一个或多个网元实现媒体管理，例如互联边界控制功能实体（Interconnection Border Control Function，简称为IBCF），按相关技术进行锚定媒体切换，并不能加快媒体切换速度。发明人发现，这其中原因在于：虽然ATCF采用了锚定媒体切换，但由于在IBCF中创建了新的呼叫，创建了新的媒体资源，连续性应用服务器（简称为SCC AS）收到的切换呼叫invite消息的媒体并不同于被切换的呼叫的媒体，就会与远端进行媒体协商，并用协商结果来修改接入切换网关（Access Transfer GateWay，简称为ATGW）的远端媒体，在此流程结束后才能实现正常通话。
因此，在相关技术中，ATCF确定采用的锚定媒体切换并没有起到相应的作用。
发明内容
本发明提供了呼叫处理方法、呼叫处理装置及呼叫处理系统，以至少解决相关技术中ATCF确定采用的锚定媒体切换并没有起到相应的作用的问题。
根据本发明的一个方面，提供了一种呼叫处理方法，包括：接入切换控制功能ATCF判断所述ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；所述ATCF至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。
优选地，所述ATCF接收来自所述一个或多个网元的消息，其中，所述消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
优选地，所述ATCF接收来自所述一个或多个网元的所述消息包括：所述ATCF将接收到的注册请求消息和/或呼叫请求消息发送给所述一个或多个网元；所述ATCF接收来自所述一个或多个网元的注册响应消息和/或呼叫响应消息，其中，所述注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
优选地，所述ATCF判断所述一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫包括：所述ATCF在向所述一个或多个网元发送注册请求消息之后，接收来自所述一个或多个网元的注册响应消息；所述ATCF根据所述注册响应消息中携带的路由信息和/或所述ATCF本地策略进行所述判断。
优选地，所述ATCF将切换呼叫路由到所述一个或多个网元；所述一个或多个网元根据所述被切换呼叫的标识将所述被切换呼叫的媒体资源移交给所述切换呼叫。
优选地，所述一个或多个网元将所述被切换呼叫的媒体资源移交给所述切换呼叫包括：所述一个或多个网元将所述被切换呼叫的媒体资源中的部分移交给所述切换呼叫；将未移交的媒体资源保留给原呼叫使用。
优选地，所述ATCF在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。
根据本发明的另一个方面，还提供了一种呼叫处理装置，在位于接入切换控制功能ATCF中，所述装置包括：判断模块，用于判断所述ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；处理模块，用于至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。
优选地，还包括：接收模块，用于接收来自所述一个或多个网元的消息，其中，所述消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
优选地，所述接收模块包括：发送单元，用于将接收到的注册请求消息和/或呼叫请求消息发送给所述一个或多个网元；第一接收单元，用于接收来自所述一个或多个网元的注册响应消息和/或呼叫响应消息，其中，所述注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
优选地，处理模块包括：第二接收单元，用于在向所述一个或多个网元发送注册请求消息之后，接收来自所述一个或多个网元的注册响应消息；判断单元，用于根据所述注册响应消息中携带的路由信息和/或所述ATCF本地策略进行所述判断。
优选地，所述处理模块还用于在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。
根据本发明的另一个方面，还提供了一种呼叫处理系统，包括所述的装置，其中，所述装置还包括：路由模块，用于将切换呼叫路由到所述一个或多个网元；所述系统还包括：所述一个或多个网元，用于根据所述被切换呼叫的标识将所述被切换呼叫的媒体资源移交给所述切换呼叫。
优选地，所述一个或多个网元用于将所述被切换呼叫的媒体资源中的部分移交给所述切换呼叫；将未移交的媒体资源保留给原呼叫使用。
通过本发明，采用接入切换控制功能ATCF判断ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；在ATCF至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。解决了相关技术中ATCF确定采用的锚定媒体切换并没有起到相应作用的问题，从而使ATCF能够更好的确定在什么情况下采用锚定媒体的方式。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的呼叫处理方法的流程图；
图2是根据本发明实施例的呼叫处理装置的结构框图；
图3是根据本发明实施例的呼叫处理装置的优选结构框图一；
图4是根据本发明实施例的呼叫处理装置的优选结构框图二；
图5是根据本发明实施例的呼叫处理装置的优选结构框图三；
图6是根据本发明实施例的呼叫处理系统的结构框图；
图7是根据本发明实施例的为ATCF在注册流程中获知后续呼叫是否经过IBCF以及是否所经过的IBCF都支持被切换呼叫的“媒体资源”在切换呼叫中使用的流程图；
图8是根据本发明实施例的ATCF接入用户做主叫确定采用锚定媒体方式创建PS呼叫的流程图一；
图9是根据本发明实施例的ATCF接入用户做被叫确定采用锚定媒体方式创建PS呼叫的流程图；
图10是根据本发明实施例的ATCF接入用户做主叫确定采用锚定媒体方式创建PS呼叫的流程图二；
图11是根据本发明实施例的使用ATCF实现由PS接入切换为CS接入的呼叫流程图。
具体实施方式
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
本实施例中，提供了一种呼叫处理方法，图1是根据本发明实施例的呼叫处理方法的流程图，如图1所示，该流程包括如下步骤：
步骤S102，接入切换控制功能ATCF判断ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元（例如，IBCF，下文中以IBCF为例进行说明）是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；
步骤S104，ATCF至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。
通过上述步骤，ATCF在判断是否采用锚定媒体方式时考虑了实现媒体管理的一个或多个网元能否支持将为被切换呼叫创建的媒体资源用于切换呼叫，如果支持，则这些网元可以使用为被切换呼叫创建的媒体资源，从而不需要进行媒体协商，ATCF采用锚定媒体方式就能够起到相应的作用。
优选地，该ATCF可以在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。当然，可以也在判断结果为否的情况下，根据其他条件确定来采用锚定媒体的方式。
ATCF判断IBCF用于实现媒体管理以及是否支持将为被切换呼叫创建的媒体资源用户切换呼叫方式有很多种，在一种优选方式中，ATCF接收来自一个或多个IBCF的消息，其中，该消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否可以用于切换呼叫的信息。通过这种方式，IBCF通过消息上报自己的能力，从而为ATCF的判断提供依据。
在实施时，可以通过现有的消息来携带这些信息，也可以通过新增加的消息来携带这些信息。
例如，ATCF可以将接收到的注册请求消息和/或呼叫请求消息发送给该一个或多个网元（例如，IBCF）；ATCF接收来自上述一个或多个网元的注册响应消息和/或呼叫响应消息，其中，该注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否可以用于切换呼叫的信息。
在另一种方式中，还可以由ATCF来进行判断。例如，ATCF在向上述一个或多个网元发送注册请求消息之后，接收来自该一个或多个网元的注册响应消息；ATCF根据该注册响应消息中携带的路由信息和/或该ATCF本地策略进行该判断这个或者这些网元是否支持将为被切换呼叫创建的媒体资源是否能够用于切换呼叫。
ATCF可以通过多种方式来指示上述一个或多个网元将被切换呼叫的媒体资源移交给该切换呼叫，例如，ATCF将切换呼叫路由到该一个或多个网元；该一个或多个网元根据该被切换呼叫的标识将该被切换呼叫的媒体资源移交给该切换呼叫。
优选地，上述一个或多个网元可以只移交部分资源，即可以将该被切换呼叫的媒体资源中的部分移交给该切换呼叫；将未移交的媒体资源保留给原呼叫使用。
优选地，该ATCF在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。
在本实施例中还提供了一种呼叫处理装置，该装置用于实现上述方法，在上述方法中已经进行过说明的在此不再赘述，以下该装置中的模块的名称不应当理解为对该模块的限定，例如，判断模块用于判断该ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫，也可以表述为“一种用于判断该ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫的模块”，下面所描述的模块的功能可以通过处理器来实现。图2是根据本发明实施例的呼叫处理装置的结构框图，如图2所示，该装置包括：判断模块22，用于判断ATCF与连续性应用服务器SCC AS之间的所有实现媒体管理的一个或多个网元是否均支持将为被切换呼叫创建的媒体资源用于切换呼叫；处理模块24，用于至少根据为“是”的判断结果，锚定媒体创建呼叫和/或锚定媒体切换呼叫。
图3是根据本发明实施例的呼叫处理装置的优选结构框图一，如图3所示，该装置还包括：接收模块32，用于接收来自该一个或多个网元的消息，其中，该消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
图4是根据本发明实施例的呼叫处理装置的优选结构框图二，如图4所示，接收模块32包括：发送单元42，用于将接收到的注册请求消息和/或呼叫请求消息发送给该一个或多个网元；第一接收单元44，用于接收来自该一个或多个网元的注册响应消息和/或呼叫响应消息，其中，该注册响应消息和/或呼叫响应消息中携带有该网元是否实现媒体管理的信息，以及为被切换呼叫创建的媒体资源是否能够用于切换呼叫的信息。
图5是根据本发明实施例的呼叫处理装置的优选结构框图三，如图5所示，处理模块24包括：第二接收单元52，用于在向一个或多个网元发送注册请求消息之后，接收来自一个或多个网元的注册响应消息；判断单元54，用于根据该注册响应消息中携带的路由信息和/或ATCF本地策略进行判断。
优选地，处理模块24还用于在判断结果为否的情况下，不进行锚定媒体创建呼叫和/或不进行锚定媒体切换呼叫。
在本实施例中，还提供了一种呼叫处理系统，图6是根据本发明实施例的呼叫处理系统的结构框图，如图6所示，包括上述装置，其中，该装置还包括：路由模块26，用于将切换呼叫路由到该一个或多个网元；该系统还包括：该一个或多个网元，用于根据该被切换呼叫的标识将该被切换呼叫的媒体资源移交给该切换呼叫。
优选地，该一个或多个网元用于将该被切换呼叫的媒体资源中的部分移交给该切换呼叫；将未移交的媒体资源保留给原呼叫使用。
下面结合优选实施例进行说明。本优选实施例结合了上述实施例及其优选实施方式。在本优选实施例中提供了不同于已有规范的呼叫流程。以适应漫游用户的eSRVCC的锚定媒体 呼叫切换需求。在本优选实施例中，ATCF是否对eSRVCC用户的呼叫锚定媒体以及是否采用锚定媒体切换，除按现有技术判断外，还使用ATCF与SCC AS之间是否有IBCF，以及所经过的IBCF是否都支持其为被切换创建的媒体资源用于切换呼叫进行判断。如果支持，则锚定媒体创建呼叫与锚定媒体切换呼叫，否则采用不锚定媒体方式。
在本优选实施例中，可以通过注册或呼叫流程，或ATCF根据配置等确定通过ATCF接入的用户在呼叫中，在ATCF与SCC AS之间是否有实现媒体管理（或称为穿越，后续简称媒体管理）的一个或多个网元（后续简称IBCF），以及这些IBCF是否都支持IBCF为被切换呼叫创建的“媒体资源”在切换呼叫中使用。
如果ATCF接入的用户在呼叫中，在ATCF与SCC AS之间有IBCF，但并不是所有的IBCF都支持IBCF为被切换呼叫创建的“媒体资源”在切换呼叫中使用，那么ATCF在创建（被切换）呼叫时，将不锚定媒体。如果ATCF接入的用户在呼叫中，在ATCF与SCC AS之间有IBCF，但所经过的IBCF都支持IBCF为被切换呼叫创建的“媒体资源”在切换呼叫中使用，且按现有技术的其它判断条件，满足锚定媒体创建呼叫，那么ATCF在创建（被切换）呼叫时，将锚定媒体。
在切换时，如果被切换呼叫经过了IBCF（即所经过的IBCF都支持IBCF为被切换呼叫创建的“媒体资源”在切换呼叫中使用），ATCF按现有技术实现锚定媒体切换与eMSC进行交互，并将切换呼叫路由到IBCF。采用携带适当的路由信息或IBCF配合，保证将切换呼叫经过被切换呼叫的ATCF与SCC AS之间的所有IBCF网元。IBCF根据切换呼叫invite中指定的被切换呼叫CALLID（会话唯一标识）以及邀请消息（invite）中的会话描述协议（Session Description Protocol，简称为SDP）相同于被切换呼叫的SDP，将被切换呼叫的“媒体资源”移交给切换呼叫。如果是部分媒体切换（即invite中的SDP部分相同于被切换呼叫的SDP），则只移交被切换部分的媒体给切换呼叫，未切换的媒体，仍留给原呼叫使用。
如果ATCF和IBCF不支持本优选实施例的功能，将按现有技术实现呼叫与呼叫切换。如果ATCF与SCC AS之间无IBCF，按现有技术实现。如果结合现有技术与本优选实施例的判断原则，ATCF判断为不锚定媒体创建呼叫与进行切换，可以按现有技术实现。
通过本优选实施例，如果IBCF支持媒体复用，能加快漫游用户的媒体切换速度，提高用户感受，IBCF也不需要为切换呼叫创建新的媒体资源，能减少对IBCF的资源占用。如果IBCF不支持媒体复用，能减少对ATGW的资源占用，节省网络资源。
下面结合附图对本优选实施例进行说明。
图7是根据本发明实施例的为ATCF在注册流程中获知后续呼叫是否经过IBCF以及是否所经过的IBCF都支持被切换呼叫的“媒体资源”在切换呼叫中使用的流程图。在图7中，ATCF参与的PS接入注册流程，在注册流程中获知后续呼叫是否经过IBCF以及是否所经过的IBCF都支持被切换呼叫的“媒体资源”在切换呼叫中使用。如图7所示，该流程包括如下步骤：
步骤S701，ATCF收到来自于P-CSCF的注册请求消息。
步骤S702-703，按现有技术，ATCF在经过IBCF发给I-CSCF注册请求消息中携带PS-CS间切换的相关信息。
步骤S704-706，按现有技术实现。
步骤S707，IBCF在注册成功响应消息中填写IBCF（此为呼叫流程会经过的IBCF）是否实现媒体管理，以及为被切换呼叫创建的媒体资源是否可以用于切换呼叫。
步骤S708，给用户回注册成功响应。
如果在步骤S707中IBCF不能准确标识，ATCF也可以根据注册响应中的路由信息并结合配置与本地策略进行判断。
图8是根据本发明实施例的ATCF接入用户做主叫确定采用锚定媒体方式创建PS呼叫的流程图一，在图8中ATCF接入用户做主叫，根据该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫。如图8所示，该流程包括如下步骤：
步骤S801，ATCF收到来自于P-CSCF的呼叫请求消息。
步骤S802，ATCF接入用户做主叫，根据该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫,创建锚定媒体资源。
步骤S803，ATCF将呼叫按现有技术进行路由，呼叫请求消息中携带的媒体为锚定媒体。可选的，在呼叫请求消息中标识ATCF身份，并标识对呼叫进行了媒体锚定。
步骤S804，IBCF按现有技术对呼叫进行媒体管理，创建媒体资源，按现有技术进行路由。可选的，在呼叫请求消息中标识IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S805-S807，同现有技术。
步骤S808，IBCF按现有技术对呼叫进行媒体管理，按现有技术转发呼叫响应消息。可选的，在呼叫响应消息中标识该IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S809，同现有技术。
在上述步骤中，如果判断为不锚定媒体创建呼叫，流程同现有技术。如果在呼叫中进行媒体修改，ATCF与IBCF对媒体的操作同现有技术。可选的，可以在消息中标识自己的身份以及ATCF是否锚定媒体和IBCF是否支持在切换呼叫中使用被切换呼叫的“媒体资源”。如果在呼叫中，ATCF与SCC AS之间经过多个IBCF，每个IBCF的处理与步骤S804和S807相似。
图9是根据本发明实施例的ATCF接入用户做被叫确定采用锚定媒体方式创建PS呼叫的流程图，在图9中ATCF接入用户做被叫，根据该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫。如图9所示，该流程包括如下步骤：
步骤S901-S902，ATCF接入用户做被叫，其所在漫游地的IBCF收到来自于其归属地的 呼叫请求，如果路由过IBCF，IBCF在其转发的信令中标识其IBCF身份，并标识其支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S903，IBCF按现有技术对呼叫进行媒体管理，创建媒体资源，按现有技术进行路由。可选的，在呼叫请求消息中标识IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S904，ATCF根据注册信息或/和收到的呼叫请求消息，和/或本端策略，得知该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫,创建锚定媒体资源。
步骤S905-S907，同现有技术。
步骤S908，ATCF将呼叫按现有技术转发呼叫响应消息。可选的，在呼叫响应消息中标识ATCF身份，并标识对呼叫进行了媒体锚定。
步骤S909，IBCF按现有技术对呼叫进行媒体管理，按现有技术转发呼叫响应消息。可选的，在呼叫响应消息中标识该IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S910，同现有技术。
在上述步骤中，如果判断为不锚定媒体创建呼叫，流程同现有技术。如果在收到响应消息后确定是否创建锚定媒体，流程类似，具体流程图从略。在呼叫中进行媒体修改，ATCF与IBCF对媒体的操作同现有技术。可选的，可以在消息中标识自己的身份以及ATCF是否锚定媒体和IBCF是否支持在切换呼叫中使用被切换呼叫的“媒体资源”。如果在呼叫中，ATCF与SCC AS之间经过多个IBCF，每个IBCF的处理与步骤S903和S909相似。
图10是根据本发明实施例的ATCF接入用户做主叫确定采用锚定媒体方式创建PS呼叫的流程图二，在图10中ATCF接入用户做主叫，根据该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫。如图10所示，该流程包括如下步骤：
步骤S1001，ATCF收到来自于P-CSCF的呼叫请求消息。
步骤S1002，ATCF接入用户做主叫，根据该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫,但由于呼叫请求中没有携带媒体信息，暂时不创建媒体资源。ATCF将呼叫按现有技术进行路由。可选的，在呼叫请求消息中标识ATCF身份，并标识可以在收到携带媒体信息的响应消息之后创建媒体资源。
步骤S1003，IBCF按现有技术对呼叫按现有技术进行路由。可选的，在呼叫请求消息中标识IBCF身份，并标识在收到携带媒体的响应消息后将对呼叫进行媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S1004-S1006，同现有技术。
步骤S1007，IBCF按现有技术对呼叫进行媒体管理，创建媒体资源，按现有技术转发呼叫响应消息。可选的，在呼叫响应消息中标识IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S1008，ATCF根据注册信息或/和收到的呼叫响应消息，和/或本端策略，得知该呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式创建PS呼叫,创建锚定媒体资源。
步骤S1009-S1011，同现有技术。
步骤S1012，ATCF将呼叫按现有技术转发呼叫响应确认消息。可选的，在呼叫响应确认消息中标识ATCF身份，并标识对呼叫进行了媒体锚定。
步骤S1013，IBCF按现有技术对呼叫进行媒体管理，按现有技术转发呼叫响应确认消息。可选的，在呼叫响应确认消息中标识该IBCF身份，并标识对呼叫进行了媒体锚定（此处或称为媒体管理），以及支持在切换呼叫中使用被切换呼叫的“媒体资源”。
步骤S1014，同现有技术。
在上述步骤中，如果判断为不锚定媒体创建呼叫，流程同现有技术。在呼叫中进行媒体修改，ATCF与IBCF对媒体的操作同现有技术。可选的，可以在消息中标识自己的身份以及ATCF是否锚定媒体和IBCF是否支持在切换呼叫中使用被切换呼叫的“媒体资源”。如果在呼叫中，ATCF与SCC AS之间经过多个IBCF，每个IBCF的处理与步骤S1003、S1007和S1013相似。
图11是根据本发明实施例的使用ATCF实现由PS接入切换为CS接入的呼叫流程图，如图11所示，该流程包括如下步骤：
步骤S1101，ATCF收到来自于eMSC Server或PS-CS会话切换请求消息。
步骤S1102，ATCF根据被切换呼叫经过的ATCF与SCC AS之间的IBCF都支持在切换呼叫中使用被切换呼叫的“媒体资源”，以及其它现有判断原则，确定采用锚定媒体方式切换呼叫。
步骤S1103-S1104，同现有技术流程。
步骤S1105，将呼叫路由到原PS呼叫与ATCF邻接的IBCF。并在发送的invite消息按顺序携带原PS呼叫经过的IBCF的路由信息和被切换呼叫的CALLID（会话唯一标识）。
步骤S1106，各个IBCF根据收到的invite消息中的被切换呼叫的CALLID（会话唯一标识）信息，以及判断出切换呼叫与被切换呼叫的媒体信息相同，IBCF将被切换呼叫的媒体资源给切换呼叫使用，以此实现IBCF上的切换呼叫的媒体与被切换呼叫的媒体保持不变。
步骤S1107，将切换呼叫路由到后向的IBCF（如果后向还有被切换呼叫经过的IBCF的话）或SCC AS（如果在被切换呼叫路由中，该IBCF后向就是SCC AS）。该路由策略既可取自于前向invite携带的route信息，也可来自于本IBCF的本地策略。
步骤S1108-S1112，同现有技术。
在上述步骤中，仅是应答后的切换流程，应答前的切换流程，midcall切换流程、additional切换流程类似，具体流程从略。如果在步骤S1106判断出媒体信息只是部分相同，那么只将相同部分的被切换呼叫的媒体资源移给切换呼叫使用，不相同的部分继续留给被切换呼叫。
在上述图所示出的流程中，注册/订阅中是否鉴权，没有在示意流程中体现。各个图中的各个网元之间的消息，主要是为了清楚的表示接入网切换信息的获取以及呼叫切换的思想。在具体的实现中，不局限于这些网元和消息。对于各种流程中出现的异常情况、在可以的情况下某些消息的先后顺序、网元内部的具体实现并不做具体的限制。IBCF是否支持被切换呼叫的“媒体资源”在切换呼叫中使用，如果没有在注册流程中携带，也不采用ATCF的本地策略判断，则可以采用在呼叫流程做类似携带。CS接入IMS注册，CS接入IMS呼叫以及CS-PS切换流程，可做类似处理。在实现中，ATCF和P-CSCF既可以合一，也可以分离。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。