CN1835505A - 会话中继装置 - Google Patents

会话中继装置 Download PDF

Info

Publication number
CN1835505A
CN1835505A CNA2005101357661A CN200510135766A CN1835505A CN 1835505 A CN1835505 A CN 1835505A CN A2005101357661 A CNA2005101357661 A CN A2005101357661A CN 200510135766 A CN200510135766 A CN 200510135766A CN 1835505 A CN1835505 A CN 1835505A
Authority
CN
China
Prior art keywords
sip
program
information
message
session
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.)
Granted
Application number
CNA2005101357661A
Other languages
English (en)
Other versions
CN1835505B (zh
Inventor
吉泽政洋
汤本一磨
川井惠理
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of CN1835505A publication Critical patent/CN1835505A/zh
Application granted granted Critical
Publication of CN1835505B publication Critical patent/CN1835505B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • 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/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • 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/1101—Session protocols
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13164—Traffic (registration, measurement,...)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166—Fault prevention
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13348—Channel/line reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供一种使用传输调用控制报文的会话中继装置，解决若导致会话中继装置间的协作频繁进行，则有可能在调用控制报文的路径上扩充处理被多余执行的问题。会话中继装置每次接收调用控制报文，都计算与传输该报文的路径有关的信息。由于除调用控制报文之外还将其路径信息提交给扩充处理程序，因而要为每个会话决定是否应在同会话中继装置上执行其扩充处理。另外，执行扩充处理后的会话中继装置为了将这种情况通知给其他的会话中继装置，在调用控制报文中添加表明处理状况的信息。

Description

会话中继装置
技术领域
本发明涉及使用传输调用控制报文的会话中继装置，在传输调用控制报文的传送路径上执行扩充处理(extended processing)的装置和系统。
背景技术
近年来，由于宽带的普及和IP(Internet Protocol)电话协议(VoIP(Voice over IP)protocol)标准化的进展，IP电话正在快速得到普及。在那些IP电话协议之中尤为普及的是SIP(Session InitiationProtocol)，该SIP是一种考虑了因特网的特性所设计出的IP电话协议。
SIP的最单纯的结构中的结构要件是下面的3个。在本说明书中，当对于实施示例进行说明时，也使用下面的定义。
第一个结构要件是SIP UA(User Agent)。它是一种通信终端，可以解释作为SIP之调用控制报文的SIP报文。
第二个结构要件是区域服务器(location server)。它是一种服务器，用来对表示SIP UA的名字(Universal Resource Identifier；URI等)和SIP UA网络地址的关联关系进行管理。
区域服务器用来管理SIP UA和SIP代理(SIP proxy)。在本说明书中，为了和DNS(Domain Name System)中的域(domain)相区别，将由1个区域服务器管理的SIP UA和SIP代理的范围称为各区域服务器的作用域(scope)。域和作用域的范围通常相一致，但是也可以完全不一致，例如1个作用域包括多个域等。
第三个结构要件是SIP代理。它是一种服务器，用来根据区域服务器上的信息，向目的地的SIP UA传输SIP报文(SIP message)。SIP代理不一定需要直接给目的地的SIP UA传输SIP报文，也可以往比自身更接近目的地的其他SIP代理传输SIP报文。
另外，SIP代理在接收到SIP报文时，有时执行除SIP报文传输之外的扩充处理。在那种扩充处理中，有和RTP(Real-Time TransportProtocol)代理等媒体中继装置(media relay server)之间的协作、和呈现服务器(presence server)之间的协作、和Web服务器之间的协作、注册的记录、收费信息的记录以及QoS(Quality of Service)控制等。由于原本SIP是作为下述调用控制协议设计出的，该调用控制协议为因特网上多媒体通信的基础，因而SIP代理也可以利用和其他服务器进行协作的扩充处理容易地执行。但是，只要产生本发明的效果，扩充处理即使不是这里所列举的处理也可以。
以上是SIP代理中的扩充处理示例，但是在其他调用控制协议中，还存在执行除调用控制报文传输之外的扩充处理的会话中继装置。
下面，提示一种因下述处理而产生的课题，该处理为由用来传输调用控制报文的会话中继装置，执行除调用控制报文传输之外的扩充处理。
目前，用来执行除调用控制报文传输之外的扩充处理的会话中继装置很少和其他从业者管理的会话中继装置进行协作。但是，若以后从业者间的连接增加等，致使会话中继装置间的协作频繁进行，则有可能在调用控制报文的路径上重复执行扩充处理，或者未执行必要的扩充处理。
图21是在SIP中会话中继装置(SIP代理)作为扩充处理和媒体中继装置(RTP代理)进行了协作时的示例。
该附图表示出，在SIP UA2-1和SIP UA2-2之间交换调用控制报文(SIP报文100)时的状况。此时，SIP代理3-1因为SIP UA2-1处于NAT(Network Address Translation)装置7-1的后面，所以和RTP代理5-1进行协作，并且SIP代理3-2因为SIP UA2-2处于NAT装置(NAT equipment)7-2的后面，所以和RTP代理5-2进行协作。这样，由于SIP代理不具有用来获知由其他SIP代理执行后的扩充处理的机构，因而会重复执行原本在路径只执行一次就足够的RTP代理协作。
因此，为了避免这种状况，在会话中继装置间需要可决定由哪个会话中继装置执行扩充处理的连贯方法。上面课题的内容并不限定为SIP。
另外，只要产生本发明的效果，扩充处理不是上述示例那种和RTP代理之间的协作处理也可以。
发明内容
在本发明中，在各会话中继装置的存储器上具备两种程序，一种用来计算与传输调用控制报文的路径有关的信息，另一种用来计算与各用户终端所需要的扩充处理有关的信息。另外，和它们2种程序不同，在各会话中继装置的存储器上具备用来执行扩充处理的程序。
各会话中继装置通过除调用控制报文之外，还将上述2个信息提交给用来执行扩充处理的程序，为每个会话决定是否应在同会话中继装置上执行其扩充处理。另外，会话中继装置为了将已执行扩充处理的状况通知给其他会话中继装置，要在调用控制报文中添加表明处理状况的信息。借此，来达到上述目标。
发明效果
因为由路径上的会话中继装置执行扩充处理的次数被抑制为最低限度，所以会话中继装置中的处理负荷得以减轻，传输调用控制报文时的延迟时间变短。另外，在会话中继装置中的处理伴随和外部服务器之间的协作时，不仅是会话中继装置，还关系到外部服务器通信量的减少。这样一来，网络整体的负荷得以减轻。
附图说明
图1表示的是实施示例1中假定的网络物理结构。
图2表示的是实施示例2中假定的网络物理结构。
图3表示的是实施示例3中假定的网络物理结构。
图4表示的是实施示例4中假定的网络物理结构。
图5是将实施示例1、2的SIP代理内部结构在功能上展开的附图。
图6是将实施示例3的SIP代理内部结构在功能上展开的附图。
图7是将实施示例4的SIP代理内部结构在功能上展开的附图。
图8是表示路径决定程序内部动作的流程图。
图9是表示路径决定程序内部动作的流程图。
图10是表示处理信息取得程序内部动作的流程图。
图11是表示RTP代理协作程序内部动作的流程图。
图12是表示RTP代理协作程序内部动作的流程图。
图13是表示RTP代理协作程序内部动作的流程图。
图14是表示呈现服务器协作程序内部动作的流程图。
图15是表示呈现服务器协作程序内部动作的流程图。
图16表示的是实施示例1的动作顺序。
图17表示的是实施示例2的动作顺序。
图18表示的是实施示例3的动作顺序。
图19表示的是实施示例4的动作顺序。
图20表示的是在实施示例1中添加了RTP代理协作的处理通知的SIP报文示例。
图21表示的是以往采用SIP代理的网络物理结构。
实施示例1
下面，根据附图来说明实施示例。
图1-a模式表示在本实施示例中假定的物理通信网络的结构。作为SIP UA2-1除具备通信功能的PC或电话式终端那种固定终端之外，还可以是移动电话或PDA(Personal Digital Assistant)那类的移动终端。3-1是SIP代理，用来根据区域服务器4-1管理的信息，决定SIP报文的路径并进行传输。如同图1-b的SIP服务器8-1那样，SIP代理和区域服务器也可以整体形成。上述SIP UA2-1、NAT装置7-1、SIP代理3-1、区域服务器4-1及RTP代理5-1相互通过物理通信线路9来连接。SIP UA2-1可以只经由SIP代理3-1来收发SIP报文。另外，它们属于相同的作用域10-1。
作用域10-2的SIP UA2-2、NAT装置7-2、SIP代理3-2、区域服务器4-2及RTP代理5-2也和作用域10-1相同，相互通过物理通信线路9来连接。SIP UA2-2通过NAT装置7-2间接连接到通信网1-2上，并且SIP UA2-2可以只经由SIP代理3-2来收发SIP报文。
另外，通信网1-1和通信网1-2通过物理通信线路9来连接。作用域10-1只是指区域服务器4-1管理的范围，作用域10-2只是指区域服务器4-2管理的范围，并且作用域的范围并不一定根据物理的位置加以限制。但是，在附图中，为了帮助理解，使物理通信网络上的位置和作用域的范围相一致。
实施示例1到4的区域服务器除了以往区域服务器管理的信息之外，还管理与下述扩充处理有关的信息，该扩充处理是该区域服务器管理的作用域内各SIP UA所请求的。在实施示例1中，区域服务器4-1管理着「SIP UA2-1请求RTP代理协作」这样的信息，区域服务器4-2管理着「SIP UA2-2请求RTP代理协作」这样的信息。
另外，实施示例1、2及4的RTP代理是一种单纯的装置，用于若从SIP代理获取到用来唯一确定会话的识别符(identifier)(Call-ID等)，则如果与其会话相对应的端口号码(port number)尚未分配，就进行新分配，随后将其端口号码回发给SIP代理。
在实施示例1中，在SIP UA2-1和SIP UA2-2之间建立会话。较细的实线100用来表示在SIP UA2-1和SIP UA2-2之间建立会话时的SIP报文流。这里，SIP UA2-1设为呼叫方(caller)(发送过INVITE的SIP UA)，SIP UA2-2设为被呼叫方(callee)。另外，虚线110用来表示RTP数据流。
图5表示，将图1-a所示的SIP代理3(SIP代理3-1、SIP代理3-2共同)的内部结构在功能上展开所示的框图。SIP代理3通过IF31来收发SIP报文。SIP代理3的各程序存储于存储器33中，并且在进行动作时CPU32通过数据通路34将它们读出并加以执行。另外，SIP代理3管理的各种表也存储于存储器33中，并且由此取出必要的信息，予以写入。这些表也可以存储于硬盘等用存储系统来实现的DB装置中。
存储器33用来存储会话管理表(session management table)330、调用控制程序(signaling program)331、路径决定程序(path decisionprogram)332、处理信息取得程序(processing-information acquisitionprogram)333、RTP代理协作程序(RTP proxy interaction program或者interaction program with RTP proxy)334及静态处理信息表(staticprocessing-information table)337。
会话管理表330用来存储与SIP代理3当前处理的会话有关的信息。在这些信息中，有各会话的状态、会话的识别符、呼叫方和被呼叫方的URI及Contact地址等。在本专利中，会话管理表330除通常SIP代理管理的这些信息之外，还存储路径类型(path type)、上一跳(previous hop)、下一跳(next hop)以及与由该会话执行过的扩充处理有关的信息。
所谓路径类型表示路径整体的特征，是封闭于1个作用域内的路径(下面，为「封闭」(closed))或是跨越多个作用域的路径(下面，为「开放」(open))的某一个。根据SIP报文的From报头中包含的URI(下面，为呼叫方URI(Caller URI))和To报头中包含的URI(下面，为被呼叫方URI(Callee URI))，来决定。
所谓上一跳指的是对SIP代理3的SIP报文发送源，并且是属于和SIP代理3相同的作用域的SIP UA(下面，为同作用域UA(same-scope UA))、属于和SIP代理3相同的作用域的其他SIP代理(下面，为同作用域SIP代理(same-scope SIP proxy))以及属于和SIP代理3不同的作用域的SIP代理(下面，为其他作用域SIP代理(other-scope SIP proxy))的3种。其任一个都根据SIP代理3使用在其SIP报文接收中的NNI(Network-Network Interface)或者UNI(User-Network Interface)，来决定。
所谓下一跳指的是SIP代理3后续发送SIP报文的发送源，并且是同作用域UA、同作用域SIP代理以及其他作用域SIP代理的3种。其任一个都根据被呼叫方URI来决定。
所谓与由该会话执行过的扩充处理有关的信息指的是，SIP代理3对于各自的扩充处理记录了「执行(execute)」还是「未执行(notexecute)」的信息。其用途将在下面说明。
另外，在下面的实施示例1～4中，会话管理表330除了存储上述信息的区域之外，还具有用来对从区域服务器4所取得的呼叫方或被呼叫方(或者其双方)的信息进行高速缓存的区域。但是，在本发明中，也可以没有这种高速缓存器。
调用控制程序331用来执行SIP报文的基本操作。除了调出路径决定程序332、处理信息取得程序333还有扩充处理程序(RTP代理协作程序334和实施示例3以后的呈现服务器协作程序(presenceserver interaction program或者interaction program with presenceserver)335等)的这一点之外，还提供和现有的SIP代理相同的功能。
路径决定程序332用来计算与传输调用控制报文的路径有关的信息。该程序计算传输SIP报文的路径之路径类型、上一跳还有下一跳。
处理信息取得程序333用来计算与各SIP UA所需要的扩充处理有关的信息。在那些信息中，有动态信息(dynamicprocessing-information(dynamic information))和静态信息(staticprocessing-information(static information))。前一个是对每个SIP UA都不同的信息，例如是「SIP UA(因为处于NAT装置的后面)请求了RTP代理协作等」的信息。后一个是作用域内的SIP UA共同的信息，例如是「若作用域内的SIP UA开始通话则将其状态自动更新为「通话中」」等的信息。
RTP代理协作程序334是执行扩充处理的程序一种，用来获取路径决定程序332和处理信息取得程序333的计算结果，并且只在满足特定条件时，才执行SIP代理-RTP代理间协作(SIP proxy-RTP proxyinteraction)(下面，为RTP代理协作(RTP proxy interaction))。所谓RTP代理协作指的是，由于对RTP代理请求端口号码的分配，并使用所分配的端口号码来重写SDP(Session Description Protocol)报文的内容，因而在SIP UA间交换的RTP数据包必定经由RTP代理。
静态处理信息表337用来存储与各SIP UA所需要的扩充处理有关的信息之内作用域内的所有SIP UA共同的信息。在实施示例1及2中，该表也可以不特别包含信息。
如上所述，由于为了判断是否应执行扩充处理而计算必要信息的程序和执行扩充处理的程序相分开，因而不用对原本存在于会话中继装置中的程序进行修正，就可以容易地添加或删除用来执行扩充处理的程序。
图16是表示在SIP UA2-1和SIP UA2-2之间建立会话时的动作一个示例的顺序图。下面，使用图16所示的顺序图及图8～13所示的流程图，来说明当SIP报文经由多个SIP代理时动态决定用来执行RTP代理协作的SIP代理之状况。
若SIP代理3-1从SIP UA2-1接收到包含SDP的INVITE(S601)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332判断SIP报文是否是请求(S101)，在是请求时，判断其是否是ACK(S102)。此时，由于请求是INVITE，因而首先将路径类型设定为「封闭」(S103)。随后，根据呼叫方URI的域等，来判别与呼叫方URI相对应的UA(下面，为呼叫方UA(callerUA))是同作用域UA还是其他作用域UA(S104)。由于SIP UA2-1和SIP代理3-1属于相同的作用域(S105)，因而从区域服务器4-1取得呼叫方UA的信息(S106)。与此相同，对于与被呼叫方URI相对应的UA(下面，为被呼叫方UA(callee UA))，也判别是同作用域UA还是其他作用域UA(S108)。
由于SIP UA2-2和SIP代理3-1属于不同的作用域(S109)，因而将路径类型设定为「开放」(S111)。
接着，路径决定程序332判别请求的接收是经由UNI进行的还是经由NNI进行的(S117)。该判别是通过对INVITE的发送源地址是否是作为NNI已事先登录的地址进行比较等来进行的。由于INVITE的发送源地址是SIP UA2-1，因而将呼叫方UA(同作用域UA)设定为上一跳(S119)。
由于根据S108的结果，判明被呼叫方UA不是同作用域UA(S121)，因而路径决定程序332将可以往SIP UA2-2传输INVITE的SIP代理3-2(其他作用域SIP代理)设定为下一跳(S125)。然后，作为该会话原有的信息，将路径类型、上一跳及下一跳的信息(S604)登录到会话管理表中(S126)。然后，和路径类型等不同，将从区域服务器所取得信息的高速缓存器登录到会话管理表中(S127)。路径决定程序332将如上所得到的信息回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。
处理信息取得程序333从会话管理表取得属于同作用域的SIPUA信息的高速缓存器(它是在S127中登录过的)。在本实施示例中，虽然利用了高速缓存器，但是在不利用高速缓存器时，也可以在此再访问区域服务器。另外，在除区域服务器之外还存在用来存储与扩充处理有关的动态信息的专用服务器时，也可以访问该服务器。优选的是，在注重总处理能力时，要利用高速缓存器，在注重SIP代理上存储器和磁盘区域的节约时，要利用区域服务器或专用服务器。
在本示例中，由于呼叫方UA是同作用域UA(S201)，因而取得呼叫方UA的处理信息(S202)，并且由于被呼叫方UA是其他作用域UA(S203)，因而不特别进行任何动作。随后，从静态处理信息表取得同作用域内共同的处理信息(S205)。在实施示例1中，由于静态处理信息表337不包含任何信息，因而不能取得任何静态信息。处理信息取得程序333将如上所得到的「呼叫方UA请求RTP代理协作」这样的动态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。调用控制程序331在调出RTP代理协作程序334这样的扩充处理程序时，转交从路径决定程序332和处理信息取得程序333获取到的计算结果。
RTP代理协作程序334检查上一跳或下一跳是否是同作用域UA(S301)。在本示例中，由于上一跳是同作用域UA，因而接着检查呼叫方UA或被呼叫方UA是否请求了RTP代理协作(S302)。在本示例中，由于根据在S106中从区域服务器4-1所取得的信息，判明作为呼叫方UA的SIP UA2-1请求了RTP代理协作，因而进入下面的处理。
在本示例中，所接收到的SIP报文是INVITE(S304)，并且包含有SDP(S305)。因此，接着检查路径类型是否是「开放」(S315)。这里，由于路径类型是「开放」，因而检查在SIP报文中有没有RTP代理协作的处理通知(S316)。这里，由于上一跳是同作用域UA(SIPUA2-1)，因而在SIP报文中未包含SIP代理的处理通知。至此是RTP代理协作程序334的处理条件判定部分。RTP代理协作程序334进行这种处理条件判定的原因是，为了本实施示例以外的网络结构也可以通过相同的程序来应对。
然后，RTP代理协作程序334对SDP的内容进行分析(S320)，向RTP代理传送端口分配请求(port allocation request)(S321)。RTP代理5-1对端口分配请求中包含的会话识别符(S605)，新分配端口号码，并回复该端口号码来作为响应(S606)。RTP代理协作程序334根据该端口号码来进行SDP报文的修正(S322)。随后，在会话管理表330中记录由该会话执行过RTP代理协作的状况(S323)。这种执行的记录具有可以使此后接收到与该会话有关的SIP报文(2xx或ACK等)时的计算得以简单化的效果。
在此，由于路径类型是「开放」(S324)，因而将RTP代理协作的处理通知添加到SIP报文中(S325)。对于属于不同作用域的SIP代理，则需要明确通知已执行RTP代理协作。
图20是表示该添加示例的附图。
在图20-a的示例中，在独自定义的Proxy-Processing报头中，存储有表明RTP代理协作已执行的「rtp」这样的字符串。即使不为处理通知专用定义新的报头，作为具有其他用意所定义的报头参数之一，也可以存储这种字符串。
另外，在图20-b的示例中，在作为独自定义的Content-Type之「application/x-sip-proxy-processing」正文中，存储有表示RTP代理协作已执行的「rtp」这样的字符串(在本示例中因为已经存在SDP，所以使正文成为多部分(multipart))。即使不为处理通知专用定义新的Content-Type正文，作为具有其他用意所定义的Content-Type正文一部分，也可以存储这种字符串。
另外，除了已执行RTP代理协作的状况之外，还可以将与RTP代理协作有关的更为详细的信息(RTP代理的域名(domain name)等)存储到上述区域中。至此是RTP代理协作程序334的处理部分。
若结束了上面的处理，则调用控制程序331往SIP代理3-2传输INVITE(S607)。
若SIP代理3-2从SIP代理3-1接收到包含SDP的INVITE(S607)，则该INVITE首先被给予调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332判断SIP报文是否是请求(S101)，在是请求时，判断其是否是ACK(S102)。随后，和SIP代理3-1的情形相反，由于SIP UA2-1和SIP代理3-2属于不同的作用域(S105)，因而将路径类型设定为「开放」(S107)。由于SIP UA2-2和SIP代理3-2属于相同的作用域(S109)，因而从区域服务器4-2取得被呼叫方UA的信息(S110)。
接着，路径决定程序332判别请求的接收是经由UNI进行的还是经由NNI进行的(S117)。这里，将INVITE发送源的SIP代理3-1(其他作用域SIP代理)设定为上一跳(S120)。
由于根据S108的结果，判明被呼叫方UA是同作用域UA(SIPUA2-1)(S121)，因而路径决定程序332查验SIP代理3-2是否能够直接给SIP UA2-2发送SIP报文。这里，由于可以直接发送，因而将同作用域UA设定为下一跳(S123)。然后，作为该会话原有的信息，将路径类型、上一跳及下一跳的信息(S610)登录到会话管理表中(S126)。然后，和路径类型等不同，将从区域服务器所取得信息的高速缓存器登录到会话管理表中(S127)。路径决定程序332将如上所得到的信息，回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333和SIP代理3-1的情形相反，将「被呼叫方UA请求RTP代理协作」这样的动态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。调用控制程序331在调出RTP代理协作程序334这样的扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。
RTP代理协作程序334虽然至中途为止其进展和SIP代理3-1接收到INVITE时相同，但是因为此处由SIP代理3-1在INVITE中添加了RTP代理协作的处理通知，所以在S316中判断出有RTP代理协作的处理通知。RTP代理协作因为只要在路径上执行一次就足够，所以凭借该处理通知，可以判断出SIP代理3-2不需要进行RTP代理协作。这样一来，就防止在SIP报文的路径上扩充处理被多余地执行。
然后，在会话管理表330中记录该会话未执行RTP代理协作(S317)，并结束程序。这种未执行的记录具有可以使此后接收到与该会话有关的SIP报文(2xx或ACK等)时的计算得以简单化的效果。
若结束了上面的处理，则调用控制程序331往SIP UA2-2传输INVITE(S611)。此时，由于在SIP代理3-2中判明下一跳是同作用域UA，因而在希望不给SIP UA传送与网络方的处理有关的信息时，也可以将RTP代理协作的处理通知从INVITE中删除。
SIP UA2-2接收INVITE，并且在此设为，此后用包含SDP的200(S612)进行响应。SIP代理3-2若接收到该200，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的信息。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定为和请求时相同的类型(S113)，和请求时相反设定上一跳和下一跳(S114)，把所得到的信息(S613)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和SIP代理3-2接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。RTP代理协作程序334检查上一跳或下一跳是否是同作用域UA(S301)。在本示例中，由于上一跳是同作用域UA，因而接着检查呼叫方UA或被呼叫方UA是否请求了RTP代理协作(S302)。在本示例中，由于判明作为被呼叫方UA的SIP UA2-2请求了RTP代理协作，因而进入下面的处理。
在本示例中，由于所接收到的SIP报文是200(S304)，因而从会话管理表330取得该会话的信息(S306)。这里，SIP报文不是ACK(S307)，并且用该会话的INVITE接收到SDP(S308)，200包含有SDP(S313)。但是，由于SIP代理3-2在接收INVITE时，在会话管理表中记录有RTP代理协作的未执行(S326)，因而不用执行RTP代理协作，就结束处理。
若结束了上面的处理，则调用控制程序331往SIP代理3-1传输200(S614)。
若SIP代理3-1从SIP代理3-2接收到包含SDP的200(S614)，则该200首先被给予调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的信息。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定为和请求时相同的类型(S113)，和请求时相反设定上一跳和下一跳(S114)，把所得到的信息(S615)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和SIP代理3-1接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。RTP代理协作程序334虽然在中途之前其进展和SIP代理3-2接收到200时相同，但是因为SIP代理3-1在接收INVITE时，在会话管理表中记录有RTP代理协作的执行(S326)，因而继续执行处理。
RTP代理协作程序334和接收到INVITE时相同，对SDP的内容进行分析(S327)，向RTP代理传送端口分配请求(S328)。RTP代理5-1查看端口分配请求中包含的会话识别符(S616)，回复和前面(S605、S606)所分配的端口号码相同的端口号码，来作为响应(S617)。RTP代理协作程序334根据该端口号码来进行SDP报文的修正(S329)。
若结束了上面的处理，则SIP代理3-1往SIP UA2-1传输200(S618)。
如上所述，就可以在存在于SIP报文的路径上的SIP代理之间，唯一决定用来执行RTP代理协作的SIP代理。
借此，因为在SIP代理和RTP代理之间交换的报文120有所减少，所以SIP报文传输时的延迟时间变短。另外，因为用来中继RTP数据流110的RTP代理数目得以减少，所以声音和动态图像的延迟时间变短。而且，还有下述效果，即因为SIP报文和RTP数据流双方的处理量得以减少，所以给RTP代理带来的负荷有所减少。
实施示例2
在实施示例1中表示出，SIP报文通过跨越多个作用域的路径的示例。在这样不同作用域的SIP代理之间进行协作时，需要明确执行扩充处理的处理通知。
但是，在SIP报文通过封闭于1个作用域中的路径时，即使不在SIP代理间明确收发扩充处理的处理通知，SIP代理也可以默认获知是否已经执行扩充处理。因此，在本实施示例中，对于那种情形的动作进行说明。
图2表示在本实施示例中假定的网络物理的结构图。SIPUA2-1、SIP UA2-2和实施示例1相同。3-1、3-2是SIP代理，用来根据区域服务器4管理的信息，决定SIP报文的路径并进行传输。通信网1、SIP UA2-1、2-2、NAT装置7-1、7-2、SIP代理3-1、3-2、区域服务器4及RTP代理5相互通过物理通信线路9来连接。SIPUA2-1、2-2分别通过NAT装置7-1、7-2间接连接到通信网1上，并且SIP UA2-1、2-2可以分别只经由SIP代理3-1、3-2来收发SIP报文。另外，它们属于相同的作用域10。
作用域10只是指，区域服务器4管理的范围，并且作用域的范围并不一定根据物理的位置加以限制。但是，在附图中，为了帮助理解，使物理通信网络上的位置和作用域的范围相一致。
在实施示例2及4中，区域服务器4作为与SIP UA请求的扩充处理有关的信息，管理着「SIP UA2-1请求RTP代理协作」、「SIPUA2-2请求RTP代理协作」这样的信息。在实施示例2中，在SIPUA2-1和SIP UA2-2之间建立会话。细的实线100用来表示在SIPUA2-1和SIP UA2-2之间建立会话时的SIP报文流。这里，SIPUA2-1设为呼叫方(发送过INVITE的SIP UA)，SIP UA2-2设为被呼叫方。另外，虚线110用来表示RTP数据流。
SIP代理3(3-1、3-2)的内部结构及SIP代理3各程序的流程图，和实施示例1相同。
本实施示例的RTP代理协作程序遵照「由可以最先执行RTP代理协作的SIP代理执行RTP代理协作」这样的策略。但是，在SIP报文通过封闭于1个作用域中的路径时，也可以制作下述RTP代理协作程序，该RTP代理协作程序遵照「在可以执行RTP代理协作而且下一跳为SIP UA时，执行RTP代理协作」这样的策略等的其他策略。但是，由于在SIP报文的路径上，有可能存在因暂时故障等的原因而无法执行RTP代理协作的SIP代理，因而在故障对策这方面，最好遵照本实施示例的策略。
图17是表示在SIP UA2-1和SIP UA2-2之间建立会话时的动作一个示例的顺序图。下面，采用图17所示的顺序图及图8～13所示的流程图，来说明当SIP报文经由多个SIP代理时动态决定用来执行RTP代理协作的SIP代理之状况。
若SIP代理3-1从SIP UA2-1接收到包含SDP的INVITE(S701)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332判断SIP报文是否是请求(S101)，在是请求时，判断其是否是ACK(S102)。此时，由于请求是INVITE，因而首先将路径类型设定为「封闭」(S103)。然后，判别呼叫方UA是同作用域UA还是其他作用域UA(S104)。由于SIP UA2-1和SIP代理3-1属于相同的作用域(S105)，因而从区域服务器4取得呼叫方UA的信息(S106)。与此相同，对于被呼叫方UA，也判别是同作用域UA还是其他作用域UA(S108)。由于SIP UA2-2和SIP代理3-1属于相同的作用域(S109)，因而从区域服务器4取得被呼叫方UA的信息(S110)。
接着，路径决定程序332判别请求的接收是经由UNI进行的还是经由NNI进行的(S117)。该判别是对INVITE的发送源地址是否是作为NNI已事先登录的地址进行比较等来进行的。由于INVITE的发送源地址是SIP UA2-1，因而将呼叫方UA(同作用域UA)设定为上一跳(S119)。
虽然根据在S110中从区域服务器4所取得的信息，SIP代理3-1属于和被呼叫方UA相同的作用域(S121)，但是判明无法直接传输SIP报文(S122)。因此，路径决定程序332将可往SIP UA2-2传输INVITE的SIP代理3-2(同作用域SIP代理)设定为下一跳(S124)。随后，作为该会话原有的信息，将路径类型、上一跳及下一跳的信息(S704)登录到会话管理表中(S126)。然后，和路径类型等不同，将从区域服务器所取得信息的高速缓存器登录到会话管理表中(S127)。路径决定程序332将如上所得到的信息回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。
处理信息取得程序333从会话管理表取得属于同作用域的SIPUA信息的高速缓存器(它是在S127中登录过的)。在本实施示例中，虽然利用了高速缓存器，但是在不利用高速缓存器时，也可以在此再访问区域服务器。另外，在除区域服务器之外还存在用来存储与扩充处理有关的动态信息的专用服务器时，也可以访问该服务器。优选的是，在注重总处理能力时，要利用高速缓存器，在注重SIP代理上存储器和磁盘区域的节约时，要利用区域服务器或专用服务器。
在本示例中，由于呼叫方UA和被呼叫方UA都是同作用域UA(S201、S203)，因而取得各自的处理信息(S202、S204)。随后，从静态处理信息表取得同作用域内共同的处理信息(S205)。在实施示例2中，由于静态处理信息表337任何信息都不包含，因而不能取得任何静态信息。处理信息取得程序333将如上所得到的「呼叫方UA和被呼叫方UA请求RTP代理协作」这样的动态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。调用控制程序331在调出RTP代理协作程序334这样的扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。
RTP代理协作程序334至S315为止，其进展和实施示例1中SIP代理3-1接收到INVITE时相同。但是，在实施示例2中，由于路径类型是「封闭」，因而接着检查上一跳是否是同作用域SIP代理(S318)。这里，由于上一跳是同作用域UA(SIP UA2-1)，因而继续执行程序。至此是RTP代理协作程序334的处理条件判定部分。RTP代理协作程序334进行这种处理条件判定的原因是，为了本实施示例以外的网络结构也可以通过相同的程序来应对。
随后，RTP代理协作程序334对SDP的内容进行分析(S320)，向RTP代理传送端口分配请求(S321)。RTP代理5-1对端口分配请求中包含的会话识别符(S705)，新分配端口号码，并回复该端口号码来作为响应(S706)。RTP代理协作程序334根据该端口号码来进行SDP报文的修正(S322)。然后，在会话管理表330中记录已由该会话执行过RTP代理协作(S323)。这种执行的记录具有可以使此后接收到与该会话有关的SIP报文(2xx或ACK等)时的计算得以简单化之效果。
在此，由于路径类型是「封闭」(S324)，因而不需要将RTP代理协作的处理通知添加到SIP报文中。但是，在希望更为严格地进行SIP代理之间的协作时，也可以在路径类型为「封闭」时，仍和实施示例1相同，将RTP代理协作的处理通知添加到SIP报文中。至此是RTP代理协作程序334的处理部分。
若结束了上面的处理，则调用控制程序331往SIP代理3-2传输INVITE(S707)。
若SIP代理3-2从SIP代理3-1接收到包含SDP的INVITE(S707)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332至S118为止，其进展和本实施示例中SIP代理3-1接收到INVITE时相同。但是，SIP代理3-2为了从SIP代理3-1接收INVITE，此处将INVITE发送源的SIP代理3-1(同作用域SIP代理)设定为上一跳(S120)。
由于根据S108的结果，判明被呼叫方UA是同作用域UA(SIPUA2-2)(S121)，因而路径决定程序332查验SIP代理3-2是否能够直接给SIP UA2-2发送SIP报文。由于根据在S110中从区域服务器4所取得的信息，判明SIP代理3-2可以向SIP UA2-2直接传输SIP报文，因而将SIP UA2-2(同作用域UA)设定为下一跳(S123)。随后，作为该会话原有的信息，将路径类型、上一跳及下一跳的信息(S710)登录到会话管理表中(S126)。然后，和路径类型等不同，将从区域服务器所取得信息的高速缓存器登录到会话管理表中(S127)。路径决定程序332将如上所得到的信息回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333其进展和本实施示例中SIP代理3-1接收到INVITE时相同，并将「呼叫方UA和被呼叫方UA请求RTP代理协作」这样的动态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。调用控制程序331在调出RTP代理协作程序334这样的扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。
RTP代理协作程序334至中途为止，其进展和本实施示例中SIP代理3-1接收到INVITE时相同。但是，在路径类型为「封闭」(S315)且上一跳为同作用域SIP代理时(S318)，默认判明上一跳的SIP代理已经执行RTP代理协作。RTP代理协作因为只要在路径上执行一次就足够，所以可以判断出SIP代理3-2不需要进行RTP代理协作。这样一来，在SIP报文通过封闭于1个作用域中的路径时，还防止在SIP报文的路径上扩充处理被多余执行。然后，在会话管理表330中记录该会话未执行RTP代理协作(S319)，并结束程序。
但是，在希望更为严格地进行SIP代理之间的协作时，在路径类型为「封闭」时，也可以在没有RTP代理协作的处理通知时执行RTP代理协作。
若结束了上面的处理，则调用控制程序331往SIP UA2-2传输INVITE(S711)。此时，由于在SIP代理3-2中判明下一跳是同作用域UA，因而也可以将RTP代理协作的处理通知从INVITE中删除，以便不向SIP UA传输与网络方的处理有关的信息。
SIP UA2-2接收INVITE，并且此处设为，此后用包含SDP的200(S712)进行响应。SIP代理3-2若接收到该200，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的报文。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定成和请求时相同的类型(S113)，和请求时相反地设定上一跳和下一跳(S114)，把所得到的信息(S713)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和本实施示例中SIP代理3-2接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。但是，由于SIP代理3-2在接收INVITE时，在会话管理表中记录有RTP代理协作的未执行，因而不执行RTP代理协作，就结束处理(S326)。若结束了上面的处理，则调用控制程序331往SIP代理3-1传输200(S714)。
若SIP代理3-1从SIP代理3-2接收到包含SDP的200(S714)，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的信息。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定成和请求时相同的类型(S113)，和请求时相反设定上一跳和下一跳(S114)，把所得到的信息(S715)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和本实施示例中SIP代理3-1接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。但是，由于SIP代理3-1在接收INVITE时，在会话管理表中记录有RTP代理协作的执行(S326)，因而继续执行处理。
RTP代理协作程序334和接收到INVITE时相同，对SDP的内容进行分析(S327)，向RTP代理传送端口分配请求(S328)。RTP代理5-1查看端口分配请求中包含的会话识别符(S716)，并回复和前面(S705、706)所分配的端口号码相同的端口号码，来作为响应(S717)。RTP代理协作程序334根据该端口号码，来进行SDP报文的修正(S329)。
若结束了上面的处理，则SIP代理3-1往SIP UA2-1传输200(S718)。
如上所述，在SIP报文通过封闭于1个作用域中的路径时，即使不进行扩充处理的处理通知，也可以唯一决定用来执行RTP代理协作的SIP代理。
借此，由于在SIP代理和RTP代理之间交换的报文120得以减少，因而SIP报文传输时的延迟时间变短。另外，由于用来中继RTP数据流110的RTP代理数目得以减少，因而声音和动态图像的延迟时间变短。而且，还有下述效果，即由于SIP报文和RTP数据流双方的处理量得以减少，因而给RTP代理带来的负荷有所减少。
另外，和实施示例1不同，在如同本实施示例这样在单个作用域内采取冗余结构(redundant configuration)时，不需要向原来调用控制协议(此时是SIP)的扩充。
还可以考虑在1个作用域之中只有1个RTP代理的情况，此时也有可以减少在SIP代理和RTP代理之间交换的报文120之效果。
实施示例3
在实施示例1和2中表示出，SIP代理执行作为扩充处理一种的RTP代理协作的示例。在本实施示例中，作为扩充处理不同的示例，将对于执行SIP代理-呈现服务器间协作(SIP proxy-presence serverinteraction)(下面，为呈现服务器协作(presence server interaction))时的动作，进行说明。在本实施示例中称为呈现服务器协作的处理为，若在SIP UA间建立了会话，则SIP代理将双方SIP UA的状态更新为「通话中(Busy)」，并且若结束了会话，则更新为「可通话(Online)」。
另外，在本实施示例及实施示例4中，其前提为，区域服务器的作用域及呈现服务器管理的SIP UA和SIP代理的范围相一致。
图3表示在本实施示例中假定的网络物理结构图。SIP UA2-1、2-2和实施示例1相同。3-1、3-2是SIP代理，用来根据区域服务器4管理的信息，决定SIP报文的路径并进行传输。通信网1、SIPUA2-1、2-2、SIP代理3-1、3-2、区域服务器4及呈现服务器6相互通过物理通信线路9来连接。因为维持着TLS(Transport LayerSecurity)等的安全连接这样的理由，SIP UA2-1、2-2可以分别只经由SIP代理3-1、3-2来收发SIP报文。但是，本实施示例并不限定为该理由，在SIP报文通过相同的路径时，进行同样的处理。
另外，它们属于相同的作用域10。作用域10只是指，区域服务器4管理的范围，作用域的范围并不一定根据物理的位置加以限制。但是，在附图中，为了帮助理解，使物理通信网络上的位置和作用域的范围相一致。
在实施示例3中，在SIP UA2-1和SIP UA2-2之间建立会话。较细的实线100用来表示在SIP UA2-1和SIP UA2-2之间建立会话时的SIP报文流。在此，SIP UA2-1设为呼叫方(发送过INVITE的SIP UA)，SIP UA2-2设为被呼叫方。
图6表示，将图3所示的SIP代理3(SIP代理3-1、SIP代理3-2共同)的内部结构在功能上展开所示的框图。除了取代RTP代理协作程序334而在存储器33中存储有呈现服务器协作程序335这一点之外，和实施示例1的SIP代理3的内部结构(图5)相同。
另外，除了呈现服务器协作程序335之外的各程序流程图，和实施示例1相同。
呈现服务器协作程序335是进行扩充处理的程序一种，用来获取路径决定程序332和处理信息取得程序333的计算结果，并且只在满足特定条件时，才执行呈现服务器协作。在本实施示例及实施示例4中，通过从SIP代理3对呈现服务器6发送SIP报文的PUBLISH，来更新SIP UA。但是，更新SIP UA状态的方法不限定为PUBLISH。
本实施示例及实施示例4的呈现服务器协作程序335遵照「由可以最先执行呈现服务器协作的SIP代理执行呈现服务器协作」这样的策略。但是，在SIP报文通过封闭于1个作用域中的路径时，也可以制作下述呈现服务器协作程序，该呈现服务器协作程序遵照「在可以执行呈现服务器协作而且下一跳为SIP UA时，执行呈现服务器协作」这样的策略等的其他策略。但是，由于在SIP报文的路径上，有可能存在因暂时故障等的原因而无法执行呈现服务器协作的SIP代理，因而在故障对策这方面，最好遵照本实施示例及实施示例4的策略。
另外，在本实施示例及实施示例4中，在静态处理信息表337中存储有「全部的同作用域UA请求呈现服务器协作」这样的信息。虽然在只有一部分UA请求呈现服务器协作时，需要在静态处理信息表337中存储那种信息，但是此时也和本实施示例相同，可以由呈现服务器协作程序335来应对。
图18是表示在SIP UA2-1和SIP UA2-2之间建立会话时的动作一个示例的顺序图。下面，采用图18所示的顺序图及图8～10、图14～15所示的流程图，来说明当SIP报文经由多个SIP代理时动态决定用来执行呈现服务器协作的SIP代理之状况。
若SIP代理3-1从SIP UA2-1接收到包含SDP的INVITE(S801)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-1接收到INVITE时完全相同。然后，将如上所得到的信息(S804)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。
处理信息取得程序333从会话管理表取得属于同作用域的SIPUA信息的高速缓存器(它是在S127中登录过的)。在本实施示例中，虽然利用了高速缓存器，但是在不利用高速缓存器时，也可以在此再访问区域服务器。另外，在除区域服务器之外还存在用来存储与扩充处理有关的动态信息的专用服务器时，也可以访问该服务器。优选的是，在注重总处理能力时，要利用高速缓存器，在注重SIP代理上存储器和磁盘区域的节约时，要利用区域服务器或专用服务器。
在本示例中，由于呼叫方UA和被呼叫方UA都是同作用域UA(S201、S203)，因而取得各自的处理信息(S202、S204)。在本实施示例中，由于不存在基于动态信息的扩充处理(RTP代理协作等)，因而不能取得任何动态信息。随后，从静态处理信息表取得同作用域内共同的处理信息(S205)。处理信息取得程序333将如上所得到的「全部的同作用域UA请求呈现服务器协作」这样的静态信息，回复给调用控制程序331。
然后，调用控制程序331调出呈现服务器协作程序335。调用控制程序331在调出呈现服务器协作程序335这样的扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。
呈现服务器协作程序335检查上一跳或下一跳是否是同作用域UA(S401)。在本示例中，由于双方都是同作用域UA，因而接着检查静态处理信息是否请求了呈现服务器协作(S402)。在本示例中，由于根据在S205中从静态处理信息表337所取得的信息，判明作为同域UA的呼叫方UA和被呼叫方UA请求了呈现服务器协作，因而进行下面的处理。
但是，在本示例中，由于SIP报文是INVITE，因而在S403和S413的检查之后，结束处理。和从会话的建立中执行的RTP代理协作不同，呈现服务器协作在会话建立后加以执行。
若结束了上面的处理，则调用控制程序331往SIP代理3-2传输INVITE(S805)。
若SIP代理3-2从SIP代理3-1接收到包含SDP的INVITE(S805)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-1接收到INVITE时完全相同。然后，将如上所得到的信息(S808)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333的进展为，和本实施示例中SIP代理3-1接收到INVITE时相同，并且将「全部的同作用域UA请求呈现服务器协作」这样的信息，回复给调用控制程序331。
然后，调用控制程序331调出呈现服务器协作程序335。调用控制程序331在调出呈现服务器协作程序335这样的扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。
呈现服务器协作程序335的进展，和本实施示例中SIP代理3-1接收到INVITE时相同，在执行呈现服务器协作之前，结束处理。
若结束了上面的处理，则调用控制程序331往SIP UA2-2传输INVITE(S809)。
SIP UA2-2接收INVITE，并且此处设为，此后用包含SDP的200(S810)进行响应。SIP代理3-2若接收到该200，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的信息。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定成和请求时相同的类型(S113)，和请求时相反设定上一跳和下一跳(S114)，把所得到的信息(S811)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和在本实施示例中SIP代理3-2接收到INVITE时相同的信息，回复给调用控制程序331。然后，调用控制程序331调出呈现服务器协作程序335。
呈现服务器协作程序335检查上一跳或下一跳是否是同作用域UA(S401)。在本示例中，由于双方都是同作用域UA，因而接着检查静态处理信息是否请求了呈现服务器协作(S402)。在本示例中，由于根据在S205中从静态处理信息表337所取得的信息，判明作为同作用域UA的呼叫方UA和被呼叫方UA请求了呈现服务器协作，因而进行下面的处理。
在本示例中，由于所接收到的SIP报文是200(S403)，因而从会话管理表取得该会话的信息。而且，所接收到的SIP报文是200(S405)，该会话的INVITE包含SDP(S406)，并且SIP报文(此处所说的200)也包含SDP(S407)。因此，接着检查路径类型是否是「封闭」(S414)。这里，虽然路径类型是「封闭」，但是由于上一跳是同作用域UA(SIP UA2-2)(S415)，因而继续执行处理。至此是呈现服务器协作程序335的处理条件判定部分。呈现服务器协作程序335进行这种处理条件判定的原因为，为了本实施示例以外的网络结构也可以通过相同的程序来应对。
此后，呈现服务器协作程序335分别判定呼叫方UA和被呼叫方UA是否是同作用域UA(S416、S420)，并且因为是同作用域UA，所以将状态更新为「通话中」(S418、S422)。和RTP代理协作不同，由于呈现服务器协作通过一次处理就结束，因而不需要在会话管理表中记录呈现服务器协作的执行。
在本实施示例及实施示例4中，有区域服务器4的作用域及呈现服务器管理的SIP UA和SIP代理的范围相一致这样的前提条件。也就是说，由于为每个作用域执行1次呈现服务器协作，因而不需要在属于不同作用域的SIP代理间收发呈现服务器协作的处理通知。但是，在希望更为严格地进行SIP代理之间的协作时，也可以只在路径类型为「封闭」时，采用和RTP代理协作的处理通知相同的方法，将呈现服务器协作的处理通知添加到SIP报文中。至此是呈现服务器协作程序335的处理部分。
若结束了上面的处理，则调用控制程序331往SIP代理3-1传输200(S814)。
若SIP代理3-1从SIP代理3-2接收到包含SDP的200(S814)，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332在SIP报文是响应时，利用请求时的信息。首先，从会话管理表取得该会话请求时的路径类型、上一跳及下一跳(S112)。然后，将路径类型设定成和请求时相同的类型(S113)，和请求时相反地设定上一跳和下一跳(S114)，把所得到的信息(S815)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和在本实施示例中SIP代理3-1接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334。RTP代理协作程序334虽然至中途为止，其进展和SIP代理3-2接收到200时相同，但是在路径类型为「封闭」(S414)且上一跳为同作用域SIP代理时(S415)，由于默认获知上一跳的SIP代理已经执行了呈现服务器协作，因而结束程序。
但是，在希望更为严格地进行SIP代理之间的协作时，也可以在路径类型为「封闭」时，在没有呈现服务器协作的处理通知时执行呈现服务器协作。
若结束了上面的处理，则调用控制程序331往SIP UA2-1传输INVITE(S816)。
如上所述，对于作为RTP代理协作之外的扩充处理的呈现服务器协作，也可以通过添加由处理条件判定部分和处理部分组成的程序，来唯一决定用来执行其扩充处理的SIP代理。
借此，因为SIP代理和呈现服务器之间交换的报文130得以减少，所以SIP报文传输时的延迟时间变短。另外，还有下述效果，即因为SIP报文的处理量得以减少，所以给呈现服务器带来的负荷有所减少。
另外，和实施示例1不同，在如同本实施示例这样于单个作用域内采取冗余结构的范围内，不需要对原来调用控制协议(此时是SIP)进行扩充。
实施示例4
在实施示例1～3中表示出，SIP代理执行单个扩充处理的示例。在本实施示例中，将对于SIP代理执行多个扩充处理时的动作，进行说明。在本实施示例中，执行2个扩充处理，一个是实施示例1和2所示的RTP代理协作，另一个是实施示例3所示的呈现服务器协作。
图4表示在本实施示例中假定的网络物理结构图。除了RTP代理5以及呈现服务器6通过物理通信线路9连接到通信网1上这一点之外，和实施示例2的结构图(图2)相同。
图7表示，将图4所示的SIP代理3(SIP代理3-1、SIP代理3-2共同)的内部结构在功能上展开所示的框图。除了RTP代理协作程序334以及呈现服务器协作程序335存储于存储器33中这一点之外，和实施示例1的SIP代理3的内部结构(图5)相同。
另外，除呈现服务器协作程序335之外的各程序流程图，和实施示例1相同，并且呈现服务器协作程序335的流程图，和实施示例3相同。在静态处理信息表337中存储有和实施示例3相同的信息。
图19是表示在SIP UA2-1和SIP UA2-2之间建立会话时的动作一个示例的顺序图。下面，采用图19所示的顺序图及图8～15所示的流程图，来说明当SIP报文经由多个SIP代理时分别动态决定用来执行RTP代理协作和呈现服务器协作的SIP代理之状况。
若SIP代理3-1从SIP UA2-1接收到包含SDP的INVITE(S901)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-1接收到INVITE时完全相同。然后，将如上所得到的信息(S904)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。
处理信息取得程序333从会话管理表取得属于同作用域的SIPUA信息的高速缓存器(cache)(它是在S127中登录过的)。在本实施示例中，虽然利用了高速缓存器，但是在不利用高速缓存器时，也可以在此再访问区域服务器。另外，在除区域服务器之外还存在用来存储与扩充处理有关的动态信息的专用服务器时，也可以访问该服务器。优选的是，在注重总处理能力时，要利用高速缓存器，在注重SIP代理上存储器和磁盘区域的节约时，要利用区域服务器或专用服务器。
在本示例中，由于呼叫方UA和被呼叫方UA都是同作用域UA(S201、S203)，因而取得各自的处理信息(S202、S204)。随后，从静态处理信息表取得同作用域内共同的处理信息(S205)。处理信息取得程序333将如上所得到的「呼叫方UA和被呼叫方UA请求RTP代理协作」这样的动态信息和「全部的同作用域UA请求呈现服务器协作」这样的静态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334和呈现服务器协作程序335。调用控制程序331在调出这些扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。即便变更了调出这些扩充处理程序的顺序，整体的处理结果也没有改变。
RTP代理协作程序334的动作为，和实施示例2中SIP代理3-1接收到INVITE时完全相同，并且执行RTP代理协作。然后，在会话管理表330中记录已由该会话执行了RTP代理协作(S323)，并结束程序。
呈现服务器协作程序335的动作为，和实施示例3中SIP代理3-1接收到INVITE时完全相同，并且不执行呈现服务器协作，就结束程序。
若结束了上面的处理，则调用控制程序331往SIP代理3-2传输INVITE(S907)。
若SIP代理3-2从SIP代理3-1接收到包含SDP的INVITE(S907)，则该INVITE首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-1接收到INVITE时完全相同。然后，将如上所得到的信息(S910)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。
处理信息取得程序333的进展为，和本实施示例中SIP代理3-1接收到INVITE时相同，并且将「呼叫方UA和被呼叫方UA请求RTP代理协作」这样的动态信息和「全部的同作用域UA请求呈现服务器协作」这样的静态信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334和呈现服务器协作程序335。调用控制程序331在调出这些扩充处理程序时，提交从路径决定程序332和处理信息取得程序333获取到的计算结果。即便变更了调出这些扩充处理程序的顺序，整体的处理结果也没有改变。
RTP代理协作程序334的动作为，和实施示例2中SIP代理3-2接收到INVITE时完全相同，并且不执行RTP代理协作。然后，在会话管理表330中记录未由该会话执行RTP代理协作(S319)，并结束程序。
呈现服务器协作程序335的动作为，和实施示例3中SIP代理3-2接收到INVITE时完全相同，并且不执行呈现服务器协作，就结束程序。
若结束了上面的处理，则调用控制程序331往SIP UA2-2传输INVITE(S911)。
SIP UA2-2接收INVITE，并且此处设为，此后用包含SDP的200(S912)进行响应。SIP代理3-2若接收到该200，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-2接收到200时完全相同。然后，将如上所得到的信息(S913)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和在本实施示例中SIP代理3-2接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334和呈现服务器协作程序335。
RTP代理协作程序334的动作为，和实施示例2中SIP代理3-2接收到200时完全相同，并且不执行RTP代理协作，就结束程序。
呈现服务器协作程序335的动作为，和实施示例3中SIP代理3-2接收到200时完全相同，并且执行呈现服务器协作。然后，结束程序。
若结束了上面的处理，则调用控制程序331往SIP代理3-1传输200(S916)。
若SIP代理3-1从SIP代理3-2接收到包含SDP的200(S916)，则该200首先被交给调用控制程序331。然后，调用控制程序331在其处理之中调出路径决定程序332。
路径决定程序332的动作为，和实施示例2中SIP代理3-1接收到200时完全相同。然后，将如上所得到的信息(S917)回复给调用控制程序331。
若结束了路径决定程序332，则调用控制程序331接着调出处理信息取得程序333。处理信息取得程序333将和在本实施示例中SIP代理3-1接收到INVITE时相同的信息，回复给调用控制程序331。
然后，调用控制程序331调出RTP代理协作程序334和呈现服务器协作程序335。
RTP代理协作程序334的动作为，和实施示例2中SIP代理3-1接收到200时完全相同，并且执行RTP代理协作。然后，结束程序。
呈现服务器协作程序335的动作为，和实施示例3中SIP代理3-1接收到200时完全相同，并且不执行呈现服务器协作，就结束程序。
若结束了上面的处理，则调用控制程序331往SIP UA2-1传输INVITE(S920)。
如上所述，对于有多个SIP代理执行的扩充处理的场合，也可以唯一决定用来执行其各自扩充处理的SIP代理。另外，还表示出，由于处理条件的判定对每个扩充处理都执行，因而1个SIP代理未必执行全部的扩充处理。
借此，由于SIP代理和外部服务器(RTP代理、呈现服务器)之间交换的报文得以减少，因而SIP报文传输时的延迟时间变短。还有下述效果，即由于从SIP代理发送的报文处理量得以减少，因而给外部服务器带来的负荷有所减少。
另外，和实施示例1不同，在如同本实施示例这样在单个作用域内采取冗余结构的范围内，不需要向原来调用控制协议(此时是SIP)的扩充处理。而且，由于其结构为，将路径决定程序332和处理信息取得程序333的计算结果，交给各自的扩充处理程序，因而不用对SIP代理的基本程序(调用控制程序331、路径决定程序332及处理信息取得程序333)施加变更，也可以新添加实施示例4所示的程序之外的扩充处理程序。作为除RTP代理协作和呈现服务器协作之外要考虑的扩充处理程序，有和Web服务器之间的协作、注册的记录、收费信息的记录及QoS控制等。
上面，对于本发明的实施方式，参照附图进行了详细说明，但是具体的结构并不限于该实施方式，还包括不脱离本发明宗旨的范围的设计等。另外，只要产生本发明的效果，协议就不限定为SIP。
符号说明
1 通信网
2 SIP UA
3 SIP代理
4 区域服务器
5 RTP代理
6 呈现服务器
7 NAT装置
8 SIP服务器
9 通信线路
10 作用域
100 SIP报文
110 RTP数据流
120 SIP代理-RTP代理间协作报文
130 SIP代理-呈现服务器间协作报文
31 IF
32 CPU
33 存储器
34 数据通路
330 会话管理表
331 调用控制程序
332 路径决定程序
333 处理信息取得程序
334 RTP代理协作程序
335 呈现服务器协作程序
337 静态处理信息表。

Claims (5)

1.一种会话中继装置，与通信终端和其他会话中继装置连接，其特征为，
具有：
收发部，从上述通信终端或上述会话中继装置接收呼叫控制报文；
控制部，根据上述呼叫控制报文所通过的路径上本装置的位置信息和有关需要上述呼叫控制报文所属的会话的处理的信息，来决定是否由本装置执行上述处理。
2.根据权利要求1所述的会话中继装置，其特征为：
上述收发部发送附加下述信息后的上述呼叫控制报文，该信息为是否由本装置执行了需要上述呼叫控制报文所属的会话的处理的信息。
3.根据权利要求1所述的会话中继装置，其特征为：
需要上述呼叫控制报文所属的会话的处理是2个或更多个独立的处理。
4.根据权利要求1所述的会话中继装置，其特征为：
具备存储部，
在上述存储部中，存储有：
程序1，取得上述呼叫控制报文所通过的路径上本装置的位置信息；
程序2，取得与需要上述呼叫控制报文所属的会话的处理有关的信息；
程序3，根据上述呼叫控制报文所通过的路径上本装置的位置信息、和有关需要上述呼叫控制报文所属的会话的处理的信息，来决定是否由本装置执行上述处理；
上述控制部执行上述存储部中所存储的各程序。
5.根据权利要求4所述的会话中继装置，其特征为，
决定是否由本装置执行上述处理的程序可以对上述每个处理进行追加或删除。
CN2005101357661A 2005-03-14 2005-12-28 会话中继装置 Expired - Fee Related CN1835505B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005070239A JP4487810B2 (ja) 2005-03-14 2005-03-14 セッション中継装置
JP070239/2005 2005-03-14

Publications (2)

Publication Number Publication Date
CN1835505A true CN1835505A (zh) 2006-09-20
CN1835505B CN1835505B (zh) 2011-11-30

Family

ID=36970830

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2005101357661A Expired - Fee Related CN1835505B (zh) 2005-03-14 2005-12-28 会话中继装置

Country Status (3)

Country Link
US (1) US7764668B2 (zh)
JP (1) JP4487810B2 (zh)
CN (1) CN1835505B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102355638A (zh) * 2008-06-07 2012-02-15 华为技术有限公司 呼叫处理方法及装置

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8184641B2 (en) * 2005-07-20 2012-05-22 Verizon Business Global Llc Method and system for providing secure communications between proxy servers in support of interdomain traversal
KR100810759B1 (ko) * 2006-02-17 2008-03-07 엔에이치엔(주) Ｐ2ｐ 파일 전송 시스템 및 방법
US20070253340A1 (en) * 2006-04-28 2007-11-01 Lucent Technologies Inc. Method and apparatus for selective presence notification
US20080076422A1 (en) * 2006-09-09 2008-03-27 Jeou-Kai Lin System and method for providing continuous media messaging during a handoff procedure in an IP-based mobile communication network
WO2008080225A1 (en) * 2006-12-29 2008-07-10 Natural Convergence Inc. Method and system for network address translation (nat) traversal of real time protocol (rtp) media
US7991904B2 (en) 2007-07-10 2011-08-02 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
US7987285B2 (en) 2007-07-10 2011-07-26 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
JP2009021855A (ja) * 2007-07-12 2009-01-29 Toshiba Corp 中継装置、通信方法及び通信プログラム
US8775665B2 (en) * 2009-02-09 2014-07-08 Citrix Systems, Inc. Method for controlling download rate of real-time streaming as needed by media player
JP5331655B2 (ja) * 2009-11-13 2013-10-30 株式会社日立製作所 通信システム、制御サーバ
US9392121B2 (en) 2010-09-20 2016-07-12 International Business Machines Corporation Seamlessly conferencing a previously-connected telephone call
KR101263783B1 (ko) * 2010-12-27 2013-05-13 삼성에스디에스 주식회사 릴레이 서버를 이용한 데이터 전송 시스템 및 방법
CN103828324B (zh) 2011-06-10 2017-11-28 茨特里克斯系统公司 用于自适应比特率管理的方法、设备和系统
US9288251B2 (en) 2011-06-10 2016-03-15 Citrix Systems, Inc. Adaptive bitrate management on progressive download with indexed media files
US9143722B2 (en) * 2011-11-22 2015-09-22 Cisco Technology, Inc. Method and apparatus for providing session description for a media session
US9306991B2 (en) 2012-10-16 2016-04-05 Motorola Solutions, Inc. Enhanced push to talk systems and methods with floor control and media traffic optimization
US9510160B2 (en) 2012-10-31 2016-11-29 Motorola Solutions, Inc. Enhanced network-network interface systems and methods for multimedia broadcast multicast services
US10069871B2 (en) * 2016-02-01 2018-09-04 Verizon Patent And Licensing Inc. Measuring session initiation protocol (SIP) messaging latency

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6252952B1 (en) * 1999-12-30 2001-06-26 At&T Corp Personal user network (closed user network) PUN/CUN
US6826173B1 (en) * 1999-12-30 2004-11-30 At&T Corp. Enhanced subscriber IP alerting
US7283519B2 (en) * 2001-04-13 2007-10-16 Esn, Llc Distributed edge switching system for voice-over-packet multiservice network
US7386000B2 (en) * 2001-04-17 2008-06-10 Nokia Corporation Packet mode speech communication
US7984174B2 (en) * 2002-11-11 2011-07-19 Supracomm, Tm Inc. Multicast videoconferencing
US7028101B2 (en) * 2003-03-25 2006-04-11 Nokia Corporation Optimal location service for managing next hop addressing for messages associated with multiple address schemes
CN100399768C (zh) * 2003-12-24 2008-07-02 华为技术有限公司 实现网络地址转换穿越的方法、系统
US7983254B2 (en) * 2005-07-20 2011-07-19 Verizon Business Global Llc Method and system for securing real-time media streams in support of interdomain traversal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102355638A (zh) * 2008-06-07 2012-02-15 华为技术有限公司 呼叫处理方法及装置

Also Published As

Publication number Publication date
US20060203831A1 (en) 2006-09-14
JP2006254253A (ja) 2006-09-21
JP4487810B2 (ja) 2010-06-23
US7764668B2 (en) 2010-07-27
CN1835505B (zh) 2011-11-30

Similar Documents

Publication Publication Date Title
CN1835505A (zh) 会话中继装置
CN1711784A (zh) 用于发送sms以及文本消息的系统和方法
CN101060464A (zh) 地址变换装置、消息处理方法及网络系统
CN101039247A (zh) 一种点到点网络系统及重叠网间节点的互通方法
CN100343835C (zh) 信息处理方法和设备
CN101064866A (zh) 一种短信的路由寻址方法及系统
CN1750543A (zh) 服务器负载平衡系统、装置以及内容管理装置
CN1661990A (zh) 协议版本转换器
CN1615635A (zh) 移动节点,路由器,服务器和根据ip版本6(ipv6)协议的移动通信的方法
CN1859393A (zh) 一种协商设备信息的系统及方法
CN1575466A (zh) 存在管理的实现
CN1679004A (zh) 高速缓存设备、高速缓存数据管理方法和计算机程序
CN1853384A (zh) 移动通信方法、移动通信装置、归属代理装置、访问路由器信息服务器装置以及移动通信系统
CN101031918A (zh) 节点设备、共享信息更新方法、共享信息存储方法以及程序
CN1878375A (zh) 终端设备软件/固件下载更新方法
CN1905720A (zh) 传送移动电信网中与至少一个移动终端相关的信息的方法
CN1801231A (zh) 紧急通报系统和紧急通报方法
CN101064960A (zh) 一种对语音呼叫连续锚定进行优化的方法、系统及装置
CN1889771A (zh) 一种hlr以及将传统移动终端接入ims域的方法及系统
CN1870639A (zh) 初始会话协议消息编码能力的协商方法及装置
CN101047630A (zh) 实现短消息业务的系统和上发以及下发短消息的方法
CN1870777A (zh) 一种选择被叫路由的方法、网络及设备
CN101032134A (zh) 通信系统、移动终端和验证服务器
CN1859392A (zh) 业务编址方法、系统及其应用
CN1949752A (zh) 一种电路交换网与ip多媒体子系统网络互通的系统和方法

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: 20111130

Termination date: 20131228