CN1954578B - 在基于消息的通信中的改进 - Google Patents

Abstract

依照本发明的一个方面，提供了一种用于在基于消息的通信系统中的中间部件和源部件之间传送信息的方法，其中从所述源部件向目的地部件发送请求消息并且响应于此从所述目的地部件向源部件发送相应的响应消息，所述请求和响应消息被经由中间部件来发送，所述中间部件被安排来把所述消息转送到适当的部件，所述方法包括，在所述中间部件：在转送所接收的请求消息之前：确定在所接收的请求消息中存在要被传送的信息的指示，并且在存在的情况下，采用把与所述中间部件相关联的临时标识符包括在相应的响应消息中的方式来把所述临时标识符添加到所述消息；并且在转送所接收的响应消息之前：确定存在与所述中间部件相关联的临时标识符，并且在存在的情况下，用要被传送到所述源部件的信息来代替所述临时标识符。

Description

在基于消息的通信中的改进

技术领域

本发明总体上涉及通信协议和系统领域，并且尤其涉及基于消息的通信，其中经由一个或多个中间部件在端点之间传送消息。

背景技术

许多通信系统使用基于消息的请求-响应通信协议来在源部件和目的地部件之间通信。常常经由中间部件发送请求和响应消息，所述中间部件把所接收的消息转送到适当的目的地部件。

会话启动协议(SIP)是这种通信协议的一个例子，并且其在Internet标准(RFC)3261中被定义为应用层控制和通信协议，以便主要经由网际协议(IP)网络来建立、修改并终止实时呼叫和会议。通过采用SIP消息的形式从一个SIP部件向另一个SIP部件发送请求并接收响应来实现这些动作。

在一些情况下，中间部件可能有必要向源部件传送信息，然而在中间部件和源部件之间可能并不存在任何直接的双向通信路径。在这种情况下，中间部件与源部件传送信息的唯一方式是等待将从目的地部件所发送的响应消息，并且将要传送的所述信息添加到所述响应消息，其中所述响应消息也经由中间部件发送。在中间部件从多个源和目的地部件接收消息的情况下，另外要求一种机制使得中间部件能够确定哪些响应消息与哪些请求消息相关联。在SIP中，这种情况随着SIP消息压缩的使用而出现，其中要被传送的信息涉及消息压缩，如在RFC 3486中所定义。RFC 3486描述了可以怎样压缩SIP消息并且提供了一个参数，所述参数可以被添加到SIP消息以便表明部件是否支持SIP压缩。

例如，经由中间部件从源部件发送到目的地部件的SIP请求消息可以包含用于表明所述源部件支持SIP压缩的信息。如果中间部件也支持压缩，那么可能需要把信息传送回源部件以便允许将来在源和中间部件之间使用压缩来进行通信。中间部件通过当接收由目的地部件向源部件发送相应的响应消息时把信息插入到该消息中以便向源部件表明所述中间部件也支持压缩来实现这点。

由于诸如SIP代理之类的中间部件典型情况下从多个目的地接收消息，所以需要维护上下文数据库以便使所述中间部件能够把形成相同事务部分的相应请求和响应消息配对。例如RFC 3486中所描述的这种技术要求消息路径中的中间部件(诸如代理服务器)本地存储对话或事务上下文信息——换句话说，当前所建议的技术要求使用有状态(stateful)的部件。

有状态的部件要求提供附加存储容量、数据库、查找例程、无用单元收集例程等，其耗尽了宝贵的处理资源并且典型情况下增加了这种设备的成本和开发时间。例如在SIP中，具有压缩能力的代理服务器常常位于固定和无线网络之间的网关，并且通常是要求高性能和高可用性的关键性网络元件。

