用于跨应用元件传送应用标识符的方法和设备的制作方法

文档序号:7850499阅读:243来源:国知局
专利名称:用于跨应用元件传送应用标识符的方法和设备的制作方法
技术领域
本公开总体上涉及通信网络,并且更具体地涉及在整个网络中在不同域之间传送与业务流有关的信息。
背景技术
当网络仅支持一个语音应用和一个视频应用时,呼叫供应(calloffer)的接收方相对易于识别用于处理呼叫的适当应用,并且由此,识别请求的适当服务质量相对容易。结果,可以有效地处理呼叫,并且通常使呼叫的发起方和呼叫的接收方满意。当网络支持多种类型的类似应用时,变得难以识别与业务流相关联的应用类型,并且因此,难以识别对于处理业务流的请求的适当服务质量。另外,当网络支持多个管理域以及跨管理域的边界的 业务流时,通常变得甚至更加难以识别与业务流相关联的服务质量和应用类型。


结合附图,通过下面的详细描述将容易地理解本公开,在附图中图1是根据实施例的包括多个域的网络的图示,在该多个域内,例如应用元件的系统被布置成发送和/或接收指定与实时传输协议(RTP)流相关联的业务类型的分组。图2A是根据实施例的包括指定服务类别的属性行的会话描述协议(SDP)净荷的图示,SDP净荷例如在作为供应或应答的会话发起协议(SIP)或RTSP消息内的净荷。图2B是根据实施例的包括指定服务类别的属性行并且包括标签的SDP净荷的图示,SDP净荷例如在作为供应或应答的SIP或RTSP消息内的净荷。图3是根据实施例的识别与之相关联的特定业务类别的SDP净荷的图示。图4是根据实施例的适用于生成和/或处理标识应用类别或服务类别的SDP净荷的设备或应用元件的框图表示。图5是图示根据实施例的生成指定服务类别的SDP净荷的方法的过程流程图。图6是图示根据实施例的处理指定服务类别的SDP净荷的方法的过程流程图。
具体实施方式
综述根据一个方面,一种方法包括生成会话描述协议(SDP)构造,该SDP构造被布置成被包括在第一信令流中。该方法还包括在SDP构造中提供属性。该属性标识与第一媒体流相关联的应用类型。最后,在第一信令业务流上转发SDP构造。描述因为不同的业务流,例如与实时传输协议(RTP)相关联的不同的业务流,通常与不同的服务质量相关联,因此,除非可以容易地识别服务质量需求,否则可能损害根据业务流的服务质量来处理业务流的能力。例如,如果在执行许可控制时没有请求适当的服务质量,或者如果在将差分服务代码点(DSCP)指派给接收到的流时没有识别适当的服务质量,则可能损害与流相关联的整体服务质量。此外,如本领域技术人员应当理解的,除非在不同的管理域中使用服务质量的标准定义,否则还可能损害提供适当的服务质量的能力。在一个实施例中,当例如呼叫的信令流通过管理域时,如果该信令流包括与业务流相关联的应用类别或服务类别的指示符,例如不同管理域理解的指示符,则业务流的接收方可以确定应用类别。一旦接收方确定了应用类别或类型,接收方就可以通过例如与整个网络进行协商来确保基本上与应用类别一致地处理业务流。例如,在接收到与呼叫供应相关联的信令流之后,接收方可以使相关联的业务流放进入适当队列以供处理。在与会话发起协议(SIP)相关联的会话描述协议(SDP)净荷或更一般地SDP构造的背景下,可以通过在SDP净荷中包括属性行来标识应用或服务类别。属性行可以被添加到SDP净荷,并且用于至少在包括例如由不同服务提供商所支持的管理域的不同管理域的网络内以基本上被理解的方式标识应用或服务类别。可以在属性行中标识应用或服务类另O,例如作为服务类别或“servclass”。在一个实施例中,可以存在大约十二种类型的应用或服务类别,如在因特网工程任务组(IETF)发布的标题为“Configuration Guidelinesfor Diffserv ServiceClasses”的RFC 4594中所固定的,其全部内容通过引用并入本文。应当理解的是,可以使用任何数目的类型的应用或服务类别,并且这样类型的应用或服务类别不限于在RFC 4594中所规定的。例如,可以在其他RFC中定义其他类型的应用或服务类别。定义服务类别,即“voice-admit(语音-许可)”服务类别的另一个RFC的一个示例是标题为“A Differentiated Services Code Point (DSCP) for Capacity-AdmittedTraffic,,的 RFC 5865。首先参考图1,根据实施例,将描述包括多个域的网络,在该多个域内,系统被布置成发送和/或接收指定与RTP流相关联的业务类型的分组。通常可以是任何适当的通信网络的网络100,诸如支持电话和统一通信的通信网络,包括域144a、144b。域144a、144b可以是管理域,并且每一个都可以包括任何数目的系统160a、160b。系统160a、160b可以包括但不限于,路由器、计算系统和/或应用元件。

