用于管理ip多媒体子系统中的应用服务器响应的系统和方法

专利名称：：用于管理ip多媒体子系统中的应用服务器响应的系统和方法
技术领域：
：本发明涉及网际协议多媒体子系统(IMS)，并且更特别地涉及IMS网络上的增强型响应处理。
背景技术：
：由3GPP定义的IP多媒体子系统(IMS)通过为电信行业提供基于全IP的架构来融合电话和因特网技术。IMS基于会话发起协议(SIP)并且大量使用在因特网工程任务组(IETF)内所定义的协议。系统提供服务器和数据库的网络，所述服务器和数据库辅助用户代理进行建立和管理会话的任务。IMS使用术语“会话”，因为用户之间的连接不再限于语音服务(即电话呼叫)。会话可以是语音、视频、文本或者将两个或者更多用户代理连接在一起的其它服务。如图1所示，典型的IMS架构10包括用户设备(UE)11、在12处总体示出的若干呼叫会话控制功能(CSCF)、归属订户服务器(HSS)13以及一个或多个应用服务器14。UE11是包含会话发起协议(SIP)用户代理(UA)并且能够发起或者终止会话的设备。用户设备例如可以是无线电话、计算机、个人数字助理、启用web(网络)的电话或者任何合适的通信设备。CSCF12负责管理会话，包括安全性和互连。存在三种类型的CSCF。代理(P)CSCF15位于网络的边缘并且是UE11进入IMS核心的入口点。询问⑴CSCF16用作进入对等网络的网络的入口点并且还起到用于为订户寻找适当的服务节点的查找功能。服务(S)CSCF17负责鉴别UE11并且为UE11管理进行中的会话，包括调用应用程序。举例来说，所示出的S-CSCF17的特征在于，处理器22与存储器23—起工作。其它CSCF将具有等同特征，这些特征为清楚起见而被省略。HSS13在至少一个数据库19中存储包括鉴别信息和服务数据的相关用户数据。作为用户简档的一部分，初始过滤准则(iFC)被定义以指示基于信令平面中的信息来调用哪些应用服务器。S-CSCF17通过Cx接口21与HSS13通信以便获取(retrieve)UE鉴别信息。在用户已经被鉴别之后，S-CSCF17再次与HSS13通信，这次是为了获取用户简档。用户简档指定用户已预订的服务以及针对那些服务调用哪些应用服务器。基于存储在用户简档中的iFC来调用应用服务器14。如果在iFC中定义的准则得到满足，则S-CSCF将通过IMS服务控制(ISC)接口20将信令传递到应用服务器14。一旦被调用，应用服务器14现在就能够参与会话并且提供附加能力。这可以包括熟知的特征，如呼叫转发，或者新定义的服务，如无线一键通(Push-to-TalkoverCellular,PoC)。有可能调用多个应用服务器作为相同会话的一部分。为了获得对IMS网络10的接入，需要UE11向网络登记以对用户进行鉴别，从而建立安全关联。在UE11已经登记之后，它然后能够发起会话。虽然这样的登记过程是现有技术的典型特征，但是该登记过程对于本发明来说不是必不可少的。应该与登记过程无关地考虑本发明，并且本发明可以将3GPP规范所定义的对登记过程的任何改变(如可能周期性地发生)考虑进来。3GPPTS29.228(版本7.6.0)所定义的当前模式(schema)被部分复制如下<table>tableseeoriginaldocumentpage5</column></row><table>作为用户简档的一部分，iFC定义与应用服务器有关的信息。在应用服务器定义内，(name="tApplicationServer")是缺省处理。如在3GPPTS29.228(版本7.6.0)中所定义的那样，缺省处理只适用于来自应用服务器的5xx响应或者响应408(请求超时)。其他错误代码没有被处理。另外，现有技术只允许为所有这些错误响应定义缺省处理，而不针对每个错误响应提供不同处理。
发明内容本发明的目的是提供处理附加响应代码并且允许基于每个响应确定处理的灵活性的系统、方法和计算机可读介质。在某些实施例中，在S-CSCF处通过与应用服务器的交互，为扩大范围的响应代码给出特定处理。本发明还通过允许就每个响应代码而言行为改变而不是使用单一的“缺省处理”，在处理这些响应代码时考虑到更大程度的细化(greatergranularity)。所述处理作为存储在HSS上的用户简档中的初始过滤准则(iFC)的一部分被定义。在一个实施例中，提供了一种网际协议多媒体子系统(IMS)，其包括至少一个归属订户服务器；其中所述至少一个归属订户服务器存储至少一个用户简档，所述用户简档定义至少一个错误代码；以及与所述至少一个错误代码相关联的至少一个错误处理。在一个实施例中，提供了一种管理网际协议多媒体子系统中的应用服务器响应的方法，所述方法包括从归属订户服务器接收用户简档；向应用服务器发送请求；接收对所述请求的响应，所述响应标识响应代码；将所接收的响应代码与在所述用户简档中定义的一个或多个响应代码进行比较；确定同与所述所接收的响应代码相匹配的所定义的响应代码相关联的响应处理指令；以及执行所述响应处理指令。在一个实施例中，在包括至少一个呼叫会话控制功能(CSCF)和至少一个应用服务器的网际协议多媒体子系统(IMS)中，提供一种计算机可读介质，所述计算机可读介质包括能够在至少一个呼叫会话控制功能(CSCF)中执行的指令，用于接收对针对所述至少一个应用服务器的请求的响应；处理所述响应以确定响应代码；确定所述响应代码是否对应于错误代码；确定错误代码是否是定义的错误代码；确定与所述错误代码相关联的响应处理指令；以及执行所述响应处理指令。现在，将参考优选实施例和附图仅以举例方式来描述本发明，其中图1表示IMS网络的示意图；图2和3表示图1的网络上的UE登记的流程图；图4和5表示UE的会话发起的流程图；图6表示响应处理的流程图；图7和8表示具有扩展处理范围的响应处理的呼叫流过程；图9表示用于提供增强型响应处理的电子设备。具体实施例方式图2示出根据现有技术的UE向网络的登记，并且包括基于用户简档中的iFC对应用服务器的成功调用。图3示出对应的流程图100。在步骤101，UE11向P-CSCF15发送REGISTER(登记)请求以发起登记过程。在步骤102，P-CSCF15将REGISTER请求转发给I-CSCF16。I-CSCF16用用户授权请求(UAR)查询HSS13以确定将服务该UE11的S-CSCF17(步骤103)。HSS13用用户授权应答(UAA)来响应I-CSCF16，该UAA包括确定将服务该UE11的S-CSCF17所需的信息(步骤104)。I-CSCF16将REGISTER请求转发给适当的S-CSCF17(步骤105)。S-CSCF(17)用多媒体授权请求(MAR)查询HSS13以获取用于该UE11的鉴别信息(步骤106)。HSS13用包括用于该UE11的鉴别信息的多媒体授权应答(MAA)来响应(步骤107)。S-CSCF17将401响应发送回I-CSCF16以拒绝REGISTER请求但是包括鉴别向量，以使得UE11能够进行鉴别(步骤108)。在步骤109，I-CSCF将401响应转发给P-CSCF15，P-CSCF15将401响应转发给UE11(步骤110)。UE11使用在401中所接收到的鉴别信息以通过向P-CSCF15发送REGISTER请求来继续该登记过程(步骤111)。在步骤112，P-CSCF15将REGISTER请求转发给I-CSCF16，I-CSCF16用UAR查询HSS13以确定将服务该UE11的S-CSCF17(步骤113)。HSS13用UAA来响应I-CSCF16，其中UAA具有确定将服务该UE11的S-CSCF17所需的信息(步骤114)。I-CSCF16将REGISTER请求转发给适当的S-CSCF17(步骤115)。S-CSCF17验证来自UE11的鉴别信息并且使用服务器分配请求(SAR)通知HSS13:它将服务该UE11(步骤116)。在步骤117，HSS13用服务分配应答(SAA)来确认该分配并且提供用户简档。S-CSCF17经由I-CSCF16将2000K响应发送回UE(步骤118)。I-CSCF16将该2000K响应转发给P-CSCF15(步骤119)。P-CSCF15将该2000K响应转发给UE11(步骤120)。基于从用户简档获取的用于该用户的初始过滤准则(iFC)，S-CSCF17向应用服务器14发起第三方登记请求(步骤121)。应用服务器14将2000K响应发送回S-CSCF17(步骤122)。在UE11已经登记之后，UE11然后能够发起会话。参考图4和图5的流程图200来描述会话发起。UE-A11向P-CSCF15发送寻址到(addressedto)UE-B的INVITE(邀请)请求(步骤201)。作为响应，P-CSCF15将100Trying(尝试)发送回UE-A11，指示INVITE请求正被处理(步骤202)。P-CSCF15将INVITE请求继续发送给S-CSCF17(步骤203)。S-CSCF17将lOOTrying发送回P-CSCF15，指示INVITE请求正被处理(步骤204)。基于用于UE-A的iFC，S-CSCF17向应用服务器14发送INVITE请求(步骤205)。应用服务器14将lOOTrying发送回S-CSCF17，指示INVITE请求正被处理(步骤206)。应用服务器14将INVITE请求发送回S-CSCF17(如果它担当背靠背用户代理(B2BUA)，则有可能对该消息进行改变)(步骤207)。S-CSCF17将lOOTrying发送回应用服务器14，指示INVITE请求正被处理(步骤208)。S-CSCF17将INVITE请求继续发送以便终止处理(步骤209)(为清楚起见，省略了本领域中公知的终止处理的细节)。终止侧18将lOOTrying发送回S-CSCF17，指示INVITE请求正被处理(步骤210)。在步骤211，终止侧18向S-CSCF17发送2000K，该S-CSCF17将2000K发送给应用服务器(步骤212)。应用服务器14将2000K发送回S-CSCF17(步骤213)。S-CSCF17向P-CSCF15发送2000K(步骤214)，该P-CSCF15向UE-A11发送2000K(步骤215)。上述消息序列表示利用2000K响应的成功会话建立。在响应不是2000K的情况下，S-CSCF必须决定如何继续进行该会话。根据上述模式中的“tApplicationServer”类型的“DefaultHandling”元素，对处理做出决定所需的信息被作为所定义的iFC的一部分包括在用户简档中。在本发明的实施例中，对HSS和S-CSCF做出改变以促进对来自应用服务器的作为iFC的一部分被触发的响应的增强型处理。HSS增强为了支持对来自应用服务器的响应的更细化处理，对用于用户简档的XML模式进行更新以允许存储和传输额外的信息。然后，该信息通过Cx接口(在3GPP中所定义的S-CSCF与HSS之间的接口)被传递给S-CSCF。从上述模式中能够看出，在“tApplicationServer”类型中存在“Extention(扩展)”元素。通过使用该扩展，能够引入允许定义附加响应处理的附加元素。在一个实施例中，对所述模式进行修改以定义要向其分配响应处理的响应代码的范围。在可替换的实施例中，使用正则表达式(regex)来确定要向其分配处理的响应代码。对于本领域技术人员来说显而易见的是，本发明范围内的其它选择也是可用的并且以下提供的特定示例应被认为是说明性的而非限制性的。代码范围解决方案利用该解决方案，响应代码的范围与用于该范围的处理一起被定义。能够存在包含范围定义的(一个或多个)元素的多个实例，这是考虑到以不同方式对不同响应代码进行细化控制。根据本发明的实施例，用于通过Cx接口从HSS转移的用户简档的XML模式被修改。在此，对XML模式的受影响部分进行再现并将在下面详细描述<xs:complexTypename="tApplicationServer"><xs:sequence><xs:elementname="ServerName"type="tSIP_URL"/><xs:elementname="DefaultHandling"type="tDefaultHaridling"minOccurs='O"/><table>tableseeoriginaldocumentpage9</column></row><table>tApplicationServerExtension使用该新类型来替代"tExtension，，。定义该新类型考虑到以向后兼容现有技术模式的方式来对该模式进行增强。<xs:complexTypename="tApplicationServerExtension，，>开始对新的“tApplicationServerExtension”类型的定义。该类型是包含两个元素的序列。通过使用序列，可以允许该类型在以后也可扩展ExtendedHandlingRangeΜ7ΜΜ“tExtendedHandlingRange，，gM的(iii^if类型)。该元素是包含范围和处理信息的复合类型。Extension添加该元素以允许该类型在以后可扩展。(这符合在XML模式中所使用的现有惯例)。<xs:complexTypename="tExtendedHandlingRange，，>这开始对新的“tExtendedHandlingRange”类型的定义。该类型是用于定义响应代码范围和适当处理的序列。在这里定义该序列的重要元素ResponseStart类型为“tResponseCode”的该元素定义待定义的响应代码范围的开始。ResponseEnd类型为“tResponseCode”的该元素定义待定义的响应代码范围的结束。该元素是可选的。如果该元素不存在，则该实例将针对处理只定义单个代码。ExtendedHandling该元素定义要对落入所定义范围内的任何响应代码所应用的处理。该元素重新使用现有技术中现有的“tDefaultHandling”类型，以使得SESSI0N_CONTINUED和SESSI0N_TERMINATED选项也可用于基于范围的响应代码处理。Extension为了使该新类型可以为以后需要而扩展，“Extension”元素被包括进来。该元素利用现有的“tExtension”类型并且遵循在该模式中其它地方所使用的惯例。<xs:simpleTypename="tResponseCode，，>这开始对新的"tResponseCode，，类型的定义。该类型被定义为基于“int”的simpleType(简单类型)并且将值限制在300和999之间(包括300和999在内)。该类型被用于定义要在该范围中使用的响应代码。“ResponseEnd”必须大于或者等于“ResponseStart”元素。如果它们彼此相等，则将只为该范围定义单个响应代码。IsjApplicationServer^)ExtendedHandlingRangeWM^h^MWillll^jtW重叠。如果在两个实例中处理不同，则这会在如何处理响应代码方面引起模糊。能够以类似于如何处理iFC优先级的方式，使用范围的优先级来克服这种限制。ιΗ则表达式解决方案对于这种解决方案，正则表达式串被用来定义匹配的响应代码。能够存在定义该正则表达式的(一个或多个)元素的多个实例，这是考虑到以不同方式对不同响应代码进行细化控制。如前面所提到的那样，用于用户简档的XML模式在由HSS通过Cx接口使用时被更新。用于用户简档的XML模式的受影响部分如下，在下面描述其细节<table>tableseeoriginaldocumentpage11</column></row><table><table>tableseeoriginaldocumentpage11</column></row><table>tApplicationServerExtension使用该新类型来替代在现有技术模式中所使用的“tExtension”。定义该新类型考虑到以向后兼容现有技术模式的方式来对该模式进行增强。<xs:complexTypename=“tApplicationServerExtension，，>这幵始对“tApplicationServerExtension”类型的定义。该类型是包含两个元素的序列。通过使用序列，可以允许该类型在以后也可扩展。该序列的元素如下ExtendedHandlingRegex"tExtendedHandlingRegex"(胃ifeif类型)的。该元素是包含正则表达式和处理信息的复合类型。Extension添加该元素以允许"tApplicationServerExtension”类型在以后可扩展，这符合在XML模式中所使用的现有惯例。<xs:complexTypename="tExtendedHandlingRegex，，>这开始对新的“tExtendedHandlingRegex”类型的定义。该类型是用于定义针对响应代码匹配和适当处理所使用的正则表达式的序列。在这里定义该序列的重要元素ResponseRegex该元素是“tString”类型的并且定义用于响应代码的匹配的正则表达式。这种匹配方式与在iFC的其它方面中使用的匹配方式(如“RequestURI”)类似。ExtendedHandling该元素定义要对落入所定义范围内的任何响应代码所应用的处理。该元素重新使用现有技术模式中现有的“tDefaultHandling”类型，以使得SESSI0N_CONTINUED和SESSION_TERMINATED选项也可用于基于范围的响应代码处理。Extension为了使该新类型可以为以后需要而扩展，“Extension”元素被包括进来。该元素利用现有的“tExtension”类型并且遵循在模式中的其它地方所使用的惯例。对于正则表达式解决方案来说，两个“ResponseRegex”表达式不应引起相同响应代码的匹配。如果在两个实例中处理不同，则这会在如何处理响应代码方面引起模糊。可以以类似于如何处理iFC优先级的方式，使用表达式的优先级来克服这种限制。S-CSCF增强在逻辑层面上，无论选择哪个解决方案来修改在Cx接口上所使用的用于用户简档的XML模式，对由S-CSCF17所需的处理器22执行的处理指令的改变都是相同的。S-CSCF17的处理器22在登记过程期间通过Cx接口21从HSS13接收用户简档，例如在上面讨论的图2和3中的步骤117中所示出的那样。根据经修改的模式，S-CSCF针对特定响应代码做出决定所需的附加信息被包括进来。图6示出S-CSCF17的处理器22使用的用于处理来自应用服务器14的响应代码的决策树600。在处理器22已经基于用户简档中的iFC向应用服务器14转发了请求之后，该处理过程在处理器22中开始。用户简档可以被从HSS13接收到并且暂时存储在存储器23中。处理器22将在如上参照图2和3所讨论的登记流的步骤121之后或者在如上参照图4和5所讨论的会话发起过程的步骤205之后启动这些处理指令。在步骤601，S_CSCF17的处理器22，在已经向应用服务器14发送了请求后，等待来自应用服务器的响应。处理器22接收响应并且处理响应代码(步骤602)。如果响应代码是小于200的任何整数，则处理器22返回到等待来自应用服务器14的响应。如果响应代码在200和299之间(步骤606)，则处理器认为已经接收到成功的响应并因此继续进行成功响应处理(604)并然后停止(步骤605)。大于299的响应代码通常指示某种形式的错误。示例性错误607“不能到达应用服务器”被示出。这样的错误代码可具有在用户简档中定义的响应代码和相关联的响应处理。在步骤608，S-CSCF17的处理器22例如通过从存储器23获取用户简档并将所接收到的响应代码与在用户简档中所提供的错误代码进行比较来确定响应代码是否是定义的错误代码。如果使用“代码范围”方法，则S-CSCF17的处理器22将确定响应代码是否落入所定义的错误代码范围之一内。如果使用“正则表达式”方法，则S-CSCF17的处理器22将确定响应代码是否与所定义的正则表达式之一相匹配。如果在使用这些方法中的任一种的情况下存在匹配，则S-CSCF将对该错误代码执行如在从存储器23获取的用户简档的"ExtendedHandling"元素中所指定的处理(步骤610)。如果不存在匹配，则S-CSCF17的处理器22将执行如在用户简档的"DefaultHandling"元素中所指定的缺省处理(步骤609)。在响应处理之后，该过程完成(步骤611)。图9示出能够执行参考图6所描述的方法的电子设备。设备90包括可通信地与存储器92耦合的处理器91。在与存储器一起工作的情况下，处理器91能够执行指令以接收对针对应用服务器的请求的响应901，处理该响应以确定响应代码902，确定该响应代码是否对应于错误代码903，确定该错误代码是否是定义的错误代码904，确定与错误代码相关联的响应处理指令905；以及执行所述响应处理指令906。电子设备90还能够包括任意数量的附加组件，诸如图形卡、收发器、电源等等。另夕卜，设备90可通过有线或无线方式进行通信。已经在3GPP中使用XML定义了用户简档以考虑到可扩展性，该可扩展性允许向后兼容性。在此所描述的实施例利用该可扩展性并且保留向后兼容性。在S-CSCF17支持在此所描述的增强型响应处理而HSS不支持的情况下，存储在HSS上的用户简档将不包含由“tApplicationServerExtension”类型所定义的“Extension”。因此，S-CSCF执行增强型响应代码处理所需的附加信息将不存在。然而，“DefaultHandling”元素将仍然存在于用户简档中并且S-CSCF17能够对此起作用。具有已经支持本发明的S-CSCF将在HSS确实获得支持时使稍后包括特征变得更容易。在HSS13支持扩展的用户简档而S-CSCF17尚未具有支持的情况下，存储在HSS13上的用户简档将包含由“tApplicationServerExtension”类型所定义的“Extension”。当在登记过程期间转移用户简档时，该信息将被通过Cx接口传递给S-CSCF17。由于S-CSCF没有识别出该信息并且因为该信息在原始模式中被定义为扩展，所以S-CSCF将仅仅忽略该额外信息。在这种情况下，S-CSCF将仅仅使用仍然存在于用户简档中的“DefaultHandling”元素。一旦S-CSCF17被升级以使用该附加信息，该信息将在HSS13上的用户简档中已经处于可用状态。上述实施例提供用于扩展用户简档的两个示例。虽然其它实施例也是有可能的，但是最期望的实施例将取决于要使用的实施方式的类型。例如，正则表达式常常被认为实施起来很昂贵。然而，由于使用正则表达式的模式中的其它元素的缘故，在平台上已经存在对于正则表达式的支持。对范围进行定义将允许进行简单的整数比较。然而，该解决方案可能需要对数目大得多的组合进行定义(并因而存储和转移)以针对所有相关响应代码确定处理。现在将参考图7、图8的流程图800并且参考下面的用户简档XML文档来描述本发明实施例的特定可行示例。该示例基于上述代码范围解决方案。用户简档的相关部分如下<？xmlversion="1.0〃encoding="UTF-8"？><IMSSubscriptionxmlns:xsi=‘‘http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="CxDataType_range.xsd"><PrivateID>IMPIlihomedomain.com</PrivateID><ServiceProfile><PublicIdentity><BarringIndication>l</BarringIndication><Identity>sip:IMPUlihomedomain.com</Identity></PublicIdentity><InitialFilterCriteria><Priority>0</Priority><TriggerPoint><ConditionTypeCNF>l</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method></SPT></TriggerPoint><ApplicationServer><ServerName>sip:ASlihomedomain.com</ServerName><DefaultHandling>l</DefaultHandling><Extension><ExtendedHandlingRange><ResponseStart>486</ResponseStart><ExtendedHandling>0</ExtendedHandling></ExtendedHandlingRange><Extension></ApplicationServer></InitialFilterCriteria><InitialFiIterCriteria><Priority>l</Priority><TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method>,</SPT></TriggerPoint><ApplicationServer><ServerName>sip:AS2ihomedomain.com</ServerName><DefaultHandling>l</DefaultHandling></ApplicationServer></InitialFilterCriteria></ServiceProfile></IMSSubscription>在该示例中，通过SIPIMPIlihomedomain.com来识别用户。<ApplicationServer>类型定义用于应用服务器ASl@homedomain.com的错误处理。在该类型定义中，缺省处理被如下定义<DefaultHandling>l</DefaultHandling>。该定义对应于SESSI0N_TERMINATED。换句话说，如果错误基于该触发而发生，则缺省处理将终止会话。然而，简档还定义了如下的扩展处理范围<ExtendedHandlingRange><ResponseStart>486</ResponseStart><ExtendedHandling>0</ExtendedHandling></ExtendedHandlingRange>也就是说，该示例添加了对486BusyHere(现在正忙)SIP错误代码的特定处理。该处理被设置成SESSI0N_C0NTINUED(<ExtendedHandling>0</ExtendedHandling>)，这意味着如果接收到486错误代码，则应该对剩余的过滤准则继续进行过滤匹配，就好像没有错误发生过一样。现在参考图7和8，将描述基于示例用户简档的呼叫流，其中用户标识UE-A对应于上面的XML文档中的标识IMPIl和IMPU1，应用服务器A对应于ASlOhomedomain.com并且应用服务器B对应于AS2@h0med0main.com。在该呼叫流中，在第一应用服务器处发生故障，这触发了由增强型用户简档所提供的附加规则。在步骤801，用户UE-A11向P-CSCF15发送寻址到UE-B的INVITE请求。P-CSCF将100Trying发送回UE-A11，指示INVITE请求正被处理(步骤802)。P-CSCF15将INVITE请求继续发送给S-CSCF17(步骤803)，S-CSCF17用100Trying响应返回P-CSCF15(步骤804)，指示INVITE请求正被处理。基于用于UE-A的iFC，S-CSCF17向应用服务器A14a发送INVITE请求(步骤805)。应用服务器A14a将486BusyHere响应发送回S-CSCF17，指示其由于忙碌状态而不能处理该请求(步骤806)。在接收到该错误消息时，S-CSCF17的处理器评估本发明所提供的附加校验(步骤807)。根据用于该应用服务器的<ExtendedHandlingRange>定义，486响应应该使用SESSI0N_C0NTINUED。因此，S-CSCF17将继续iFC评估。基于该评估，S-CSCF将INVITE请求转发给应用服务器B14b(步骤808)。应用服务器B将100Trying发送回S-CSCF17，指示INVITE请求正被处理(809)。应用服务器B14b将INVITE请求发送回S-CSCF17(如果它担当背靠背用户代理(B2BUA)，则有可能对该消息进行改变)(步骤810)。S-CSCF17将100Trying发送回应用服务器B，指示INVITE请求正被处理(步骤811)。在步骤812，S-CSCF17将INVITE请求继续发送以终止处理(为简单起见，省略了终止处理的细节)。终止侧将100Trying发送回S-CSCF17，指示INVITE请求正被处理(步骤813)。在步骤814，终止侧向S-CSCF17发送2000K，S-CSCF17然后向应用服务器B14b发送200OK(步骤815)。应用服务器B14b将200OK发送回S-CSCF17(步骤816)，S-CSCF17将200OK转发给P-CSCF15(步骤817)并进而转发给UE-A11(步骤818)。前面的示例提供了根据本发明实施例的用例。在呼叫流的步骤807中，S-CSCF使用<ExtendedHandlingRange>添加来为486BusyHere响应提供特定处理。在没有该增强的情况下，S-CSCF会作为替代地使用〈DefaultHandling〉过程并且会不得不终止该会话。在此所描述的实施例与现有技术系统相比所具有的优点在于，实施IMS系统的运营商在其如何处理来自应用服务器的响应方面获得了附加的灵活性。该附加的灵活性允许它们以不同方式对待不同的响应代码，并因而允许它们根据响应特性从终端用户角度更好地处理响应。尽管在附图中示出并且在前面的说明中描述了本发明的实施例，但是应该理解本发明并不限于所公开的实施例，而是能够在不脱离由下面的权利要求书所陈述和定义的本发明的精神的情况下进行许多调整、修改和替换。例如，本发明的能力能够完全地和/或部分地由一个或多个块、模块、处理器或存储器来执行。而且，这些能力可以以当前的方式或以分布式方式并且在能够提供和/或接收信息的任何设备上或借助该设备来执行。进一步地，尽管以特定方式描述，但是各种模块或块可以被重新定位而不脱离本发明的范围。再进一步地，尽管以特定方式描述，但是对于本发明而言可以利用更多或更少数量的模块和连接以便实现本发明、为本发明提供附加的已知特征和/或使本发明更加高效。而且，在各个模块之间所发送的信息能够经由数据网络、因特网、网际协议网络、无线源和有线源中的至少一种并且经由多个协议在模块之间被发送。权利要求一种网际协议多媒体子系统(IMS)，包括至少一个归属订户服务器；其中所述至少一个归属订户服务器存储至少一个用户简档，所述用户简档定义至少一个错误代码；和与所述至少一个错误代码相关联的至少一个错误处理。2.根据权利要求1所述的网际协议多媒体子系统，其中所述用户简档进一步定义缺省错误处理。3.根据权利要求1所述的网际协议多媒体子系统，其中所述用户简档定义错误代码的一个或多个范围以及与所述一个或多个范围中的每一个相关联的错误处理。4.根据权利要求1所述的网际协议多媒体子系统，其中所述用户简档定义一个或多个正则表达式，每个正则表达式定义错误处理以及与所述错误处理相关联的至少一个错误代码。5.根据权利要求1所述的网际协议多媒体子系统，其中在用户简档模式的扩展的tApplicationServer类型中定义所述至少一个错误代码和所述至少一个错误处理。6.根据权利要求1所述的网际协议多媒体子系统，进一步包括至少一个应用服务器和至少一个呼叫会话控制功能，其中所述至少一个呼叫会话控制功能从所述归属订户服务器获取所述用户简档；其中所述至少一个呼叫会话控制功能接收对针对所述至少一个应用服务器的请求的响应；其中所述呼叫会话控制功能处理所述响应以确定响应代码；其中所述呼叫会话控制功能确定所述响应代码是否是错误代码；其中如果所述错误代码与在所述用户简档中定义的错误代码相匹配，则呼叫会话控制功能执行与所述匹配的错误代码相关联的错误处理。7.根据权利要求6所述的网际协议多媒体子系统，其中如果所述错误代码与在所述用户简档中定义的错误代码不匹配，则呼叫会话控制功能执行缺省错误处理。8.—种管理网际协议多媒体子系统中的应用服务器响应的方法，所述方法包括从归属订户服务器接收用户简档；向应用服务器发送请求；接收对所述请求的响应，所述响应标识响应代码；将所接收的响应代码与在所述用户简档中定义的一个或多个响应代码进行比较；确定同与所述所接收的响应代码相匹配的所定义的响应代码相关联的响应处理指令；以及执行所述响应处理指令。9.根据权利要求8所述的方法，进一步包括接收来自用户的应用请求，从应用请求确定用户的标识，以及根据用户的标识接收用户简档。10.根据权利要求8所述的方法，进一步包括如果所述所接收的响应代码与在所述用户简档中定义的响应代码不匹配，则确定缺省处理指令。11.根据权利要求8所述的方法，进一步包括定义至少一个响应代码，定义至少一个响应处理，以及将所述至少一个响应处理与所述至少一个响应代码相关联。12.根据权利要求11所述的方法，进一步包括定义至少一个多个响应代码并且将所述多个响应代码与所述至少一个响应处理相关联。13.根据权利要求12所述的方法，其中所述至少一个多个响应代码是响应代码的范围。14.根据权利要求12所述的方法，其中所述定义包括至少一个正则表达式，每个正则表达式定义响应处理以及与所述响应处理相关联的至少一个响应代码。15.根据权利要求11所述的方法，进一步包括在至少一个用户简档中存储至少一个响应代码和至少一个相关联的响应处理。16.根据权利要求15所述的方法，进一步其中在用户简档模式的扩展的tApplicationServer类型中存储至少一个响应代码和相关联的响应处理。17.在包括至少一个呼叫会话控制功能(CSCF)和至少一个应用服务器的网际协议多媒体子系统(IMS)中，一种计算机可读介质包括能够在至少一个呼叫会话控制功能(CSCF)中执行的指令，用于接收对针对所述至少一个应用服务器的请求的响应；处理所述响应以确定响应代码；确定所述响应代码是否对应于错误代码；确定错误代码是否是定义的错误代码；确定与所述错误代码相关联的响应处理指令；以及执行所述响应处理指令。18.根据权利要求17所述的计算机可读介质，进一步包括用于从存储器获取用户简档并且处理所述用户简档以确定所述响应代码是否是定义的错误代码的指令。19.根据权利要求18所述的计算机可读介质，进一步包括用于处理所述用户简档以确定用于所述错误代码的响应处理指令的指令。20.根据权利要求18所述的计算机可读介质，进一步包括用于确定所述响应代码未被定义、从所述用户简档获取缺省响应处理以及执行所述缺省响应处理的指令。全文摘要在网际协议多媒体子系统(IMS)中，一种用户简档被配备有提供一个或多个错误代码定义和相关联的错误处理指令的扩展模式。所接收到的响应于对应用服务器的请求的响应代码被处理以确定在用户简档中是否定义了匹配的响应代码。如果发现匹配，则执行相关联的响应处理指令。如果没有发现匹配，则执行缺省响应处理。文档编号H04L29/12GK101803345SQ200880107999公开日2010年8月11日申请日期2008年7月16日优先权日2007年7月20日发明者S·K·施尼耶,T·普雷斯利申请人:爱立信电话股份有限公司