如那些本领域技术人员理解，特别是在需要保留大量上下文数据的情况下，要求使部件高度可用是困难且昂贵的。此外，提供高可用性机制典型情况下导致一定程度的性能降低，这在电信应用中是尤其不想要的，例如在可以由部件处理的同时呼叫的数目直接与系统性能相关的情况下，并且该数目常常是在竞争者产品之间显著的区分因素。

据此，本发明的一个目标在于缓和至少一些上述问题。

发明内容

依照本发明的第一方面，提供了一种用于在基于消息的通信系统中的中间部件和源部件之间传送信息的方法，其中从所述源部件向目的地部件发送请求消息并且响应于此从所述目的地部件向源部件发送相应的响应消息，经由中间部件来发送所述请求和响应消息，所述中间部件被安排来把所述消息转送到适当的部件。所述方法包括在中间部件并且在转送所接收的请求消息之前，确定在所接收的请求消息中存在信息要被传送的指示，并且在存在的情况下，采用把与所述中间部件相关联的临时标识符包括在相应的响应消息中的方式把所述临时标识符添加到所述消息。在转送所接收的响应消息之前，所述方法包括：确定存在与中间部件相关联的临时标识符，并且在存在的情况下，用要被传送到源部件的信息来代替所述临时标识符。

有益地是，这使得不必存储与消息相关的上下文信息并因而不必存储相关联的数据库查找例程、无用单元收集例程等。

适当地是，临时标识符在系统内是明确的。

适当地是，添加临时标识符的步骤还包括添加用于标识要被传送到源部件的信息类型的附加信息。

基于消息的通信系统可以是基于会话启动协议(SIP)的系统，其中中间部件是SIP代理服务器，在这种情况下请求消息可以是SIP请求消息，并且其中响应消息可以是SIP响应消息。在这种情况下，在所接收的请求消息中确定存在的步骤还包括确定SIP压缩参数的存在。

请求消息适当地包括SIP代理的URI，于是添加临时标识符的步骤还包括把所述临时标识符添加到所述SIP代理的URI。

适当地是，确定在响应消息中存在临时标识符的步骤还包括确定在所述响应消息内的SIP代理的URI中存在临时标识符。

优选地是，代替临时标识符的步骤还包括用SIP压缩参数来代替所述临时标识符。

适当地是，在SIP代理先前已经向源部件表明该代理支持SIP压缩的情况下，使用压缩来从所述源部件向所述SIP代理发送将来的请求消息。

依照本发明的第二方面，提供了适于依照任何以上所描述的方法步骤操作的中间部件。

依照本发明的第三方面，提供了一种适于依照任何以上所描述的方法步骤来操作的SIP代理。

依照第四方面，提供了一种用于在基于消息的通信系统中转送消息的设备，其中从源部件向目的地部件发送请求消息，并且响应于此从所述源部件向目的地部件发送响应消息，所述系统被这样配置以致消息经由所述设备被发送以便转送到它们适当的目的地，所述系统包括用于在转送所接收的请求消息之前确定在所接收的请求消息中存在要传送的信息的指示的装置，所述装置被配置成在确定存在所述指示的情况下采用把与中间部件相关联的临时标识符包括在相应的响应消息中的方式来把所述临时标识符添加到所述消息；还包括用于在转送所接收的响应消息之前确定在所接收的响应消息中存在与所述中间部件相关联的临时标识符的装置，所述装置被配置成在确定存在所述临时标识符的情况下，用要被传送到所述源部件的信息来代替所述临时标识符。

附图说明

现在将仅以举例形式，参考附图来描述本发明的实施例，其中：

图1A是示出依照现有技术的SIP网络的框图；

图1B是概述在图1A中所示出网络的不同网络元件之间的典型消息流的消息流程图；

图2A是依照本发明实施例示出包括SIP代理服务器的SIP网络的框图；

图2B是概述在图2B中所示出网络的不同网络元件之间的消息流的消息流程图；和

图3是概述依照本发明实施例由SIP代理服务器所执行的示例性处理步骤的流程图。

具体实施方式

