CN101155173B - 电路域感知ims域多媒体会话媒体信息的方法及*** - Google Patents
电路域感知ims域多媒体会话媒体信息的方法及*** Download PDFInfo
- Publication number
- CN101155173B CN101155173B CN 200610152690 CN200610152690A CN101155173B CN 101155173 B CN101155173 B CN 101155173B CN 200610152690 CN200610152690 CN 200610152690 CN 200610152690 A CN200610152690 A CN 200610152690A CN 101155173 B CN101155173 B CN 101155173B
- Authority
- CN
- China
- Prior art keywords
- scp
- ssf
- message
- information
- media
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1073—Registration or de-registration
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种电路域感知IMS域多媒体会话媒体信息的方法及***，用以解决现有技术中电路域智能业务控制实体无法感知IMS域多媒体会话媒体信息的问题。本发明方法包括：业务交换功能实体IM-SSF从收到的IMS域会话控制信令中获取多媒体会话媒体信息；以及IM-SSF将获取的多媒体会话媒体信息上报给智能业务控制实体SCP。本发明的***，包括：HSS、SCP和S-CSCF，还包括与HSS、SCP和S-CSCF分别相连的IM-SSF；IM-SSF与SCP之间存在接口。本发明可使电路域智能业务控制实体感知IMS域多媒体会话媒体信息。
Description
技术领域
本发明涉及通信领域，特别是涉及一种电路域感知IMS域多媒体会话媒体信息的方法及***。
背景技术
下一代通信网的承载已经全面开始换用IP。从通信网的发展来看，不管是CDMA还是GSM/WCDMA，都经历了从传统电路交换网络到控制承载分离的IP包交换网络再到全IP的多媒体网络这样一个演进过程。以CDMA的演进为例：CDMA网络承载从最初的TDM承载，到定义了LMSD和MMD两个演进阶段，选择IP作为核心网及接入网的承载选择，并且A接口在承载类型上选择IP；CDMA LMSD阶段电路域实现了承载和控制的分离，在承载类型上支持IP；MMD版本则在核心网引入IMS域，接口信令IP化(SIP)。这个演进过程中的最终目标是由统一的IMS网络来提供业务。
另一方面，1984年美国贝尔通信公司与美国技术公司提出了智能网的概念，它是一个能够快速、方便、灵活、经济、有效地生成和实现各种新业务的体系，具有业务处理和呼叫处理相分离的设计特点。因为智能网具有以上优点，传统电路域迅速引入了智能网架构，其中固定网络定义了智能网应用规程(INAP，Intelligent Network Application Protocol)，GSM/WCDMA为实现智能业务，引入了移动网增强逻辑客户化应用(CAMEL，Customised Application forMobile network Enhanced Logic)，CDMA移动通信***定义了一系列无线智能网(WIN，Wireless Intelligent Network)协议。以上这些智能网架构都是基于传统电路域的，当传统电路域过渡到IMS网络后，仍有必要把智能网引入到IMS域，GSM/WCDMA已经把CAMEL功能架构引入到IMS域，并定义了相 关标准(TS23.278)，而CDMA目前还没有相关标准来定义如何把基于WIN的智能网引入到IMS域。
一、现有CDMA传统电路域的智能业务实现流程。
CDMA传统电路域向用户提供了很多种智能业务，如PPC(预付费)，FPH(被加付费)，ICS(入呼筛选)等业务，以下以PPC业务为例，说明CDMA传统电路域智能业务的实现机制。
●传统电路域用户签约PPC业务并发起主叫的流程参见图1所示，包括下列步骤：
1.用户通过BSC向MSC/SSF发送始呼请求，携带被叫号码和主叫用户标识。
2.MSC/SSF判断主叫用户签约了Origination_Attempt_Authorized触发器，根据该触发器记录的SCP地址，向SCP发送ORREQ消息，携带主叫用户标识。
3.SCP检查用户激活了PPC业务且用户具有足够的帐户余额则向MSC/SSF返回orreq，指示呼叫继续。
4.MSC/SSF判断主叫用户签约了Calling_Routing_Address_Available触发器，根据该触发器对应的地址向SCP发送ANLYZD，携带根据被叫号码得到的被叫路由信息。
5.SCP根据ANLYZD里的被叫路由信息，决定主叫用户通话的费率，向MSC/SSF返回anlyzd，指示呼叫继续。
6.MSC/SSF根据路由信息，向被叫用户归属网络发送始呼消息(通过局间控制信令)。
7.被叫网络返回被叫振铃消息，向主叫用户发送回铃音。
8.被叫网络返回用户应答。
9.MSC/SSF判断主叫用户签约了O_Answer触发器，根据该触发器对应的地址向SCP发送OANSWER消息，携带被叫用户应答时间，SCP根据该时 间开始计费。
●传统电路域用户签约PPC业务作为被叫的流程参见图2所示，包括下列步骤：
1.MSC/SSF接收到始呼请求。
2.MSC/SSF判断被叫用户是移动用户，到被叫归属的HLR获取被叫路由信息。
3.HLR判断用户签约了PPC业务，则返回对应的智能触发器列表和被叫用户标识。
4.MSC/SSF根据HLR返回的信息，判断用户签约了Initial_Termination触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD消息，携带被叫用户标识。
5.SCP检查被叫用户激活了PPC业务且用户具有足够的帐户余额则向MSC/SSF返回anlyzd，指示呼叫继续。
6.MSC/SSF再次到HLR获取被叫路由信息，携带trigtype参数，以区分第一次取路由。
7.HLR返回termlist，指示被叫用户当前处于MSC/SSF管辖范围内(如果用户漫游到其他MSC，则HLR会返回能够路由到其他MSC的路由信息)。
8.MSC/SSF判断被叫用户签约了Called_Routing_Address_Available触发器，根据该触发器对应的地址向SCP发送ANLYZD，携带根据HLR返回消息得到的被叫路由信息。
9.SCP根据ANLYZD里的被叫路由信息，决定被叫用户通话的费率，向MSC/SSF返回anlyzd，指示呼叫继续。
10～11.因为被叫用户就在本MSC/SSF，MSC/SSF向下属BSC发送寻呼请求消息，BSC返回寻呼响应(如果被叫用户漫游到其他MSC，则MSC/SSF根据HLR返回的路由信息，向对应的MSC发送始呼消息，被叫号码为路由号码)。
12～13.MSC/SSF向下属BSC发送指配消息，分配呼叫所需资源，BSC返回指配完成，此时被叫用户开始振铃。
14.MSC/SSF向主叫侧返回被叫振铃。
15.被叫用户返回应答消息。
16.MSC/SSF判断被叫用户签约了T_Answer触发器，根据该触发器对应的地址向SCP发送TANSWER消息，携带被叫用户应答时间，SCP根据该时间开始计费。
17.MSC/SSF向主叫侧返回被叫应答。
从以上CDMA传统电路域智能业务流程可以看出，对于智能网业务，MSC/SSF的主要功能就是接受到呼叫控制信令后(可以来自于接入网，也可为来自于其他MSC)，根据该呼叫控制信令包含的信息，判断是否满足用户签约的智能触发器条件，如果满足，则与SCP交互，向SCP提供呼叫相关的信息，SCP根据该信息完成相关智能业务。需要说明的一点是，CDMA传统电路域的MSC/SSF仅处理语音呼叫一种业务，所以在与SCP的所有智能交互中，都不携带业务类型(默认就是语音)。
二、IMS域的多媒体会话。
IMS域用户可以进行多媒体会话(即包括语音，视频等多种媒体流的会话)，这些媒体流承载在IP之上。当主被叫建立通话时，因为主被叫终端能力不同或者主被叫网络状况的不同，需要主被叫用户对多媒体会话进行协商，以建立双方都认可的会话。
●IMS域普通的呼叫建立流程参见图3所示，包括下列步骤：
1.UE1通过P_CSCF向主叫用户注册的S_CSCF发送始呼请求(图中省略起见，没有画出P_CSCF)，请求消息中包含呼叫要建立的语音，视频等媒体流信息(媒体流信息包括主叫侧支持的每种媒体流的编码方案以及为每种媒体流分配的带宽等信息)。
2.S_CSCF根据始呼消息中的被叫方信息(request url携带)，找到被叫归 属网络，向被叫归属的I_CSCF转发呼叫请求(如果主叫用户签约了其他业务，则S_CSCF会根据用户签约的iFC，将始呼请求转发到AS，AS处理完后，再返回给S_CSCF，由S_CSCF继续进行路由)。
3.被叫归属网络的I_CSCF通过与被叫用户归属的HSS交互，得知被叫用户注册的S_CSCF，将呼叫请求转发到被叫用户注册的S_CSCF(图中省略起见，没有画出I_CSCF与HSS交互的过程)。
4.被叫用户注册的S_CSCF根据注册时记录的用户地址，通过P_CSCF向被叫用户发送始呼请求(图中省略起见，没有画出P_CSCF)。注：同主叫一样S_CSCF也可根据被叫用户签约的约的iFC，将始呼请求转发到AS，AS处理完后，再返回给S_CSCF，由S_CSCF继续向被叫用户发送始呼请求。
5.被叫用户返回183消息，指示被叫用户当前仅能接收语音媒体成分，以及语音媒体成分所支持的编码方案(可有多种)和为语音媒体流分配的带宽，该消息根据始呼请求时建立的路径原路返回主叫用户。
6.主叫用户返回183响应的确认消息(PRACK)，携带主叫用户最终选择的语音编码方案(仅一种)，根据接收到183响应消息里记录的路由路径，发送到被叫用户(I_CSCF仅用于初始请求的路由，后续请求不在经由I_CSCF)。
7.被叫用户返回PRACK的响应消息，携带的媒体信息与接收到的一致(媒体流协商完成)。
8.主叫用户完成主叫侧资源预留后，向被叫侧发送UPDATE消息，指示主叫侧资源预留完成。
9.被叫用户返回UPDATE的响应消息。
10.被叫用户完成资源预留后，返回180振铃消息。
11.主叫用户返回180响应的确认消息(PRACK)。
12.被叫用户返回PRACK的响应消息。
13.被叫用户返回200 OK应答消息。
14.主叫用户返回应答消息的确认消息(ACK)。
在通话建立后，主被叫用户仍可根据用户需要重新发起媒体协商过程，可以增添、减少或者修改当前通话的媒体流。IMS域会话中的媒体重协商过程参见图4所示，包括下列步骤：
1.UE1发送会话更改请求，要求从语音通话变为多媒体通话，请求消息中包含要重新建立的语音，视频等媒体流信息(媒体流信息包括UE1支持的每种媒体流的编码方案以及为每种媒体流分配的带宽等信息)，因为会话更改请求是在当前会话里发送的消息，根据会话建立时***的路由信息，直接发送到UE2(图中省略期间，没有画出P_CSCF)。注：这里的UE1即可为主叫用户也可为被叫用户。
2.UE2返回183消息，指示UE2当前可接收多媒体呼叫，消息中包含每种媒体流所支持的编码方案(可有多种)和为每种媒体流分配的带宽，该消息返回给UE1。
3.UE1户返回183响应的确认消息(PRACK)，携带UE1最终选择的每种媒体流的编码方案(仅一种)，发送到UE2。
4.UE2返回PRACK的响应消息，携带的媒体信息与接收到的一致(媒体流协商完成)。
5.UE1完成主叫侧资源预留后，向被叫侧发送UPDATE消息，指示UE1资源预留完成。
6.UE2返回UPDATE的响应消息。
7.UE2完成资源预留后，返回180振铃消息。
8.UE1返回180响应的确认消息(PRACK)。
9.UE2返回PRACK的响应消息。
10.UE2返回200 OK会话更改请求完成消息。
11.UE1返回应答消息的确认消息(ACK)。
从以上两个IMS域流程可以看出，IMS域多媒体呼叫与传统电路域的语音呼叫相比，多了会话建立时的媒体协商过程以及会话中的媒体协商过程，而传 统电路域的语音呼叫仅支持语音这种媒体，并且其编码格式也是固定的(窄带语音编解码格式)，所以不需要这种媒体协商过程。
三、参见图5所示，在3GPP标准23.278里已定义了一种向IMS域用户提供传统电路域智能业务的架构。
该标准在IMS域引入了IM-SSF的功能实体，一方面IM-SSF作为一个AS，通过ISC接口接收S-CSCF发送的SIP消息，感知呼叫相关信令，另一方面IM-SSF作为一个SSF，它检测到用户在IMS域发生呼叫后需要触发到SCP去进行业务控制。IM-SSF通过Si接口下载智能签约数据，并根据该签约数据或者是网络配置情况，将呼叫触发到对应的SCP，进行智能业务处理。GSM网络中gsmSCP的功能实体与HSS/HLR之间具有MAP接口，通过该接口可以获取用户在电路域的位置信息(漫游信息)，智能业务签约情况和呼叫闭锁，前转等其他电路域补充业务信息。在3GPP标准23.278里IM-SSF与gsmSCP之间的交互可以使用CAP协议(用于GSM网络)，类似的IM-SSF与CDMA智能业务控制实体(winSCP)之间的交互可以使用ANSI41协议，参见图6所示。
现有技术里提到了IM-SSF具有触发到CDMA智能业务控制实体(winSCP)的能力，但是其接口协议(图6中的T1接口)仍使用传统电路域的ANSI41协议。传统电路域的T1接口协议仅持语音呼叫，使用该接口协议，winSCP是不能感知IMS域用户的多媒体会话的媒体协商的过程，所以winSCP不能获取用户的多媒体信息。以PPC业务为例，winSCP因为不能知道用户发起的是多媒体呼叫还是仅语音呼叫，所以对用户发起的这两种呼叫无法区分，只能以相同的标准对用户收费。另外如果用户在通话过程中增添或减少了媒体流信息，winSCP也无法感知，对于这种通话只能以初始通话时的标准进行收费。以上缺陷使得传统电路域的智能业务无法完善的提供给IMS域用户。
发明内容
本发明提供一种电路域感知IMS域多媒体会话媒体信息的方法及***，用 以解决现有技术中电路域智能业务控制实体无法感知IMS域多媒体会话媒体信息的问题。
进一步，解决现有技术中电路域智能业务控制实体无法根据IMS域的多媒体会话媒体信息调整费率或选择被叫用户的问题。
本发明方法在主被叫会话建立过程中，包括下列步骤：
A1、完成媒体协商后，服务会话控制功能实体S-CSCF将媒体协商结果信息告知业务交换功能实体IM-SSF；
B1、IM-SSF根据用户签约的触发器中记录的智能业务控制实体SCP地址，在向该SCP发送的消息中携带所述媒体协商结果信息。
其中，所述媒体协商结果信息至少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式。
综上所述，所述SCP根据当前收到的媒体协商结果信息调整费率，并对IMS域用户计费。
更进一步，所述步骤A1之前还包括步骤：
C11、S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息中携带初始多媒体会话媒体信息；
D11、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带所述初始多媒体会话媒体信息，以使该SCP确定初始费率。
更进一步，主叫侧或被叫侧在所述步骤A1之前发起增加媒体流的过程。
再进一步，所述步骤A1之前，若在所述SCP获知初始多媒体会话媒体信息后，又增加媒体类型，则包括步骤：
E11、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中至少携带所述增加的媒体类型以及媒体更改的方向。
再进一步，若IMS域用户作为被叫用户提供多媒体会话媒体信息，则所述步骤A1之前还包括步骤：
C12、S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息 中不携带多媒体会话媒体信息；D12、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中不携带多媒体会话媒体信息；E12、被叫侧选择多媒体会话媒体信息后，IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带被叫侧选择的多媒体会话媒体信息，以及媒体更改的方向。
所述步骤A1之前，若增加媒体类型，则所述步骤E12之后还包括步骤：
F12、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中至少携带增加的媒体类型以及媒体更改的方向。
又进一步，在会话过程中发生媒体重协商时，则还包括下列步骤：
A2、完成媒体重协商后，S-CSCF将媒体重协商结果信息告知IM-SSF；
B2、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带所述媒体重协商结果信息。
更进一步，所述步骤A2之前还包括步骤：
S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的会话更改请求消息中携带欲更改的多媒体会话媒体信息；IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带欲更改的多媒体会话媒体信息，以及会话更改的方向。
综上所述，在SCP发起会话状态查询时，则还包括下列步骤：
IM-SSF收到查询消息后，根据查询消息中携带的会话信息检查与之对应的会话状态，若该会话未被释放，则IM-SSF在向所述SCP上报的查询响应消息中携带当前会话所使用的多媒体会话媒体信息；否则，返回错误消息。
综上所述，还包括：所述SCP根据当前收到的所述初始多媒体会话媒体信息选择被叫用户，以完成会话建立。
进一步，在会话建立的入呼筛选过程中，包括下列步骤：
S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息中携带初始多媒体会话媒体信息；IM-SSF根据用户签约的触发器中记录的SCP地址， 在向该SCP发送的消息中携带所述初始多媒体会话媒体信息；SCP根据所述初始多媒体会话媒体信息判断媒体类型，并将与之对应的被叫用户信息返回，以完成会话建立。
综上所述，通过扩展IM-SSF与SCP之间的接口协议消息中的参数携带所述多媒体会话媒体信息；或者扩展IM-SSF与SCP之间的接口协议中的消息携带所述多媒体会话媒体信息。
进一步，所述接口协议为CDMA智能网所使用的ANSI41协议。
所述SCP为CDMA智能网络中的winSCP。
本发明的***，包括：归属签约服务器HSS、智能业务控制实体SCP和S-CSCF，所述***还包括：
与HSS、SCP和S-CSCF分别相连的业务交换功能实体IM-SSF，用于在主被叫会话建立过程中，完成媒体协商后，获取S-CSCF告知的媒体协商结果信息；
IM-SSF与SCP之间的接口，用于由IM-SSF根据用户签约的触发器中记录的SCP地址，向该SCP发送携带所述媒体协商结果信息的消息。
其中，所述SCP为CDMA智能网络中的winSCP。
其中，所述媒体协商结果信息至少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式。
本发明有益效果如下：
本发明方法在IM-SSF从收到的IMS域会话控制信令中获取多媒体会话媒体信息后，通过扩展IM-SSF与SCP(CDMA智能网络中的winSCP)之间的T1接口协议消息中的参数携带多媒体会话媒体信息，或者扩展T1接口协议中的消息携带多媒体会话媒体信息，将多媒体会话媒体信息上报给对应的SCP，从而使该SCP可以感知多媒体会话媒体信息。
进一步，在所述SCP感知IMS域多媒体会话媒体信息后，可根据当前的多媒体会话媒体信息调整费率，并对IMS域用户计费；或者选择被叫用户，以 完成会话建立。进而向IMS域用户提供完善的智能业务，达到重用原有电路域的winSCP的目的，减少网络运营商的投资。
附图说明
图1为传统电路域用户签约PPC业务并发起主叫的流程图；
图2为传统电路域用户签约PPC业务作为被叫的流程图；
图3为IMS域普通的呼叫建立流程图；
图4为IMS域会话中的媒体重协商流程图；
图5为现有的向IMS域用户提供传统电路域智能业务的***架构示意图；
图6为现有包含winSCP的向IMS域用户提供传统电路域智能业务的***架构示意图；
图7为本发明***结构示意图；
图8为本发明方法步骤流程图；
图9为本发明方法实例一流程图；
图10为本发明方法实例二流程图；
图11为本发明方法实例三流程图；
图12为本发明方法实例四流程图；
图13为本发明方法实例五流程图；
图14为本发明方法实例六流程图；
图15为本发明方法实例七流程图；
图16为本发明方法实例八流程图。
具体实施方式
为了使电路域智能业务控制实体无法感知IMS域多媒体会话媒体信息，本发明提供一种电路域感知IMS域多媒体会话媒体信息的***，参见图7所示，包括IM-SSF，以及通过Si/Sh接口与所述IM-SSF相连的HSS，通过ISC接口 与所述IM-SSF相连的S-CSCF，通过T1’接口与所述IM-SSF相连的SCP(在CDMA智能网络中为winSCP)。
所述S-CSCF(服务会话控制功能实体)，为IMS域用户进行会话控制和注册服务。当用户处于会话中时，S-CSCF维持会话状态，并且根据网络运营商对服务支持的需要，通过ISC接口与IM-SSF进行交互，由IM-SSF提供对应的业务。
所述HSS存放与用户和服务有关的数据，其中包括智能签约数据。所述智能签约数据可以通过Si接口(使用ANSI41协议)或者Sh接口(使用diameter协议)下载到IM-SSF，以使IM-SSF根据该数据与对应的SCP交互。
所述SCP(CDMA网络中的智能业务控制实体winSCP)，该实体根据IM-SSF上报的会话信息提供相应的智能业务。
所述IM-SSF，一方面作为服务平台(AS)，接收从S-CSCF发来的会话控制信令，并从收到的会话控制信令中获取多媒体会话媒体信息；另一方面作为业务交换功能实体，根据用户智能签约数据(通过Si/Sh接口从HSS下载)，通过扩展的T1接口(T1’)，即扩展的CDMA智能网所使用的ANSI41协议，向对应的SCP提供业务信息(该信息从会话控制信令中提取)，由该SCP提供对应的智能业务。而且IM-SSF还需要通过T1’接口上报IMS域多媒体会话媒体信息(包括：IMS域会话建立时的媒体协商信息，以及IMS域会话中的媒体协商信息；所述媒体协商信息进一步至少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式)，使SCP能够感知IMS域多媒体会话的特征，从而提供完善的智能业务。
应用上述***，本发明还提供了一种电路域感知IMS域多媒体会话媒体信息的方法，参见图8所示，包括下列主要步骤：
S1、IM-SSF收到IMS域会话控制信令。
在会话建立过程中或会话持续过程中，IM-SSF会收到S-CSCF发来的IMS域会话控制信令。
S2、IM-SSF从收到的IMS域会话控制信令中获取多媒体会话媒体信息。
所述多媒体会话媒体信息包括：IMS域会话建立时的媒体协商信息，以及IMS域会话中的媒体协商信息。进一步，所述媒体协商信息至少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式。
S3、IM-SSF将获取的多媒体会话媒体信息上报给智能业务控制实体SCP。
IM-SSF在每次获取新的多媒体会话媒体信息后都上报给对应的SCP；或者仅在媒体协商结束后，直接将最终的媒体协商结果信息上报给对应的SCP。所述IM-SSF逐次获取多媒体会话媒体信息的过程，包括但不限于：在建立会话过程中获取初始多媒体会话媒体信息(可为空)的过程；在建立会话之前增加媒体流，并获取相应的多媒体会话媒体信息的过程；在建立会话过程中，媒体协商结束后，获取相应的多媒体会话媒体信息的过程；在会话持续时，媒体重协商过程中，获取相应的多媒体会话媒体信息的过程；以及SCP发起会话状态查询时，获取当前多媒体会话信息的过程。
IM-SSF通过扩展后的IM-SSF与SCP(CDMA智能网络中为winSCP)之间的T1’接口协议消息中的参数携带所述多媒体会话媒体信息；或者IM-SSF通过扩展后的IM-SSF与SCP(CDMA智能网络中为winSCP)之间的T1’接口协议中的消息(即新增的消息)携带所述多媒体会话媒体信息，上报给对应的SCP。所述被扩展的协议为CDMA智能网所使用的ANSI41协议。
之后，所述SCP根据当前收到的多媒体会话媒体信息，调整费率，并对IMS域用户计费；或者选择被叫用户，以完成会话建立。从而向IMS域用户提供完善的智能业务。
以下通过8个实例具体描述本发明方法。
方法实例一、IMS域用户发起主叫，由SCP向其提供PPC(预付费)业务。参见图9所示，包括下列具体步骤：
1.UE1通过P_CSCF向主叫用户注册的S_CSCF发送始呼请求(图中省略起见，没有画出P_CSCF)，请求消息中包含呼叫要建立的语音，视频等媒 体流信息(媒体流信息包括主叫侧支持的每种媒体流的编码方案以及为每种媒体流分配的带宽等信息)，S_CSCF根据用户签约的iFC，将始呼请求转发到IM-SSF。
2.IM-SSF判断主叫用户签约了Origination_Attempt_Authorized触发器，根据该触发器记录的SCP地址，向SCP发送ORREQ(Original Request)消息，除携带原智能业务所需的会话信息外，还需携带medialist参数，该参数包含了始呼请求消息中要建立的媒体流信息，这些信息包括可包括媒体类型(如语音，视频等)，传输协议(如RTP等)，媒体格式(即媒体流的编码格式，如语音的AMR，EVRC编码等)，媒体流申请的带宽等任意一种或组合。
3.SCP检查主叫用户激活了PPC业务且用户具有足够的帐户余额支持这次多媒体呼叫，则向MSC/SSF返回orreq，指示呼叫继续。
4.IM-SSF判断主叫用户签约了Calling_Routing_Address_Available触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD，携带根据被叫用户标识得到的被叫路由信息。
5.SCP根据ANLYZD里的被叫路由信息和ORREQ里携带的媒体流信息，决定主叫用户通话的初始费率(此时还没有完成媒体协商，该费率后续可能发生变化)，向IM-SSF返回anlyzd，指示呼叫继续。
6.IM-SSF处理完智能业务交互后，向S_CSCF返回始呼请求消息，并把自身***到呼叫路径里。
7.S_CSCF将呼叫请求路由到被叫侧。
8.被叫侧向S_CSCF返回183消息，指示被叫用户当前仅能接收语音媒体成分，以及语音媒体成分所支持的编码方案(可有多种，是主叫侧提供的编码方案的子集)和为语音媒体流分配的带宽。
9.因为IM-SSF已***到呼叫路径里，S_CSCF将183消息转发给IM-SSF。
10.IM-SSF记录消息里的媒体流信息后，通过S_CSCF，P_CSCF将该消 息转发给主叫用户。
11.主叫用户返回183响应的确认消息(PRACK)，携带主叫用户最终选择的语音编码方案(仅一种)，根据接收到183响应消息里记录的路由路径，通过S_CSCF发送到IM-SSF，IM-SSF记录该媒体信息。
12.IM-SSF将PRACK消息返回给S_CSCF。
13.S_CSCF将PRACK消息发往被叫侧。
14.被叫用户返回PRACK的响应消息，携带的媒体信息与接收到的PRACK一致(媒体流协商完成)。
15.因为IM-SSF已***到呼叫路径里，S_CSCF将响应消息转发给IM-SSF。
16.IM-SSF记录消息里的媒体流信息，并将该信息作为会话建立协商后的媒体流信息，通过S_CSCF，P_CSCF将该消息转发给主叫用户。
17.主被叫用户完成资源预留过程(具体步骤参见背景技术2)，由于IM-SSF已经***到呼叫路径里，如果资源预留过程中导致了协商后的媒体流信息发生变化，IM-SSF也可以感知该信息(一般情况，资源预留会按照会话协商的媒体流信息完成)。
18.被叫用户返回会话应答消息。
19.因为IM-SSF已***到呼叫路径里，S_CSCF将会话应答消息转发给IM-SSF。
20.IM-SSF判断主叫用户签约了O_Answer触发器，根据该触发器记录的SCP地址，向SCP发送OANSWER消息，除携带原智能业务所需的会话信息外，还需携带medialist参数，该参数要包含会话最终建立时的媒体流信息(即经媒体协商和资源预留后，IM-SSF最终记录的媒体流信息)；SCP收到该消息后，根据最终会话建立时的媒体流信息，重新调整费率，并开始对主叫用户计费。
21.IM-SSF通过S_CSCF，P_CSCF将被叫用户应答消息转发给主叫用 户。
22～24.主叫用户返回应答确认消息(ACK)。
注1：初始请求的媒体流信息也可以在Calling_Routing_Address_Available触发的ANLYZD消息中携带。
注2：初始请求的媒体流信息也可以不上报给SCP，仅在OANSWER消息上报协商完成后的媒体信息。
注3：虽然举例为PPC业务，这种机制同样适用于其他智能业务。
方法实例二、IMS域用户作为被叫，由SCP向其提供PPC(预付费)业务。参见图10所示，包括下列具体步骤：
1.主叫侧将始呼请求消息路由到被叫用户归属网络的I_CSCF，I_CSCF向被叫用户注册的S_CSCF发送始呼请求(图中省略起见，没有画出I_CSCF)，请求消息中包含呼叫要建立的语音，视频等媒体流信息(媒体流信息包括主叫侧支持的每种媒体流的编码方案以及为每种媒体流分配的带宽等信息)，S_CSCF根据被叫用户签约的iFC，将始呼请求转发到IM-SSF。
2.IM-SSF判断被叫用户签约了Initial_Termination触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD(Analyzed Information)消息，除携带原智能业务所需的会话信息外，还需携带medialist参数，该参数包含了始呼请求消息中要建立的媒体流信息，这些信息包括媒体类型(如语音，视频等)，传输协议(如RTP等)，媒体格式(即媒体流的编码格式，如语音的AMR编码，EVRC编码等)，媒体流申请的带宽等。
3.SCP检查被叫用户激活了PPC业务且用户具有足够的帐户余额支持这次多媒体呼叫，则向IM-SSF返回anlyzd，指示呼叫继续。
4.IM-SSF判断被叫用户签约了Called_Routing_Address_Available触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD消息，携带被叫用户当前的漫游信息。
5.SCP根据ANLYZD里的被叫漫游信息和媒体流信息，决定被叫用户通 话的初始费率(此时还没有完成媒体协商，该费率后续可能发生变化)，向IM-SSF返回anlyzd，指示呼叫继续。
6.IM-SSF处理完智能业务交互后，向S_CSCF返回始呼请求消息，并把自身***到呼叫路径里。
7.S_CSCF根据被叫用户注册的地址，通过P_CSCF向被叫用户发送始呼请求消息。
8～17.后续的媒体协商和资源预留过程同主叫过程类似，因为IM-SSF已经***到呼叫路径里，所以IM-SSF可以感知会话的媒体协商过程，并记录相应的媒体流信息。
18.被叫用户返回会话应答消息。
19.因为IM-SSF已***到呼叫路径里，S_CSCF将会话应答消息转发给IM-SSF。
20.IM-SSF判断被叫用户签约了T_Answer触发器，根据该触发器记录的SCP地址，向SCP发送TANSWER消息，除携带原智能业务所需的会话信息外，还需携带medialist参数，该参数要包含会话最终建立时的媒体流信息(即经媒体协商和资源预留后，IM-SSF最终记录的媒体流信息)；SCP收到该消息后，根据最终会话建立时的媒体流信息，重新调整费率，并开始对被叫用户计费。
21.IM-SSF通过S_CSCF，向主叫侧发送被叫应答消息。
22～24.主叫用户返回应答确认消息(ACK)。
注1：初始请求的媒体流信息也可以在Called_Routing_Address_Available触发的ANLYZD消息中携带。
注2：初始请求的媒体流信息也可以不上报给SCP，仅在TANSWER消息上报协商完成后的媒体信息。
注3：虽然举例为PPC业务，这种机制同样适用于其他智能业务。
方法实例三、IMS域用户已经建立了语音通话。通话过程中，本端用户发 起了媒体重协商过程，建立视频通话。SCP需要根据协商后的媒体信息重新调整费率。参见图11所示，包括下列具体步骤：
1.主被叫双方已建立语音通话。
2.本端用户发起会话更改，希望增添视频媒体成分。注：本端用户即可为主叫用户也可为被叫用户。
3.因为IM-SSF已***到呼叫路径里，所以IM-SSF可接收到该会话更改请求消息，IM-SSF检测到O/TService_Change_Request触发器(对于主叫用户是O，被叫是T)，根据该触发器对应的地址向SCP发送O/TSCR消息，携带当前会话更改请求消息中的媒体流信息，当前的会话标识(BILLINGID)，用户标识(MSID)，以及会话更改的方向由本端发起(direct＝local)。注：O/TService_Change_Request触发器是新增的智能触发器(传统电路域里没有会话中媒体协商过程)，O/TSCR消息是新增的ANSI41协议消息；除媒体流信息和会话更改方向外，其他参数为现有ANSI41协议定义的参数。
4.SCP判断本端用户有足够的余额支持增添视频成分，则返回空scr(否则scr里可带拒绝原因)。
5.IM-SSF将会话更改请求消息转发给S_CSCF。
6.S_CSCF将会话更改请求消息发送到对端。
7.进行媒体协商和资源预留过程(参见背景技术2)，因为IM-SSF已经***到呼叫路径里，所以IM-SSF可以感知会话更改的媒体协商过程，并记录相应的媒体流信息。
8.对端返回会话更改完成消息。
9.S_CSCF将该消息发送给IM-SSF。
10.IM-SSF检测到(O/T)Service_Change_Complish触发器，根据该触发器对应的地址向SCP发送(O/T)SCC，携带会话更改结果(result＝Success)，以及协商后的媒体信息(如果协商失败，则要携带更改前的媒体信息)，当前的会话标识(BILLINGID)、用户标识(MSID)和协商完成时间(TOD，TDO)等信 息。注：(O/T)SCC，也是新增的ANSI41消息。
11.SCP收到该消息后重新调整费率，返回响应消息。
12.IM-SSF向本端用户返回更新完成。
注1：欲更改的多媒体会话媒体信息以及会话更改的方向也可以不上报给SCP，仅在(O/T)SCC消息上报重协商完成后的媒体信息。
方法实例四、IMS域用户已经建立了语音通话。通话过程中，对端用户发起了媒体重协商过程，建立视频通话，SCP需要根据协商后的媒体信息重新调整费率。参见图12所示，包括下列具体步骤：
1.主被叫双方已建立语音通话。
2.对端发起会话更改，希望增添视频媒体成分，会话更改请求消息发送到本端用户归属的S_CSCF。
3.S_CSCF将会话更改请求消息发送到IM-SSF。
4.IM-SSF接收到会话更改请求消息后，IM-SSF检测到(O/T)Service_Change_Request触发器(对于主叫用户是O，被叫是T)，根据该触发器对应的地址向SCP发送(O/T)SCR消息，携带当前会话更改请求消息中的媒体流信息，当前的会话标识(BILLINGID)，用户标识(MSID)，以及会话更改的方向由对端发起(direct＝reomote)。
5.SCP判断本端用户有足够的余额支持接收视频成分，则返回空scr(否则scr里可带拒绝原因)。
6.IM-SSF将会话更改请求消息发送给本端用户。
7.进行媒体协商和资源预留过程。
8.本端返回会话更改完成消息。
9.IM-SSF检测到(O/T)Service_Change_Complish触发器，根据该触发器对应的地址向SCP发送(O/T)SCC，携带会话更改结果(result＝Success)，以及协商后的媒体信息(如果协商失败，则要携带更改前的媒体信息)，当前的会话标识(BILLINGID)、用户标识(MSID)和协商完成时间(TOD，TDO) 等信息。
10.SCP收到该消息后，重新调整费率，返回响应消息。
11.IM-SSF向S_CSCF返回更新完成。
12.S_CSCF向对端用户返回更新完成。
注1：欲更改的多媒体会话媒体信息以及会话更改的方向也可以不上报给SCP，仅在(O/T)SCC消息上报重协商完成后的媒体信息。
方法实例五、IMS域主叫用户在初始会话请求中要求建立语音呼叫，在协商过程中要求增添媒体流，变为多媒体呼叫。参见图13所示，包括下列具体步骤：
1～10.同方法实例一。
11.主叫用户返回183响应的确认消息(PRACK)，除携带选择的语音编码方案外，还携带新增的视频媒体消息，即有语音呼叫变为多媒体呼叫。根据接收到183响应消息里记录的路由路径，通过S_CSCF发送到IM-SSF。
12.IM-SSF接收到PRACK消息后，IM-SSF检测到O_Service_Change_Request触发器，并且满足该触发器设定的条件(如设定条件为媒体流增加)，则根据该触发器对应的地址向SCP发送OSCR消息，携带PRACK消息中的媒体流信息，当前的会话标识(BILLINGID)，用户标识(MSID)，以及媒体更改的方向由本端发起(direct＝LOCAL)。
13.SCP判断本端用户有足够的余额支持发起多媒体会话，则返回空scr(否则scr里可带拒绝原因)。
14～26.后续过程同方法实例一。
注1：如果SCP不关注媒体变化过程，仅关注最终媒体协商结果，则11～13为可选步骤。
注2：对于被叫流程，与该流程类似，区别在于触发的是T_Service_Change_Request触发器，上报的TSCR消息里，携带的媒体更改方向为对端。
方法实例六、主叫用户在初始会话请求不携带媒体信息，由IMS域被叫用户提供媒体信息，主叫用户根据被叫用户提供的媒体信息进行协商(只有非IMS域用户呼叫IMS域用户才可出现这种情况，所以仅提供被叫过程)。参见图14所示，包括下列具体步骤：
1.主叫侧将始呼请求消息路由到被叫用户归属网络的I_CSCF，I_CSCF向被叫用户注册的S_CSCF发送始呼请求(图中省略起见，没有画出I_CSCF)，请求消息中不包含呼媒体信息，S_CSCF根据被叫用户签约的iFC，将始呼请求转发到IM-SSF。
2.IM-SSF判断被叫用户签约了Initial_Termination触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD(Analyzed_Information)消息，除携带原智能业务所需的会话信息外，可选的携带medialist参数，其内容为空。注：也可不携带medialist参数。
3.SCP检查被叫用户激活了PPC业务且用户具有足够的帐户余额，则向IM-SSF返回anlyzd，指示呼叫继续。
4.IM-SSF判断被叫用户签约了Called_Routing_Address_Available触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD消息，携带被叫用户当前的漫游信息。
5.SCP根据ANLYZD里的被叫漫游信息，决定被叫叫用户通话的初始费率(此时还没有媒体信息，该费率后续可能发生变化)，向IM-SSF返回anlyzd，指示呼叫继续。
6.IM-SSF处理完智能业务交互后，向S_CSCF返回始呼请求消息，并把自身***到呼叫路径里。
7.S_CSCF根据被叫用户注册的地址，通过P_CSCF向被叫用户发送始呼请求消息。
8.被叫用户向S_CSCF返回183消息，指示被叫用户当前选择的媒体信息，包含呼叫要建立的语音，视频等媒体流信息。
9.因为IM-SSF已***到呼叫路径里，S_CSCF将183消息转发给IM-SSF。
10.IM-SSF接收到183消息后，IM-SSF检测到T_Service_Change_Request触发器，并且满足该触发器设定的条件(如设定条件为媒体流增加)，则根据该触发器对应的地址向SCP发送TSCR消息，携带183消息中的媒体流信息，当前的会话标识(BILLINGID)，用户标识(MSID)，以及媒体更改的方向由本端发起(direct＝LOCAL)。
11.SCP判断本端用户有足够的余额接收多媒体会话，则返回空scr(否则scr里可带拒绝原因)。
12.IM-SSF通过S_CSCF将该消息转发给主叫用户。
13.主叫用户返回183响应的确认消息(PRACK)，携带主叫用户选择的媒体信息(音频)，根据接收到183响应消息里记录的路由路径，通过S_CSCF发送到IM-SSF，IM-SSF记录该媒体信息(因为该媒体信息是183消息包含的媒体信息的子集，所以不会触发T_Service_Change_Request触发器)。
14.IM-SSF将PRACK消息返回给S_CSCF。
15～26.后续过程同方法实例二。
注1：被叫侧选择的多媒体会话媒体信息也可以不上报给SCP，仅在TANSWER消息上报协商完成后的媒体信息。
注2：在本方法实例中，也可附加增添媒体流的流程。即IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带被叫侧选择的多媒体会话媒体信息，增加的媒体类型对应的多媒体会话媒体信息，以及媒体更改的方向。
方法实例七、SCP主动向IM-SSF查询当前会话的状态。参见图15所示，包括下列具体步骤：
1.主被叫双方已建立多媒体通话。
2.SCP的会话状态检测定时器超时后，需要检验用户状态，向IM-SSF 发送CCDIR消息，包含当前的会话标识(BILLINGID)、用户标识(MSID)、SCP标识(MSCID)等信息。注：SCP检验会话状态的目的在于解决SCP和IM-SSF两侧会话状态不一致的问题，如IM-SSF发送(O/T)ANSWER消息后，进入会话建立状态，但是SCP因为故障没有收到该消息还处于等待用户应答状态。
3.IM-SSF收到该消息后，IM-SSF根据BILLID和MSID检查对应的会话状态，如果呼叫没有释放，则返回ccdir，消息里携带medialist参数，指明当前进行会话的媒体信息；否则，返回错误消息。
以上七个方法实例都是以PPC智能业务为例，但该机制不仅限于PPC智能业务，其他智能业务也可应用本机制来对IMS域用户提供智能业务。
方法实例八、IMS域用户签约了ICS(入呼筛选)智能业务，可以根据入呼的媒体类型来选择不同的处理，若为语音呼叫则由本用户处理，若为多媒体呼叫则前转到另一个用户。参见图16所示，包括下列具体步骤：
1.主叫侧将始呼请求消息路由到被叫用户B归属网络的I_CSCF，I_CSCF向被叫用户注册的S_CSCF发送始呼请求(图中省略起见，没有画出I_CSCF)，请求消息中包含被叫用户B的标识(request_url携带)以及呼叫要建立的语音，视频等媒体流信息(媒体流信息包括主叫侧支持的每种媒体流的编码方案以及为每种媒体流分配的带宽等信息)，S_CSCF根据被叫用户签约的iFC，将始呼请求转发到IM-SSF。
2.IM-SSF收到始呼请求后，判断被叫用户签约了Advance_Termination触发器，根据该触发器记录的SCP地址，向SCP发送ANLYZD消息，除携带原ICS智能业务所需的会话信息外，还需携带medialist参数，该参数包含了始呼请求消息中要建立的媒体流信息。
3.SCP根据medialist参数判断该呼叫为多媒体呼叫，需要呼叫前转到用户C，则向IM-SSF返回anlyzd消息，包含termlist参数，包含前转用户C的信息。
4.IM-SSF收到该消息后，根据termlist参数，重新构造始呼请求消息，将被叫方信息改为用户C(修改request_url)，并将修改后的始呼请求消息返回S_CSCF。
5.S_CSCF将该始呼请求消息路由到用户C所归属的网络。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (19)
1.一种电路域感知IMS域多媒体会话媒体信息的方法，其特征在于，在主被叫会话建立过程中，包括下列步骤：
A1、完成媒体协商后，服务会话控制功能实体S-CSCF将媒体协商结果信息告知业务交换功能实体IM-SSF；
B1、IM-SSF根据用户签约的触发器中记录的智能业务控制实体SCP地址，在向该SCP发送的消息中携带所述媒体协商结果信息。
2.如权利要求1所述的方法，其特征在于，所述媒体协商结果信息至少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式。
3.如权利要求1或2所述的方法，其特征在于，所述SCP根据当前收到的媒体协商结果信息调整费率，并对IMS域用户计费。
4.如权利要求3所述的方法，其特征在于，所述步骤A1之前还包括步骤：
C11、S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息中携带初始多媒体会话媒体信息；
D11、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带所述初始多媒体会话媒体信息，以使该SCP确定初始费率。
5.如权利要求3所述的方法，其特征在于，主叫侧或被叫侧在所述步骤A1之前发起增加媒体流的过程。
6.如权利要求5所述的方法，其特征在于，所述步骤A1之前，若在所述SCP获知初始多媒体会话媒体信息后，又增加媒体类型，则包括步骤：
E11、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中至少携带所述增加的媒体类型以及媒体更改的方向。
7.如权利要求5所述的方法，其特征在于，若IMS域用户作为被叫用户提供多媒体会话媒体信息，则所述步骤A1之前还包括步骤：
C12、S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息中不携带多媒体会话媒体信息；
D12、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中不携带多媒体会话媒体信息；
E12、被叫侧选择多媒体会话媒体信息后，IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带被叫侧选择的多媒体会话媒体信息，以及媒体更改的方向。
8.如权利要求7所述的方法，其特征在于，所述步骤A1之前，若增加媒体类型，则所述步骤E12之后还包括步骤：
F12、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中至少携带增加的媒体类型以及媒体更改的方向。
9.如权利要求3所述的方法，其特征在于，在会话过程中发生媒体重协商时，则还包括下列步骤：
A2、完成媒体重协商后，S-CSCF将媒体重协商结果信息告知IM-SSF；
B2、IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带所述媒体重协商结果信息。
10.如权利要求9所述的方法，其特征在于，所述步骤A2之前还包括步骤：S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的会话更改请求消息中携带欲更改的多媒体会话媒体信息；
IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带欲更改的多媒体会话媒体信息，以及会话更改的方向。
11.如权利要求1或2所述的方法，其特征在于，在SCP发起会话状态查询时，则还包括下列步骤：
IM-SSF收到查询消息后，根据查询消息中携带的会话信息检查与之对应的会话状态，若该会话未被释放，则IM-SSF在向所述SCP上报的查询响应消息中携带当前会话所使用的多媒体会话媒体信息；否则，返回错误消息。
12.如权利要求4所述的方法，其特征在于，还包括：所述SCP根据当前收到的所述初始多媒体会话媒体信息选择被叫用户，以完成会话建立。
13.如权利要求12所述的方法，其特征在于，在会话建立的入呼筛选过程中，包括下列步骤：
S-CSCF根据初始过滤规则iFC，在向IM-SSF转发的始呼请求消息中携带初始多媒体会话媒体信息；
IM-SSF根据用户签约的触发器中记录的SCP地址，在向该SCP发送的消息中携带所述初始多媒体会话媒体信息；
SCP根据所述初始多媒体会话媒体信息判断媒体类型，并将与之对应的被叫用户信息返回，以完成会话建立。
14.如权利要求1所述的方法，其特征在于，通过扩展IM-SSF与SCP之间的接口协议消息中的参数携带所述多媒体会话媒体信息；或者扩展IM-SSF与SCP之间的接口协议中的消息携带所述多媒体会话媒体信息。
15.如权利要求14所述的方法，其特征在于，所述接口协议为CDMA智能网所使用的ANSI41协议。
16.如权利要求1所述的方法，其特征在于，所述SCP为CDMA智能网络中的无线智能网智能业务控制实体winSCP。
17.一种电路域感知IMS域多媒体会话媒体信息的***，包括：归属签约服务器HSS、智能业务控制实体SCP和S-CSCF，其特征在于，所述***还包括：
与HSS、SCP和S-CSCF分别相连的业务交换功能实体IM-SSF，用于在主被叫会话建立过程中，完成媒体协商后，获取S-CSCF告知的媒体协商结果信息；
IM-SSF与SCP之间的接口，用于由IM-SSF根据用户签约的触发器中记录的SCP地址，向该SCP发送携带所述媒体协商结果信息的消息。
18.如权利要求17所述的***，其特征在于，所述SCP为CDMA智能网络中的无线智能网智能业务控制实体winSCP。
19.如权利要求17所述的***，其特征在于，所述媒体协商结果信息至 少包括下列之一：媒体类型、媒体所需带宽、媒体传输协议和媒体编解码格式。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200610152690 CN101155173B (zh) | 2006-09-25 | 2006-09-25 | 电路域感知ims域多媒体会话媒体信息的方法及*** |
| PCT/CN2007/002765 WO2008040171A1 (fr) | 2006-09-25 | 2007-09-19 | Procédé, système de domaine de commutation de circuits apercevant des informations de sessions multimédia du domaine ims |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200610152690 CN101155173B (zh) | 2006-09-25 | 2006-09-25 | 电路域感知ims域多媒体会话媒体信息的方法及*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101155173A CN101155173A (zh) | 2008-04-02 |
| CN101155173B true CN101155173B (zh) | 2011-11-09 |
Family
ID=39256610
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200610152690 Expired - Fee Related CN101155173B (zh) | 2006-09-25 | 2006-09-25 | 电路域感知ims域多媒体会话媒体信息的方法及*** |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101155173B (zh) |
| WO (1) | WO2008040171A1 (zh) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917697B (zh) * | 2010-08-04 | 2013-04-17 | 中国电信股份有限公司 | 用户业务使用状态的感知方法和*** |
| CN102025731B (zh) * | 2010-12-03 | 2013-04-24 | 华为技术有限公司 | 智能业务触发方法及相关设备和*** |
| CN102655613A (zh) * | 2011-03-02 | 2012-09-05 | 中兴通讯股份有限公司 | 业务触发方法及装置 |
| CN102316425B (zh) * | 2011-09-23 | 2017-12-19 | 中兴通讯股份有限公司 | 一种用于ims与智能网的信令交互方法及im‑ssf |
| CN109121102A (zh) * | 2017-06-22 | 2019-01-01 | 中兴通讯股份有限公司 | 一种漫游计费方法和*** |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005032164A1 (en) * | 2003-09-27 | 2005-04-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Intelligent multimedia calls |
| CN1642137A (zh) * | 2004-01-05 | 2005-07-20 | 华为技术有限公司 | 实现通用分组无线业务智能网的方法及*** |
| CN1665314A (zh) * | 2005-04-21 | 2005-09-07 | 北京邮电大学 | 用于移动智能网的多业务优先触发的方法 |
| WO2006047958A1 (fr) * | 2004-11-08 | 2006-05-11 | Huawei Technologies Co., Ltd. | Procede et systeme de fourniture de services intelligents pour utilisateurs |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1217816A1 (en) * | 2000-12-22 | 2002-06-26 | Lucent Technologies Inc. | Supporting legacy voice centric services in an IP multimedia network |
| CN100471284C (zh) * | 2006-03-29 | 2009-03-18 | 北京邮电大学 | 一种对移动智能网的呼叫信令流程进行优化的方法 |
-
2006
- 2006-09-25 CN CN 200610152690 patent/CN101155173B/zh not_active Expired - Fee Related
-
2007
- 2007-09-19 WO PCT/CN2007/002765 patent/WO2008040171A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005032164A1 (en) * | 2003-09-27 | 2005-04-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Intelligent multimedia calls |
| CN1642137A (zh) * | 2004-01-05 | 2005-07-20 | 华为技术有限公司 | 实现通用分组无线业务智能网的方法及*** |
| WO2006047958A1 (fr) * | 2004-11-08 | 2006-05-11 | Huawei Technologies Co., Ltd. | Procede et systeme de fourniture de services intelligents pour utilisateurs |
| CN1665314A (zh) * | 2005-04-21 | 2005-09-07 | 北京邮电大学 | 用于移动智能网的多业务优先触发的方法 |
Non-Patent Citations (6)
| Title |
|---|
| 3GPP.Technical Specification GroupCore NetworkandTerminals |
| 3GPP.Technical Specification GroupCore NetworkandTerminals Customised ApplicationsforMobilenetworkEnhanced Logic (CAMEL) Phase4 Stage2;IMCNInterworking.http://www.3gpp.org/ftp/Specs/archive/23_series/23.278/.2006,10-15,134-136. * |
| Customised ApplicationsforMobilenetworkEnhanced Logic (CAMEL) Phase4 |
| IMCNInterworking.http://www.3gpp.org/ftp/Specs/archive/23_series/23.278/.2006,10-15,134-136. |
| Stage2 |
| 移动交换平台的智能化发展.人民邮电 无线时空栏目.2001,1-2. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101155173A (zh) | 2008-04-02 |
| WO2008040171A1 (fr) | 2008-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1534972B (zh) | 优化网络资源根据最终用户请求的用于会议接续的快速网络sip/sdp过程 | |
| CN1972254B (zh) | 终端之间语音和多媒体的互动服务的装置和方法 | |
| US6954654B2 (en) | Provision of services in a communication system including an interworking mobile switching center | |
| US6996087B2 (en) | Communication system including an interworking mobile switching center for call termination | |
| US7031747B2 (en) | Internet protocol multimedia subsystem component providing of packet-switched switching functions to serving mobile switching center feature server | |
| US6871070B2 (en) | Communication system for providing roaming between an internet protocol multimedia system and a circuit-switched domain | |
| CN101322373B (zh) | 为电路交换控制用户终端处理呼叫的方法和接入网关节点 | |
| US8908569B2 (en) | Multiple-termination routing in a wireless network environment with an internet protocol core | |
| EP2052522B1 (en) | Interworking with media fallback | |
| EP1487221B1 (en) | Server component redirection of new media path portion between packet-switched and circuit-switched portions of mobile switching center | |
| CN101330748B (zh) | 一种ip多媒体子***集中业务会话控制路径的切换方法 | |
| CN103501518A (zh) | 在异构无线通信***中的切换装置和方法 | |
| CN101374256A (zh) | 一种处理会话中媒体流连续性的方法、装置及*** | |
| US20100110992A1 (en) | Call processing method and intelligent network service control device for implementing one number multiple terminals service | |
| CN101155340B (zh) | 一种电路域感知ims域会话计费信息的方法及*** | |
| CN101155173B (zh) | 电路域感知ims域多媒体会话媒体信息的方法及*** | |
| CN100544371C (zh) | 在综合业务中实现能力协商的方法 | |
| EP2149244B1 (en) | A method of and a system for establishing a call over an ip multi media communications system and a circuit switched communications system | |
| CN101202956B (zh) | Ip多媒体子***会话回落到电路交换呼叫的实现方法 | |
| CN101111003B (zh) | 多媒体彩铃***及其播放方法 | |
| CN101267577A (zh) | 实现呼叫接续以及智能业务的方法、***和设备 | |
| CN100450210C (zh) | 一种r4网络***及提供媒体资源的方法 | |
| CN102833715B (zh) | 询问转接实现方法、应用服务器、业务终端和*** | |
| CN102158496B (zh) | 针对ims注册用户的呼叫处理 | |
| KR20080018749A (ko) | 음성 및 멀티미디어 서비스를 지원하는 통신 네트워크의메시지를 처리 방법 및 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20111109 Termination date: 20120925 |