系统“A” 160a被布置成向域“B” 144b转发、发送或以其他方式提供消息104。系统“B” 160b被布置成从系统“A” 160a或更一般地,域“A” 144a,接收或以其他方式获得消息104。消息104被有效地包括在待从域“A” 144a发送到域“B” 144b的流108中,例如在包括在流108中的SIP信令流中。域“A” 144a和域“B” 144b可以包括被配置成发送并且接收SIP信令流的终端设备、服务器和/或中间设备。消息104被配置成指定或以其他方式标识包含在流108内所包括的RTP业务流内的业务类型。例如,消息104被布置成标识与RTP业务流相关联的应用类型和/或服务类别。应当理解的是,为了使域“B” 144b理解在消息104中的业务类型的说明,在网络100内或至少在域“A” 144a和域“B” 144b之间通常全局地理解标识业务类型的指示符。如前所述,在一个实施例中,可以使用在RFC 4594中规定的定义来标识业务类型。通常,在从一个域传递到另一个域的消息中所指定的应用类型和/或服务类别可以表示网络元件基本上需要的每跳行为。虽然所述实施例通常推荐使用RFC 4594来使得全局独特的应用类型能够被使用,但是应当理解的是,在其他实施例中,可以在管理域内本地定义特有应用类型以基本上供本地使用。如前所述,业务流通常具有相关联的应用或服务类别。通常,可以从任何数目的应用或服务类别中选择与业务流相关联的应用或服务类另IJ。例如,在一个实施例中,大约十二个或更多的应用或服务类别可以与业务流相关联。对于存在大约十二个应用或服务类别的实施例,十二个应用或服务类别可以是网络控制服务类别、电话服务类别、信令服务类别、多媒体会议服务类别、实时交互服务类别、多媒体流送服务类别、广播视频服务类别、低时延数据服务类别、操作监管和管理(OAM)服务类别、高吞吐量数据服务类别、标准服务类别以及低优先级数据服务类别。这些应用或服务类别中的每一个的特征在于但不限于业务特性,诸如分组大小和传输率、对损失的容许度、对延迟的容许度以及对抖动的容许度。 在一个实施例中,可以在SDP净荷中指定应用类型或服务类别。SDP净荷可以作为例如SIP或实时流送协议(RTSP)信令流的信令流的一部分被包括进来。图2A是根据实施例的包括指定服务类别的属性行的SDP净荷的图示。SDP净荷220通常可以包括可以被存储的信息,诸如会话描述、时间描述以及媒体描述。该信息可以被存储在SDP净荷220内的基本上任何地方,例如,在SDP净荷220的主体中。可以在SDP净荷220内,例如在SDP消息220的主体内,指定属性行224。属性行224可以被指定为应用类型或服务类别。如所示,由“servclass”标号或标记来有效地表示应用类型或服务类别的说明。Servclass标记指示属性行224是业务流或流送的应用类型或服务类别。可以与servclass标记一起指定诸如参数的其他信息。即,除应用类型或服务类别外可以指定标签。图2B示出了具有与servclass标记一起指定的其他信息的SDP净荷220的示例。属性行224’可以包括标识应用类型或服务类别232的servclass。如所示,应用类型232是电话服务类别,但是应当理解的是,应用类型232不限于电话服务类别。属性行224’还可以包括标识可选或强制组件伪协商的标签228、以及标识生成了 SDP净荷220的元件期望相应的业务流如何被处理的预期的定向标签234。例如,定向标签234可以指示业务是仅被发送、仅被接 收还是被发送和接收二者。图3是根据实施例的标识与业务流相关联的特定业务类别的信令流的图示。网络344a包括多个管理域344a、344b。通常,管理域344a、344b可以与不同的服务提供商相关联。在所述实施例中,管理域344a、344b中的每一个包括布置成支持关于SDP净荷或更一般地关于SIP或RTSP信令对服务类别属性的使用的元件(未示出),例如设备。在管理域“A” 344a中的元件(未示出)跨管理域“A” 344a的边界将例如信令流的流348发送到管理域“B”344b。作为流348的一部分,标识服务类别或应用类型的信息353被包括进来。在一个实施例中,信息352可以是作为在例如图2A或图2B的SDP净荷220的SDP净荷中的servclass属性而提供的服务类别标识符。在接收到信息352之后,管理域“B”344b,或更具体地在管理域“B”344b内的元件(未示出),可以标识与相应业务流相关联的应用类型或服务类别,并且因此,根据所标识的应用类型或服务类别来对业务流进行处理。管理域344a、344b包括能够生成诸如上面参考图2A和2B描述的那些的SDP净荷的元件。接下来参考图4,将根据实施例来描述适用于生成和/或处理标识应用类别或服务类别的SDP净荷,例如包括SDP净荷的供应或应答。元件或系统460通常可以是计算系统,并且包括处理布置462、存储器布置464、网络接口布置466以及SDP逻辑468。处理布置462可以包括任何数目的处理器,并且可以被配置成执行与系统460相关联的逻辑,例如SDP逻辑468。在一个实施例中,处理布置462可以是中央处理单元(CPU)。存储器布置464可以包括静态存储器、动态存储器和/或被具体化为计算机可读介质的存储器。网络接口布置466被布置成使得系统460能够与网络内的其他系统进行通信。可以在网络接口布置466上接收和传送业务流。通常,网络接口布置466可以包括至少一个输入/输出端口,并且可以被配置成使用无线和/或有线通信来进行通信。通常可以与SIP逻辑(未示出)相关联的SDP逻辑468包括允许具有SDP净荷消息的供应消息被创建的供应消息生成逻辑470以及使得具有SDP净荷的应答消息能够被创建的应答消息生成逻辑472。供应消息生成逻辑470和应答消息生成逻辑472通常被布置成创建包括servclass属性的消息、或者更一般地包括应用类别或服务类别的指示的消息。SDP逻辑468还包括SDP处理逻辑474,该SDP处理逻辑474包括但不限于包括与处理SDP净荷、在许可控制期间建立适当服务类别以及为接收到的流指派适当DSCP相关联的逻辑。服务类别类型标识逻辑476被布置成标识应用类型或服务类别以与SDP净荷相关联,例如与要发送的SDP净荷相关联或与已经获取的SDP净荷相关联。策略应用逻辑478被布置成应用与具体应用类型或服务类别相关联的策略,例如本地策略,使得例如RTP业务流的业务流可以在适当时进行处理。策略应用逻辑478所应用的策略可以指定系统460如何有效地处理不同应用类型或服务类别的业务流。参考图5,将根据实施例来描述说明生成指定服务类别的SDP净荷的方法的过程流程图。通常,与域相关联的系统、设备或应用元件可以生成SDP净荷。生成SDP净荷的过程501在步骤505开始,其中标识适当服务类别或应用类别。这样的标识可以包括确定与RTP业务流相关联的应用类型、以及标识布置成标识该应用类型的标签。在标识了适当服务类别之后,在步骤509中创建SDP净荷。SDP净荷被创建有标识例如与RTP业务流相关联的服务类别的适当服务类别的servclass属性。一旦SDP净荷被创建有与适当服务类别一致地指定的servclass属性,就在步骤513中传送SDP净荷。SDP净荷通常可以作为诸如S IP消息或RTSP消息的消息的一部分被传送到在网络内的基本上任何系统、设备或应用元件。这样的系统、设备或应用元件可以在与传送包括SDP净荷的消息的应用元件相同的域中或在与传送包括SDP净荷的消息的应用元件不同的域中。在传送了 SDP净荷之后,完成生成SDP净荷的过程。图6是图示根据实施例的处理指定与业务流相关联的服务类别的SDP净荷的方法的过程流程图,SDP净荷例如系统或应用元件作为消息的一部分所接收到的SDP净荷。当系统、设备或应用元件获取SDP净荷605时,处理SDP净荷的方法601开始。当通过系统的网络接口布置接收例如信令消息的消息时,可以获取SDP净荷。一旦获取了 SDP净荷,就在步骤609开始对SDP净荷的处理。对SDP净荷的处理通常可以以解析SDP净荷和/或标识SDP净荷的内容开始。在步骤613中作出关于SDP净荷是否包含servclass属性或以其他方式标识与业务流相关联的应用类型或服务类别的确定。这样的确定可以包括但不限于包括,确定SDP消息的主体是否包括“a=SerVclaSS()”行或条目。如果在步骤613中的确定是SDP净荷不包含servclass属性,则指示是,待在步骤621中基于默认服务质量对例如相应RTP流的相应业务流进行处理,并且完成处理SDP净荷的方法。在一个实施例中,SDP净荷有效地指示,可以使用系统或应用元件通常用于处理业务流的任何方法来对与SDP净荷相关联的业务流进行处理。替选地,如果在步骤613中确定了 SDP净荷包含servclass属性或没有以其他方式标识应用类型或服务类别,则指示是可以使用servclass属性来请求适当服务质量以在执行许可控制时和/或当为相关联的流指派DSCP时使用。这样,过程流程从步骤613移动到步骤617,在步骤617中,基于servclass属性所标识的服务类别来处理与SDP净荷相对应的业务流,并且完成处理SDP消息的方法。尽管在本公开中仅描述了一些实施例,然而应当理解的是,在不背离本公开的精神或范围的情况下,可以以许多其他特定形式实现本公开。例如,虽然网络中的每个域可以被布置成将应用类型或服务类别映射成与域相关联的特定DSCP,但是DSCP替代地可以与应用类型或服务类别全局相关联。即,作为本地域基本上决定哪个DSCP值可以适于在RTP流中所包含或标识的应用,可以在网络内替代地定义DSCP。应当理解的是,通常可以将任何数目的应用类型或服务类别标识为在SDP净荷中的servclass属性。尽管已经描述了大约十二个应用类型或服务类别,但是可以将少于或多于十二个应用类型或服务类别标识为servclass属性。另外,在不背离本公开的精神或范围的情况下,与servclass属性相 关联的标签可以宽泛变化。对servclass属性的使用通常被描述为与SDP净荷并且由此与SIP信令和/或RTSP信令相关联。应当理解的是,对servclass属性的使用不限于与SDP净荷相关联。在呼叫期限期间的基本上任何时间,可以改变应用类型或服务类别。即,在呼叫属性中的呼叫中改变可能发生。例如,双方可以最初参加语音呼叫,并且然后将视频分量随后添加到该呼叫。在这样的情况下,可以将与该呼叫相关联的服务类别从指示语音呼叫改变为指示视频分量的存在。当这样的改变发生时,在一个实施例中,可以经由在SIP消息中承载的SDP净荷来交换新的属性。更一般地,可以在呼叫持续时间期间的基本上任何时间经由SDP净荷来交换属性。这样的交换通常可以由呼叫的任何一方发起。虽然对应用类型和服务类别的使用通常被描述为适用于实现服务质量处理,然而应当理解的是,可以结合其他类型的处理来使用应用类型和服务类别。例如,在不背离本公开的精神或范围的情况下,对应用类型和服务类别的使用可以实现任何恰当策略处理和/或许可控制。实施例可以被实现为硬件和/或在有形介质中实现的软件逻辑,当执行时可操作为执行上述各种方法和过程的软件逻辑。即,逻辑可以被实现化为物理布置、模块或组件。有形介质可以是能够存储可以例如由计算系统执行来执行与实施例相关联的方法和功能的逻辑的基本上任何适当的物理、计算机可读介质。这样的计算机可读介质可以包括但不限于包括,物理存储和/或存储器设备。可执行逻辑可以包括编码设备、计算机程序代码和/或可执行计算机命令或指令。应当理解的是,计算机可读介质或机器可读介质可以包括临时性实施例和/或非临时性实施例,例如信号或在载波中实现的信号。即,计算机可读介质可以与非临时性有形介质和临时性传播信号相关联。与本公开的方法相关联的步骤可以宽泛变化。在不背离本公开的精神或范围的情况下,可以对步骤进行添加、移除、更改、组合以及重新排序。因此,本示例应当被认为是说明性而非限制性的,并且该示例不限于在本文中给出的细节,而是在所附权利要求的范围内,可以 进行修改。
权利要求
1.一种方法,包括 生成会话描述协议(SDP)构造,所述SDP构造被布置成被包括在第一信令流中;在所述SDP构造中提供属性,所述属性被布置成标识与第一业务流相关联的应用类型;以及 在所述第一信令流上转发所述SDP构造。
2.根据权利要求1所述的方法,其中,所述第一信令流与会话发起协议(SIP)消息相关联,并且所述第一业务流是实时传输协议(RTP)业务流。
3.根据权利要求1所述的方法,其中,在所述第一信令流上转发所述SDP构造包括将所述SDP构造从第一管理域中的第一元件转发到第二管理域中的第二元件。
4.根据权利要求3所述的方法,其中,所述应用类型被布置成向所述第二管理域指示如何处理所述第一业务流。
5.根据权利要求3所述的方法,其中,所述SDP构造是供应消息,所述方法进一步包括 从所述第二元件获取应答消息,所述SDP应答消息被布置成标识与第二业务流相关联的应用类型。
6.根据权利要求1所述的方法,其中,所述SDP构造与从包括供应消息和应答消息的组中选择的一个相关联。
7.根据权利要求1所述的方法,所述应用类型提供与所述第一业务流相关联的服务质量的指示。
8.根据权利要求1所述的方法,其中,所述应用类型提供从包括与所述第一业务流相关联的策略和与所述第一业务流相关联的许可控制的组中选择的一个的指示。
9.根据权利要求1所述的方法,其中,生成所述SDP构造包括使用包括在第一管理域中的元件来生成所述SDP构造。
10.根据权利要求1所述的方法,其中,在所述第一信令流上转发所述SDP构造之后 确定与所述第一业务流相关联的所述应用类型已经改变; 生成更新的SDP构造,所述SDP构造被布置成被包括在第二信令流中; 在所述更新的SDP构造中提供更新的属性,所述更新的属性被布置成标识所述改变的应用类型;以及 在所述第二信令流上转发所述更新的SDP构造。
11.一种设备,包括 用于生成会话描述协议(SDP)构造的装置,所述SDP构造被布置成被包括在信令流中;用于在所述SDP构造中提供属性的装置,所述属性被布置成标识与业务流相关联的应用类型;以及 用于在所述信令流上转发所述SDP构造的装置。
12.一种包括计算机程序代码的计算机可读介质,所述计算机程序代码在被执行时,被配置成 生成会话描述协议(SDP)构造,所述SDP构造被布置成被包括在第一信令流中;在所述SDP构造中提供属性,所述属性被布置成标识与第一业务流相关联的应用类型;以及在所述第一信令流上转发所述SDP构造。
13.根据权利要求12所述的计算机可读介质,其中,所述第一信令流与会话发起协议(SIP)消息相关联,并且所述第一业务流是实时传输协议(RTP)业务流。
14.根据权利要求12所述的计算机可读介质,其中,配置成在所述第一信令业务流上转发所述SDP构造的所述计算机程序代码进一步被配置成将所述SDP构造从第一管理域中的第一元件转发到第二管理域中的第二元件。
15.根据权利要求14所述的计算机可读介质,其中,所述应用类型被布置成向所述第二管理域指示如何处理所述第一业务流。
16.根据权利要求14所述的计算机可读介质,其中,所述SDP构造是供应消息,所述计算机程序代码进一步被配置成 从所述第二元件获取应答消息,所述应答消息被布置成标识与第二业务流相关联的应用类型。
17.根据权利要求12所述的计算机可读介质,其中,所述SDP构造与从包括供应消息和应答消息的组中选择的一个相关联。
18.根据权利要求12所述的计算机可读介质,所述应用类型提供与所述第一业务流相关联的服务质量的指示。
19.根据权利要求12所述的计算机可读介质,其中,配置成生成所述SDP构造的所述计算机程序代码进一步被配置成使用包括在第一管理域中的元件来生成所述SDP构造。
20.—种设备,包括 处理布置; 网络接口布置;以及 会话描述协议(SDP)逻辑,所述SDP逻辑被布置成与所述处理布置协作,所述SDP逻辑被配置成生成包括属性的第一 SDP构造,所述属性被布置成指示与第一业务流相关联的服务类别,所述第一 SDP构造被布置成通过所述网络接口布置与第一信令流一起被提供到网络。
21.根据权利要求20所述的设备,其中,所述网络接口布置被配置成获取与第二信令流相关联的第二 SDP构造,并且其中,所述SDP逻辑被布置成对所述第二 SDP构造进行处理以确定与第二业务流相关联的服务类别。
22.根据权利要求21所述的设备,其中,所述SDP逻辑进一步被布置成将策略应用到所述第二业务流,所述策略使用与所述第二业务流相关联的所述服务类别来确定。
23.根据权利要求20所述的设备,其中,所述第一SDP构造是供应消息。
24.根据权利要求20所述的设备,其中,所述第一业务流是实时传输协议(RTP)业务流。
25.根据权利要求20所述的设备,其中,当与所述第一业务流相关联的所述服务类别改变时,所述SDP逻辑被配置成生成包括与所述第一业务流相关联的更新的服务类别的第二 SDP构造,所述第二 SDP构造被布置成通过所述网络接口布置与第二信令流一起被提供到网络。
全文摘要
在一个实施例中,一种方法包括生成会话描述协议(SDP)构造,该SDP构造被布置成被包括在第一信令流中。该方法还包括在该SDP构造中提供属性。该属性标识与第一业务流相关联的应用类型。最后,在第一信令业务流上转发该SDP构造。
文档编号H04L29/06GK103039054SQ201180032378
公开日2013年4月10日 申请日期2011年6月1日 优先权日2010年7月2日
发明者苏巴斯里·德斯坎, 詹姆斯·M·波尔克 申请人:思科技术公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1