参考会话启动协议(SIP)网络来进行以下描述。然而本领域技术人员应当理解，这里所描述的发明原理决不限于SIP，并且可以按要求采用适当的修改来用于具有类似特性的其它通信协议。

图1A示出了依照现有技术的典型SIP网络100的框图。SIP网络包括多个网络元件，即SIP用户代理客户端(UAC)102、SIP用户代理服务器(UAS)110和多个中间部件，诸如SIP代理服务器104、106和108。UAC 102例如可以通过向UAS 110发送诸如INVITE消息之类的请求消息来与所述UAS 110建立呼叫。UAS可以用诸如200 OK消息之类的响应消息作出响应，如下面将进一步描述。那些本领域技术人员应当理解，还可以发送附加消息以便完成呼叫建立。

在SIP中，这种消息交换被称为事务，事务包括从服务器所发送的第一请求消息直到从所述服务器向客户端发回的最终(非1xx)响应消息的所有消息。SIP呼叫被定义为包括从初始INVITE消息直到BYE消息的所有消息。SIP呼叫可以包括多个事务。

代理服务器104、106和108用来依照已知方式路由消息。在此例子中，UAC 102和代理服务器106依照RFC 3486支持SIP消息压缩，而其它网络元件不支持。

现在参照图1B，示出了消息流程图，用于示出在UAC 102和UAS 110之间建立呼叫所涉及的初始消息。那些本领域技术人员应当理解在呼叫建立中还可以涉及附加消息。为了清楚起见，在图1B中所示出的消息以简写形式示出并且只示出了一些可用的SIP消息首部。

UAC 102向UAS 110发送SIP INVITE消息120。INVITE消息120最初被发送到代理服务器104，在UAC 102中预先配置所述代理服务器104的地址。INVITE消息120的Contact首部包含UAC 102的统一资源指示符(URI)。如上所述，UAC 102支持SIP消息压缩，因此依照RFC 3486，所述UAC 102把参数comp＝sigcomp添加到Contact首部中的URI。comp可以采取的值表明要使用的压缩配置类型。以下假定使用在RFC 3320中所定义的信号压缩(SigComp)配置，然而实际的压缩机制在本发明的范围以外并且将不再进一步论述。为了清楚起见，以下使用简化符号comp来代替普通写法符号comp＝sigcomp。在SIP消息首部的URI中存在comp参数用来表明特定的部件支持压缩并且部件希望在可能的情况下以压缩格式接收将来的消息。

如果UAC 102知道代理104还支持压缩，那么所述UAC 102还可以被预先配置以便以压缩形式发送初始消息。

由于UAC 102并不知道至少在此时并不知道SIP网络中的任何其它部件是否支持SIP消息压缩，所以所述UAC 102在已经把Via首部添加到具有UAC 102的URI的消息120之后最初发送未压缩的消息。

不支持SIP压缩并因而无状态的SIP代理104，接收INVITE消息120并且在已经将其URI添加到Via首部的列表之后把所述消息转送到SIP代理106。

支持SIP压缩的SIP代理106接收INVITE消息122。代理106被配置为在相同的SIP对话中停留在将来请求的路径中并且通过把包含其URI的RECORD-ROUTE首部添加到消息来实现这点。由于代理106支持压缩，所以它把信息存储在事务上下文数据存储装置中。所存储的信息类型包括Contact URI、唯一的呼叫标识及其它信息，所述其它信息可由代理用来把当前请求与最终的响应消息相配。附加信息被存储来表明当与不同的SIP部件通信时是否应当使用压缩。因而代理202被称为有状态的代理。最后，代理106将其URI添加到Via首部的列表，并且把未压缩的消息124转送到SIP代理108，这是因为代理106最初同样不知道代理108是否支持压缩。

在此例子中并不支持压缩并因而是无状态的SIP代理108接收INVITE消息124，并且当它也希望在相同的对话中留在用于将来请求的路径中时，把包含其URI的RECORD-ROUTE(记录-路由)首部添加到所述消息并且把其URI添加到Via首部的列表顶部。由于代理108并不知道UAS是否支持SIP压缩，所以所述消息被未压缩地发送到UAS110。

UAS 110依照通常方式接收并处理消息126。由于INVITE消息是呼叫的第一消息，所以UAS 110构造并存储‘路由集’作为当前呼叫上下文的一部分。路由集是用于标识一系列服务器的有序URI的集合，经由所述一系列服务器发送在当前对话以外的新请求。路由集可以通过像记录-路由那样的首部来学习，或可以被配置。对于UAS 110来说，路由集从消息126的首部信息中获得并且包括：

路由集：

P3

P2

UAC；comp

因而在相同呼叫内从UAS 110向UAC 102所发送的新请求会经由在路由集中所提供的路由发送。然而，这只是应用于新的请求，而不应用于响应于先前请求所发送的消息。

UAS 110通过向UAC 102发回响应200 OK消息128来对所接收的INVITE消息作出响应。SIP要求响应消息追随由相应的请求消息所采用的相同路径，并且通过向在消息128的Via列表顶部中所表明的下一跳跃地址发送响应128来保证，在这种情况下所述下一跳跃地址是代理108。由于UAS 110不支持压缩，所以采用未压缩形式来发送消息。

代理108接收消息128，将其URI从Via首部列表中删除并且把消息130未压缩地转送到代理106。

当作为有状态代理的代理106接收响应消息130时，所述代理确定所接收的消息是否是当前事务的一部分。例如这可以通过把当前消息的事务标识符与在事务上下文中所存储的信息相匹配来实现。如果所述消息是当前事务的一部分，那么代理分析所接收的消息以便确定它是否为记录-路由的。这里以及在SIP规范中所使用的术语记录-路由指的是先前已经把记录-路由首部插入到相同事务内的SIP消息中的SIP部件。

如果代理106记录-路由，那么所述代理检查为此对话而设置的路由。在这种情况下所述路由包括：UAS 102、代理108、代理106和UAC102。由于代理104未记录-路由，所以它不包括在所述路由中。代理106检查路由中的下一下游部件(在这种情况下为UAC 102)，来确定它是否支持压缩。这可以通过确定压缩参数是否存在于UAC 102的URI中来实现。

由于在消息130的Contact首部中的UAC 102的URI包含comp参数，借此表明UAC支持SIP压缩请求，所以代理106将其自己的压缩参数添加到所述消息的适当部分。在这种情况下，这通过修改其消息132的记录-路由首部以包括comp参数来实现。

当UAC接收消息134时，UAC通过在所接收的消息中所包含的首部信息来构造路由集，所述路由集包括：

路由集：

P2；comp

P3

UAS

代理106的路由集条目包括压缩参数的事实使UAC能够以压缩格式在相同的对话内发送进一步的请求，如下所见。

UAC 102处理所接收的消息134并且通过向UAS 110发回ACK消息来作出响应。RFC 3261指定ACK消息形成新事务的一部分，由此它不必追随与初始INVITE消息相同的路径，并因而所述ACK以压缩格式被直接发送到代理106。

代理106以未压缩格式把所述消息转送到代理108，所述代理108随后采用正常方式把所述消息转送到UAS 110。

因而可以看出在现有技术中为了实现SIP消息压缩，要求在支持SIP压缩的每个代理中维护事务上下文数据存储装置。另外，代理还必须通过分析消息首部来确定响应路径中的另一部件是否支持压缩。此外，由于支持压缩的SIP代理服务器必须是事务有状态的，所以SIP代理中的资源要求与由相同系统所处理的同时建立的事务数目成正比。

现在参考图2来描述依照本发明的实施例，其使支持压缩的SIP代理服务器能够是无状态的。

图2A表现了与图1A中所示的类似的SIP网络和消息流，并且向同样的部件和消息给出了相同的数字标识符。SIP网络包括SIP用户代理客户端(UAC)102、三个SIP代理服务器分别为104、202和108以及SIP用户代理服务器(UAS)110。下面更详细地描述代理服务器202。

图2B示出了用于概述SIP事务的消息流的消息流程图，所述SIP事务涉及SIP网络的各个部件，依照本发明实施例包括SIP代理202。

事务以UAC 102经由包括代理服务器104、202和108的SIP网络向UAS 110发送INVITE消息120开始。

消息120最初被发送到代理服务器104，在UAC 102中预先配置所述代理服务器104的地址。INVITE消息120的Contact首部包含UAC 102的URI。在此例子中，UAC 102支持SIP消息压缩，因此所述UAC 102把参数comp添加到Contact首部中的URI。

UAC 102把消息120的Via首部设置为UAC 102的URI。由于UAC此时并不知道代理104是否支持压缩，所以未压缩地发送消息120。

不支持SIP压缩并因而无状态的SIP代理104，接收INVITE消息120并且在已经将其URI添加到Via首部的列表之后把所述消息转送到SIP代理202。

支持SIP压缩的SIP代理202接收INVITE消息122。代理202被配置为在相同的SIP对话中留在将来请求的路径中并因此把包含其URI的RECORD-ROUTE首部添加到消息。然而，与如上所述的代理106不同，代理202是无状态的-换句话说它不维护事务上下文由此不要求任何上下文存储装置。下面参考图3来描述代理202的操作。

当消息由代理202接收时(步骤302)，所述代理确定(步骤304)所述消息是请求消息还是响应消息。如果在这种情况下，所接收的消息是请求消息，那么代理找到在所述消息包含其URI的记录-路由首部(代理202刚刚添加到消息的)(步骤312)，并且向其添加(步骤314)新的压缩参数。新的压缩参数包括用于明确标识代理202的标识符和用于表明是否应当压缩将来请求的压缩标志。可以采用多种不同的方式来导出明确的标识符，这对那些本领域技术人员来说是显而易见的。

由代理202依照下列方式来确定标志值。代理202分析所接收的消息来确定下一上游部件是否支持SIP压缩。可以通过首先确定在消息中存在最顶部的记录-路由首部(如果存在的话)来确定下一上游(即向UAC方向)部件，这是由于如果任何部件已经记录-路由的话，那么任何新的请求消息会自动地通过所述记录-路由的部件。如果没有记录-路由首部，那么这意味着下一上游部件是由所接收消息的Contact首部所定义的部件。一旦已经建立下一上游部件的URI，那么代理202分析其URI来确定comp参数的存在。如果存在comp参数，那么这表明可以以压缩形式发送在下一上游部件和代理202之间所发送的将来请求消息。据此，代理202设置标志值以表明应当使用压缩，否则所述标志被设置为表明不应当使用压缩。然而在此，代理202的记录-路由参数并不包含comp参数。

最后，代理202将其URI添加到Via首部的列表，并且把未压缩的消息210转送到SIP代理108，这是由于代理106最初同样不知道代理108是否支持压缩。

应当注意，如果代理被配置为留在路径中，例如通过被配置为添加记录-路由首部，那么只把明确的标识符和标志插入该消息。

不支持压缩的SIP代理108接收INVITE消息210，当它也希望在相同的对话中留在用于将来请求的路径中时，把包含其URI的RECORD-ROUTE首部添加到消息，把消息细节添加到事务上下文数据存储装置，并且把其URI添加到Via首部的列表顶部。由于代理108并不知道UAS是否支持SIP压缩，所以所述消息被未压缩地发送到UAS 110。

UAS 110接收并处理消息212。由于INVITE消息是呼叫的第一消息，所以UAS 110存储路由集作为当前呼叫上下文的一部分。对于UAS110来说，路由集从消息126的首部信息中获得并且包括：

路由集：

P3

P2：ID+FLAG

UAC；comp

因而在相同呼叫内从UAS 110向UAC 102所发送的新请求会经由在路由集中所提供的路由发送。

然后UAS 110向UAC 102发回响应200 OK消息128。如上所述，SIP要求响应消息追随由相应的请求消息所采用的相同路径，并且通过向在消息214的Via列表顶部中所表明的下一跳跃地址发送响应214来保证，在这种情况下所述下一跳跃地址是代理108。由于下一跳跃地址并不包含comp参数，所以所述消息被未压缩地发送。

代理108接收消息214，将其URI从Via首部列表中删除并且把消息216未压缩地转送到代理202。

当代理202接收(步骤302)消息216时，并且再次参照图3，所述代理确定(步骤304)所接收的消息216是请求还是响应的一部分。在这种情况下，所接收的消息是响应消息——换句话说，所接收的消息是包括初始请求INVITE消息的事务的一部分。因此代理202检查所述消息以便找到在路由中下一下游部件(即UAC)的相关首部并且搜索所接收的消息以查看存在上述的明确标识符。由于搜索所要求的简单性，这种搜索例程可以在速度和效率上优化。

如果在消息中找到代理202的标识符，那么获得标志值。在这种情况下，如上所述所述标志表明应当压缩将来请求消息，而且下一下游部件支持压缩。因此代理202修改消息216中的记录-路由条目以便删除先前添加的明确标识符和标志，并且用comp参数来代替。然后所修改的消息218被转送到代理104。

那些本领域技术人员应当知道在SIP中，始终参考当前请求或响应的消息流方向来理解概念‘上游’和‘下游’。

当UAC接收消息134时，UAC通过在所接收的消息中所包含的首部信息来构造路由集，所述路由集包括：

路由集：

P2；comp

P3

UAS

UAC 102处理所接收的消息134并且通过向UAS 110发回ACK消息来作出响应。由于代理202已经记录-路由并且所述记录-路由首部表明所述代理202支持SIP压缩，所以消息136以压缩格式被直接发送到代理106。如分别在消息138和140中所示，ACK消息136以未压缩格式经由代理108被转送到UAS 110。

为了概括，SIP压缩提供了一种机制，借此源部件(诸如UAC)当向中间部件发送将来请求消息时可以要求所述中间部件(诸如代理)向所述源部件表明所述源部件是否可以使用压缩。由于SIP只提供单向通信路径，即请求或响应，所以可以只在响应消息中给出这种指示。依照本实施例有益地是，这种机制并不要求使用有状态的中间部件。

上述过程的效果在于由UAC 102所接收的200 OK消息134与现有技术中所接收的消息相同，区别之处在于现有技术要求使用有状态的代理服务器，而本实施例只要求使用无状态的代理服务器。因而，依照上述实施例的SIP代理服务器可以被部署在要求支持SIP消息压缩的SIP网络中，可以获得与有状态的代理服务器相对比使用无状态代理服务器所提及的整个优点。

那些本领域技术人员应当理解相同的技术也可以应用于其它SIP部件，诸如背对背用户代理(B2BUA)。

Claims (15)

1.一种用于在基于消息的通信系统中的中间部件和源部件之间传送信息的方法，其中从所述源部件向目的地部件发送请求消息并且响应于此从所述目的地部件向源部件发送相应的响应消息，经由中间部件来发送所述请求和响应消息，所述中间部件被安排来把所述请求消息转送到目的地部件或者把所述响应消息转送到源部件，在所述中间部件处所述方法包括：

在转送所接收的请求消息之前：

确定在所接收的请求消息中存在要被传送的信息的指示，并且在存在的情况下，把与所述中间部件相关联的临时标识符添加到所接收的请求消息，添加的方式使得所述临时标识符被包括在相应的响应消息中；并且

在转送所接收的响应消息之前；

确定存在与所述中间部件相关联的临时标识符，并且在存在的情况下，用要被传送到所述源部件的信息来代替所述临时标识符。

2.如权利要求1所述的方法，其中添加所述临时标识符的步骤还包括添加用于明确标识所述中间部件的标识符。

3.如权利要求1或2所述的方法，其中添加所述临时标识符的步骤还包括添加用于标识要被传送到源部件的信息的类型的附加信息。

4.如权利要求1所述的方法，其中基于消息的通信系统是基于会话启动协议SIP的系统，其中所述中间部件是SIP代理服务器，其中所述请求消息是SIP请求消息，其中所述响应消息是SIP响应消息，并且其中确定在所接收的请求消息中存在要被传送的信息的指示的步骤还包括确定存在下一上游部件的SIP压缩参数。

5.如权利要求4所述的方法，其中所述请求消息包括SIP代理服务器的URI，并且其中添加所述临时标识符的步骤还包括把所述临时标识符添加到SIP代理服务器的URI。

6.如权利要求5所述的方法，其中确定在响应消息中存在临时标识符的步骤还包括确定在所述响应消息内的SIP代理服务器的URI中存在临时标识符。

7.如权利要求6所述的方法，其中代替临时标识符的步骤还包括用SIP代理服务器的SIP压缩参数来代替所述临时标识符。

8.如权利要求4到7中任何一个所述的方法，还包括在SIP代理服务器先前已经向所述源部件表明该SIP代理服务器支持SIP压缩的情况下，使用压缩从所述源部件向SIP代理服务器发送将来的请求消息。

9.一种用于在基于消息的通信系统中转送消息的设备，其中从源部件向目的地部件发送请求消息，并且响应于此从所述目的地部件向源部件发送响应消息，所述系统被这样配置以致请求消息经由所述设备发送以便转送到目的地部件，或者响应消息经由所述设备发送以便转送到源部件，包括：

用于在转送所接收的请求消息之前，确定在所接收的请求消息中存在要被传送的信息的指示的装置，所述装置被配置成在确定存在所述指示的情况下，把与所述设备相关联的临时标识符添加到所接收的请求消息，添加的方式使得所述临时标识符被包括在相应的响应消息中；和

用于在转送所接收的响应消息之前，确定在所接收的响应消息中存在与所述设备相关联的临时标识符的装置，所述装置被配置成在确定存在所述临时标识符的情况下，用要被传送到所述源部件的信息来代替所述临时标识符。

10.如权利要求9所述的设备，其中用于确定在所接收的请求消息中存在要被传送的信息的指示的装置适于添加用于明确标识所述设备的标识符。

11.如权利要求9或10所述的设备，其中用于确定在所接收的请求消息中存在要被传送的信息的指示的装置适于添加用于标识要被传送到源部件的信息的类型的附加信息。

12.如权利要求9所述的设备，其中基于消息的通信系统是基于会话启动协议SIP的系统，其中所述设备是SIP代理服务器，其中所述请求消息是SIP请求消息，其中所述响应消息是SIP响应消息，并且其中用于确定在所接收的请求消息中存在要被传送的信息的指示的装置适于确定存在下一上游部件的SIP压缩参数。

13.如权利要求12所述的设备，其中所述请求消息包括SIP代理服务器的URI，并且其中用于确定在所接收的请求消息中存在要被传送的信息的指示的装置适于把所述临时标识符添加到所述SIP代理服务器的URI。

14.如权利要求13所述的设备，其中用于确定在所接收的响应消息中存在与所述设备相关联的临时标识符的装置适于确定在所述响应消息内的SIP代理服务器的URI中存在临时标识符。

15.如权利要求14所述的设备，其中用于确定在所接收的响应消息中存在与所述设备相关联的临时标识符的装置适于用SIP代理服务器的SIP压缩参数来代替所述临时标识符。

Images