在网络中的加密通信方法中，为了防止与相互无意向的对方装置进行通信，客户机和服务器都对对方装置执行认证过程，在对方装置的认证成功时，才交换在通信中使用的加密参数。在IETF(Intemet EngineeringTask Force即，互联网工程技术特别小组)的RFC2401“SecurityArchitecture for the Internet Protocol”(非专利文献1)中记述的IPsec(Internet Protocol Security即，IP安全协议网际协议)和RFC2246“TheTls Protocol Version 1.0”(非专利文献2)中记述的TLS(Transport LayerSecurity，即传输层安全)中，在通信对象的认证中适用公开密钥证明书。
在使用了公开密钥证明书的认证中，需要用某种方法验证通信对象所提示的公开密钥证明书是从可信赖的认证局发行的。作为公开密钥证明书的验证方法之一，例如，有事先用某种方法得到用于证明通信对象所提示的公开密钥证明书的发行源认证局的具有可靠性的认证局root证明书，在通信对象的认证过程中，利用认证局的root证明书的公开密钥验证在对方装置所提示的公开密钥证明书中提供的认证局署名的方法。根据该验证方法，服务器和客户机需要对应于成为通信对象的全部通信装置的公开密钥证明书，事先准备各公开密钥证明书的发行源认证局的root证明书。
例如，如图1所示，设想多个客户机(终端装置)CL1、CL2、CL3分别持有发行源(CA1、CA2、CA3)的不同的秘密密钥SK1、SK2、SK3和公开密钥证明书PK1、PK2、PK3，服务器SV1、SV2、SV3也分别持有发行源(CA1、CA2、CA3)的不同的秘密密钥SK11、SK12、SK13和公开密钥证明书PK11、PK12、PK13的系统。在此，各客户机为了能够随时与多个服务器SV1、SV2、SV3进行通信，如图所示，需要与成为通信对象的全部的客户机装置CL1、CL2、CL3所持的公开密钥证明书(PK1、PK2、PK3)的发行源认证局(CA1、CA2、CA3)相对应，使各服务器事先持有多个root证明书RT1、RT2、RT3。同样地，也需要在各客户机中，与成为通信对象的服务器SV1、SV2、SV3所持的公开密钥证明书(PK11、PK12、PK13)的发行源认证局(CA1、CA2、CA3)相对应，事先准备多个root证明书RT1、RT2、RT3。此外，在该系统结构中，各客户机装置和服务器需要在改变通信对象时，每次都反复进行认证处理。
图2示出为了利用上述RFC2401中记述的IPsec进行加密通信而客户机所具有的软件的基本方框结构。
在此，20示出了网络接口卡(NIC)部，30示出了TCP/IP层，40示出了应用层的软件部，50示出了RFC2409“The Internet Key Exchange(IKE)”(非专利文献3)中记述的密钥管理(IKE：Internet Key Exchange)过程用的软件部。作为TCP/IP层的软件的一部分，装备有IPsec引擎31，该IPsec引擎31具有存储了是否在发送包中适用加密的判定信息(SP信息)的SPDB(Security Policy Data Base即，安全策略数据库)32、和存储了在加密通信中适用的加密方式或密码密钥等信息(SA信息)的SADB(Security Association Data Base即，安全检查数据库)33。
成为上述客户机的通信对象的服务器也具有与图2同样的软件，客户机与服务器的应用层彼此之间、密钥管理过程彼此之间就能相互进行通信。
IPsec引擎31一检测出应用层40的程序所发行的IP包的发送请求，就用SPDB32验证该IP包的报头信息，判定该IP包中是否应该适用IPsec。判断为在IP包中适用IPsec的IPsec引擎31，从SADB33取得应该在IP包中适用的SA(Security Association)信息。在此，若SADB33中没登记与上述IP包相对应的SA信息的情况下，IPsec引擎31就对IKE(密钥管理)过程50请求进行包含与通信对象(连接目的地服务器)之间的密码密钥的SA信息的交换。
IKE过程50按照RFC2408“Internet Security Association and keyManagement Protocol(ISAKMP)”(非专利文献4)中记载的ISAKMP(Internet Security Association and key Management Protocol)，与通信对象交换SA信息。在ISAKMP中，在与通信对象之间形成了加密通信路径之后，执行用于确认对方装置是否是容许通信的真正的装置。IKE过程50按照上述认证过程，一确认对方装置是容许加密通信的真正的装置，就通过由ISAKMP设定的通信路径，开始与对方装置进行SA信息的交换。当与对方装置的SA信息的交换结束时，IKE过程50就向IPsec引擎31通知SA信息和与其相对应的SP(Security Policy)信息。
IPsec引擎31分别在SPDB32和SADB33中存储了从IKE过程50通知的SP信息和SA信息之后，按照上述SA信息，将IP包加密后发送给通信对象。在成为通信对象的服务器侧，一接收上述加密后的IP包，就按照由IKE过程同意的SA信息加密接收IP包，向服务器侧应用层通知接收IP包。
另一方面，在RFC3261“SIP：Session Initiation Protocol”(非专利文献5)中，记载了利用TLS(Transport Layer Security：安全传输层协议)进行客户机(用户代理程序客户机)与对话管理服务器即SIP(SessionInitiation Protocol，即会话初始协议)代理服务器之间、和SIP代理服务器与服务器(用户代理程序服务器)之间的相互认证，客户机与SIP代理服务器、和SIP代理服务器与服务器进行加密通信的方法。根据RFC3261的SIP模式，客户机和服务器分别利用SIP代理服务器确认了是真正的通信对象，并且，由于在客户机与服务器之间收发加密的SIP报文，因此，除了客户机、服务器、SIP代理服务器以外的其他装置，就很难接收上述客户机与服务器之间的通信内容。
SIP是基于文本的协议，SIP报文由报头部和表示对话内容的报文正文部构成。关于SIP，在RFC3263“Session Initiation Protocol(SIP)：Locating SIP Servers”(非专利文献6)中进行了记述。此外，在RFC2327“SDP：Session Description Protocol”(非专利文献7)中公开了对话描述中适用的SDP(Session Description Protocol)、和在客户机与服务器之间交换的加密参数的记述方法。SIP模式的客户机和服务器能够分别通过形成在与SIP代理服务器之间的密码通信路径，在利用SIP报文交换了对话描述和加密参数之后，适用上述加密参数来通信加密包。
图3示出适用了上述的SIP代理服务器的认证系统的一例。在此，PR表示与多个客户机CL1、CL2、CL3和多个服务器SV1、SV2、SV3连接的SIP代理服务器。SIP代理服务器PR使用认证局CA4发行的秘密密钥SK30和公开密钥证明书PK30，为了认证服务器SV1、SV2、SV3，预先持有与这些用户使用的公开密钥证明书的发行源认证局(CA1、CA2、CA3)相对应的多个root证明书RT1、RT2、RT3。
在适用了SIP代理服务器的认证系统中，各服务器和客户机如图3所示，可以仅持有与SIP代理服务器PR使用的公开密钥证明书PK30的发行源认证局相对应的root证明书RT4，作为用于认证通信对象的root证明书。此外，各客户机在通过SIP代理服务器PR与一个服务器通信后、将连接目的地变更为另外的服务器的情况下，能够在与SIP代理服务器之间使用已经构筑的密码通信路径进行通信，因此，只要与新的通信对象之间交换加密参数，就能开始加密通信。即，在适用了SIP代理服务器的认证系统中，对于各客户机来说，具有每次变更连接目的地服务器时不需要重新进行认证处理的优点。
然而，在SIP的框架中，对话管理服务器(SIP代理服务器)利用具有被称作AOR(Address-Of-Record)的“用户名@域名”形式的标识符(SIP-URI)，决定接收SIP报文的传送目的地。从而，在以经由如上述的SIP代理服务器这样的对话管理服务器的对话设定为前提的网络系统中，在客户机上执行的应用程序就需要使用能确定服务器所属域的SIP-URI(Uniform Resource Identifier即，统一资源标识符)，作为用于指定连接目的地服务器的标识符。
更详细地说，在SIP的框架中，在客户机侧生成记述了指定连接目的地服务器的AOR形式的SIP-URI的连接请求SIP报文，作为包含在起始行中的Request-URI，将在有效负荷中包含该SIP报文的IP包发送给位于客户机的所属域中的SIP代理服务器。接收了上述IP包的SIP代理服务器基于记述为Request-URI的AOR所示出的域名，通过进行例如DNS(Domain Name System即，域名命名系统)的NAPTR Record检索和SRV Record检索，来确定位于接收报文的传送目的地服务器所属的其他域中的SIP代理服务器(传送目的地SIP代理服务器)的IP地址或FQDN(Full Qualified Domain Name即，完全符合标准的域名)。在SRVRecord检索的结果表示FQDN的情况下，通过执行DNS的A Record检索，就能够取得传送目的地SIP代理服务器的IP地址。再有，关于从域名取得传送目的地SIP代理服务器的IP地址的过程，记述在RFC3263(非专利文献6)中。
在此，在连接目的地服务器的所属域与接收了SIP报文的SIP代理服务器的所属域相同的情况下，SIP代理服务器将在接收报文的Request-URI中记述的SIP-URI作为检索关键字，从定位服务器DB(数据库)取得连接目的地服务器的IP地址(或FQDN)，将该IP地址作为IP包的目的地地址，向连接目的地服务器传送SIP报文。在连接目的地服务器的所属域与SIP代理服务器(或发送源客户机)的所属域不同的情况下，SIP报文就被传送给位于连接目的地服务器的所属域中的另外的SIP代理服务器，传送目的地的SIP代理服务器从定位服务DB取得连接目的地服务器的IP地址或FQDN，将SIP报文传送给连接目的地服务器。
如上所述，在以经由对话管理服务器(SIP代理服务器)的对话设定为前提的网络中，对话管理服务器根据接收到的SIP报文中包含的请求资源标识符(SIP-URL)，判定连接目的地服务器所属的域以后，才将接收报文传送给连接目的地服务器或连接目的地对话管理服务器。但是，在与IP网连接的客户机终端上执行的一般的应用程序，在连接目的地服务器的指定中，不使用如上述的AOR形式的SIP-URI这样的包含域名的标识符，而是使用如IP地址这样地仅表示连接目的地服务器的标识符。
在应用程序或加密通信软件用IP地址指定了连接目的地服务器、并发行与服务器的连接请求，客户机按照用IP地址指定了连接目的地服务器的形式发送了连接请求SIP报文的情况下，对话管理服务器(SIP代理服务器)就不能够确定接收到的连接请求报文的传送目的地域。该情况下，就有客户机不能享用图3中示出的认证系统的优点的问题。

本发明的目的在于，提供一种能经由对话管理服务器，向连接目的地服务器传送用IP地址指定了连接目的地服务器的对话控制报文的数据通信方法和系统。
本发明的另外的目的在于，提供一种能经由对话管理服务器，向连接目的地服务器传送客户机所产生的、用IP地址指定了连接目的地服务器的连接请求的数据通信方法和系统。
本发明的又一个目的在于，提供一种能进行客户机与服务器之间的加密数据通信，并且，容易地进行加密数据通信之前必需的客户机与服务器之间的认证过程的数据通信方法和系统。
为了达到上述目的，在本发明中，在客户机的应用程序或加密通信软件按照用IP地址指定了连接目的地服务器的形式发行了连接请求时，在客户机或对话管理服务器上，自动地将上述IP地址变换为能识别域的期望的资源标识符。
本发明涉及的客户机与服务器之间的数据通信方法，包括以下步骤：第一步骤，从上述客户机向上述对话管理服务器指定连接目的地服务器的IP地址，询问包含分配给该连接目的地服务器的所属域名的资源标识符；第二步骤，上述对话管理服务器从管理着IP地址与资源标识符的对应关系的定位表中，取得与上述连接目的地服务器的IP地址相对应的资源标识符，通知给上述客户机；第三步骤，从上述客户机向上述对话管理服务器，发送用上述连接目的地服务器的资源标识符指定了请求资源的连接请求报文；第四步骤，上述对话管理服务器基于接收到的连接请求报文中记述的上述资源标识符中包含的域名，判定接收报文的传送目的地，将接收报文传送给连接目的地服务器、或管理该连接目的地服务器的所属域的另外的对话管理服务器。
本发明涉及的数据通信方法的另外的实施例，包括以下步骤：第一步骤，从上述客户机向上述对话管理服务器，发送用连接目的地服务器的IP地址指定了请求资源的连接请求报文；第二步骤，接收到了上述连接请求报文的对话管理服务器，从管理着IP地址与资源标识符的对应关系的定位表中，取得与上述连接目的地服务器的IP地址相对应的资源标识符；第三步骤，上述对话管理服务器将作为请求资源记述在接收报文中的IP地址，重写为从上述定位表取得的资源标识符；第四步骤，上述对话管理服务器基于上述资源标识符中包含的域名来判定接收报文的传送目的地，将接收报文传送给连接目的地服务器、或管理该连接目的地服务器的所属域的另外的对话管理服务器。
本发明涉及的数据通信方法的又一实施例，包括以下步骤：第一步骤，从上述客户机向成为连接目的地的服务器，询问包含分配给连接目的地服务器的所属域名的资源标识符；第二步骤，从上述连接目的地服务器向上述客户机通知被询问的上述资源标识符；第三步骤，从上述客户机向上述对话管理服务器，发送用上述连接目的地服务器的资源标识符指定了请求资源的连接请求报文；第四步骤，上述对话管理服务器基于在接收到的连接请求报文中记述的上述资源标识符中所包含的域名，判定接收报文的传送目的地，将接收报文传送给连接目的地服务器、或管理该连接目的地服务器的所属域的其他的对话管理服务器。
更详细地说，本发明的数据通信方法还包括：第五步骤，响应上述连接请求报文的接收，从上述连接目的地服务器通过上述对话管理服务器、向上述请求源客户机回送包含加密通信所必需的参数信息的连接响应报文；第六步骤，在上述客户机与连接目的地服务器之间，对包含按照用上述连接响应报文指定的参数信息进行加密的报文的包进行通信。
上述对话管理服务器例如由SIP(Session Initiation Protocol)服务器构成。该情况下，利用例如RFC3261中规定的TLS(Transport LayerSecurity)，把客户机与对话管理服务器之间的通信报文加密，利用例如RFC2401中规定的IPsec(Internet Protocol Security)，把客户机与连接目的地服务器之间的通信数据加密。
本发明提供的对话管理服务器，具有：请求资源重写单元，在从上述客户机接收了用连接目的地服务器的IP地址指定了请求资源的连接请求报文时，从管理着IP地址与资源标识符的对应关系的定位表中，取得与上述连接目的地服务器的IP地址相对应的资源标识符，将接收报文中记述的请求资源从IP地址重写为上述资源标识符；以及接收报文传送单元，基于上述资源标识符中包含的域名来判定接收报文的传送目的地，将接收报文传送给连接目的地服务器、或管理该连接目的地服务器的所属域的其他的对话管理服务器。
上述对话管理服务器具体地具有：与上述通信网络连接的网络接口部；处理对话控制报文的报文处理部；以及安全部，解密从上述网络接口部接收到的加密报文后，提供给上述报文处理部，并且，加密从上述报文处理部输出的对话控制报文后，向上述网络接口部输出；上述报文处理部具有上述请求资源的重写单元和上述接收报文的传送单元。
本发明提供的客户机终端，包括：与上述通信网络连接的网络接口部；处理对话控制报文的报文处理部；第一安全部，加密应用程序所产生的发送给连接目的地服务器的发送报文后，向上述网络接口部输出，并且，解密从上述网络接口部接收到的加密报文后，提供给上述应用程序；以及安全信息控制部，在从上述安全部产生了与连接目的地服务器的加密参数的交换请求时，向上述报文处理部输出用IP地址指定了连接目的地服务器的连接请求报文，在从上述报文处理部接收了连接响应报文时，将从该接收报文中抽出的加密参数提供给上述第一安全部；
上述报文处理部在从上述安全信息控制部接收了连接请求报文时，基于上述IP地址，从上述对话管理服务器或连接目的地服务器取得连接目的地服务器的资源标识符，并按照用该资源标识符指定了请求资源的形式，将上述连接请求报文发送给上述对话管理服务器。
在实际的应用中，具有第二安全部，该第二安全部解密从上述网络接口部接收到的加密的对话控制报文后，提供给上述报文处理部，并且，加密从上述报文处理部输出的对话控制报文后，向上述网络接口部输出；
与上述连接目的地服务器之间的通信数据通过上述第一安全部被加密，与上述对话管理服务器之间的通信报文通过上述第二安全部被加密。
根据本发明，在从客户机的应用程序或加密通信软件按照用IP地址指定了请求资源(连接目的地服务器)的形式发行了连接请求的情况下，也能够自动地将连接请求报文的请求资源变换为能根据IP地址识别域的资源标识符。从而，在传送控制连接请求报文的对话管理服务器中，能根据接收报文的资源标识符判定传送目的地域，将接收报文传送给连接目的地服务器或位于连接目的地服务器的所属域中的另外的对话管理服务器。
根据本发明，在执行一般的应用程序的客户机中，通过利用对话管理服务器的认证功能，也能够与连接目的地服务器之间容易地实现加密通信。
附图说明
图1是用于说明公开密钥加密通信中的现有的认证系统的图。
图2是示出现有的客户机为了利用IPsec进行加密通信而具有的软件的基本方框结构的图。
图3是用于说明适用了与本发明有关系的SIP代理服务器的认证系统的图。
图4是示出包含本发明的对话管理服务器(SIP服务器)的网络结构的一例的图。
图5是示出图4中示出的定位服务器LSV所具有的定位服务表的一例的图。
图6是示出图4中示出的SIP代理服务器PRa的软件结构的方框图。
图7是示出图4中示出的客户机CL1a的基本软件结构的图。
图8是示出图4中示出的服务器SV1b的基本软件结构的图。
图9是示出图4中示出的SIP代理服务器PRa的基本软件结构的图。
图10是示出图4中示出的域名注册管理机构RGa的基本软件结构的图。
图11是用于说明本发明涉及的加密通信的第一实施例的时序图的一部分。
图12是用于说明本发明涉及的加密通信的第一实施例的时序图的剩余部分。
图13是示出图11中的定位登记请求报文M1的格式的一例的图。
图14是示出图11中的定位登记响应报文M2的格式的一例的图。
图15是示出图11中的定位AOR取得请求报文M3的格式的一例的图。
图16是示出图11中的定位AOR取得响应报文M4的格式的一例的图。
图17是示出图11中的连接请求报文M5的格式的一例的图。
图18是示出连接请求报文M5的正文部M5-2的格式的一例的图。
图19是示出图11中的连接中报文M6的格式的一例的图。
图20是示出图11中的连接请求报文M7的格式的一例的图。
图21是示出图12中的连接中报文M8的格式的一例的图。
图22是示出图12中的连接请求报文M9的格式的一例的图。
图23是示出图12中的连接响应报文M10的格式的一例的图。
图24是示出连接响应报文M10的正文部M10-2的格式的一例的图。
图25是示出图12中的连接响应报文M11的格式的一例的图。
图26是示出图12中的连接响应报文M12的格式的一例的图。
图27是示出图12中的连接确认报文M13的格式的一例的图。
图28是示出图12中的连接确认报文M14的格式的一例的图。
图29是示出图12中的连接确认报文M15的格式的一例的图。
图30是示出图12中的断开请求报文M20的格式的一例的图。
图31是示出图12中的断开中报文M21的格式的一例的图。
图32是示出图12中的断开请求报文M22的格式的一例的图。
图33是示出图12中的断开中报文M23的格式的一例的图。
图34是示出图12中的断开请求报文M24的格式的一例的图。
图35是示出图12中的断开响应报文M25的格式的一例的图。
图36是示出图12中的断开响应报文M26的格式的一例的图。
图37是示出图12中的断开响应报文M27的格式的一例的图。
图38是示出在接收了密钥交换请求时，客户机CL1a的SP/SA控制部51C执行的控制工作的流程图。
图39A是示出在接收了连接请求报文的正文部时，客户机CL1a的SIP报文处理部53C执行的控制工作的流程图的一部分。
图39B是示出在接收了连接请求报文的正文部时，客户机CL1a的SIP报文处理部53C执行的控制工作的流程图的剩余部分。
图40是示出在接收了AOR取得请求报文时，域名注册管理机构RGa的SIP报文处理部53R执行的控制工作的流程图。
图41A是示出在接收了连接请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的第一部分。
图41B是示出在接收了连接请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的第二部分。
图41C是示出在接收了连接请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的第三部分。
图41D是示出在接收了连接请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的第四部分。
图42是示出在接收了连接请求报文时，服务器SV1b的SIP报文处理部53S执行的控制工作的流程图。
图43是示出在接收了连接请求报文的正文部时，服务器SV1b的SP/SA控制部51S执行的控制工作的流程图。
图44是示出在接收了密钥删除请求时，客户机CL1a的SP/SA控制部51C执行的控制工作的流程图。
图45是示出在接收了断开请求报文的发行请求时，客户机CL1a的SIP报文处理部53C执行的控制工作的流程图。
图46A是示出在接收了断开请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的一部分。
图46B是示出在接收了断开请求报文时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的剩余部分。
图47是示出在接收了断开请求报文时，服务器SV1b的SIP报文处理部53S执行的控制工作的流程图。
图48是示出在接收了断开请求的发生通知时，服务器SV1b的SP/SA控制部51S执行的控制工作的流程图。
图49是用于说明本发明涉及的加密通信的第二实施例的时序图的一部分。
图50是用于说明本发明涉及的加密通信的第二实施例的时序图的剩余部分。
图51是示出图49中的连接请求报文M5x的格式的一例的图。
图52是示出图49中的连接中报文M6x的格式的一例的图。
图53是示出图49中的连接请求报文M7x的格式的一例的图。
图54是示出图50中的断开请求报文M20x的格式的一例的图。
图55是示出图50中的断开请求报文M22x的格式的一例的图。
图56是示出在接收了连接请求报文的正文部时，第二实施例的客户机CL1a的SIP报文处理部53C执行的控制工作的流程图的一部分。
图57是示出在接收了连接请求报文时，第二实施例的SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的一部分。
图58是示出在接收了断开请求报文的发行请求时，第二实施例的客户机CL1a的SIP报文处理部53C执行的控制工作的流程图。
图59是示出在接收了断开请求报文时，第二实施例的SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图的一部分。
图60是示出本发明的第三实施例的客户机CL1a具有的基本软件结构的图。
图61是示出本发明的第三实施例的服务器SV1b具有的基本软件结构的图。
图62是示出服务器SV1b具有的定位表的内容的图。
图63是用于说明本发明涉及的加密通信的第三实施例的时序图的一部分。
图64是示出图63中的AOR取得请求报文M30的格式的一例的图。
图65是示出图63中的AOR取得响应报文M40的格式的一例的图。
图66是示出在接收了连接请求报文的正文部时，第三实施例的客户机CL1a的SIP报文处理部53C执行的控制工作的流程图的一部分。
图67是示出在接收了AOR取得请求报文时，第三实施例的服务器SV1b的SIP报文处理部53S执行的控制工作的流程图。

以下，参照附图，说明本发明的实施例。
图4示出适用本发明的网络结构的一例。
在此示出的网络包括：形成SIP服务器SIPa所管理的第一域的第一网络NW1，形成SIP服务器SIPb所管理的第二域的第二网络NW2，定位服务器LSV，DNS(Domain Name System)。
第一网络NW1上连接着客户机CL1a、CL2a和服务器SV1a、SV2a，第二网络NW2上连接着客户机CL1b、CL2b和服务器SV1b、SV2b。此外，SIP服务器SIPa由SIP代理服务器PRa和域名注册管理机构PGa构成，SIP服务器SIPb由SIP代理服务器PRb和域名注册管理机构PGb构成。
在此，附随各客户机和服务器而在括号中示出的字符串，表示成为SIP报文的传送目的地标识符(资源标识符)的AOR(Address-of-Record)形式的SIP-URI值。在与第一网络NW1连接的客户机和服务器中分配了包含SIP服务器SIPa的域标识符“aaa.com”的AOR，在与第二网络NW2连接的客户机和服务器中分配了包含SIP服务器SIPb的域标识符“bbb.com”的AOR。
本发明的SIP服务器SIPa、SIPb在从位于各自管辖下的客户机接收了用IP地址指定了连接目的地服务器的SIP报文时，向定位服务器LSV请求与上述连接目的地IP地址相对应的AOR(资源标识符)的检索(定位数据检索)。此外，SIP服务器SIPa、SIPb在各自从其他的SIP服务器接收了用AOR指定了连接目的地服务器的SIP报文时，向定位服务器LSV请求与上述连接目的地AOR相对应的IP地址的检索。
定位服务器LSV在定位服务数据库(DB)中例如如图5所示，由与位于SIP服务器SIPa、SIPb管辖下的客户机和服务器相对应的多个入口EN-1、EN-2、…构成，各入口具有表示客户机或服务器的AOR61与IP地址62的对应关系的定位服务表60。定位服务器LSV响应来自SIP服务器的定位数据检索请求，从上述定位服务表60中检索与被指定为检索关键字的IP地址(或AOR)相对应的AOR(或IP地址)，将检索结果回送给请求源SIP服务器。
图6示出SIP代理服务器PRa的硬件结构。
SIP代理服务器Pra包括处理器(CPU)11、用于存储处理器所执行的各种软件和数据的存储器12和硬盘13、用于与网络NW1(NW2)连接的网络接口14、输入输出装置15，这些要素利用内部总线16相互连接。SIP代理服务器PRb、域名注册管理机构RGa、RGb、客户机CL1a～CL2b、服务器SV1a～SV2b基本上也由与图6中示出的SIP代理服务器同样的结构要素构成。
以下，以所属在图4中示出的第一域中的客户机CL1a、和所属在第二域中的服务器SV1b进行加密数据通信的情况下的通信过程为例，说明本发明的第一实施例。
图7示出客户机CL1a的基本的软件结构。其他客户机CL1b～CL2b也具有与其同样的软件结构。
客户机CL1a的软件由网络接口卡部(NIC)20C、包含具有IPsec加密/解密功能的IPsec引擎31C的TCP/IP层部30C、应用程序40C、密钥管理进程部50C构成。在第一实施例中，密钥管理进程部50C的特征在于具有SP/SA(Security Policy/Security Association即，安全策略/安全检查程序)控制部51C、TLS(Transport Layer Security即，传输层安全性)部52C、SIP报文处理部53C。
图8示出服务器SV1b的基本的软件结构。其他的服务器SV1a、SV2a、SV2b也构成为与其同样的软件结构。
服务器SV1b的软件包括网络接口卡部(NIC)20S、包含具有IPsec加密/解密功能的IPsec引擎31S的TCP/IP层部30S、应用程序40S、密钥管理进程部50S，密钥管理进程部50S具有SP/SA控制部51S、TLS部52S、SIP报文处理部53S。
客户机CL1a的应用程序40C和服务器SV1b的应用程序40S，利用各自具有的IPsec引擎31C、31S的IPsec加密/解密功能，进行加密数据的通信。另一方面，客户机CL1a的SIP报文处理部53C与后述的SIP服务器SIPa(SIP代理服务器PRa、域名注册管理机构RGa)的SIP报文处理部之间，利用各自具有的TLS部的报文加密/解密功能，进行加密后的SIP报文的通信。同样地，服务器SV1b的SIP报文处理部53S也与SIP服务器SIPa(SIP代理服务器PRa、域名注册管理机构RGa)的SIP报文处理部之间，利用各自具有的TLS部的报文加密/解密功能，进行加密后的SIP报文的通信。
图9示出SIP代理服务器PRa的基本的软件结构。SIP代理服务器PRb也构成与其同样的软件结构。
SIP代理服务器PRa的软件包括网络接口卡部(NIC)20P、TCP/IP层部30P、密钥管理进程部50P，密钥管理进程部50P具有TLS部52P和SIP报文处理部53P。SIP报文处理部53P具有后述的SIP-URL(AOR)检索功能54。SIP代理服务器PRa的SIP报文处理部53P，利用TLS部52P的报文加密/解密功能，与所属在位于管理下的域中的客户机、服务器和管理其他域的其他SIP代理服务器例如PRb，进行加密报文的通信。
图10示出域名注册管理机构RGa的基本的软件结构。域名注册管理机构RGb也构成与其同样的软件结构。
域名注册管理机构RGa的软件包括网络接口卡部(NIC)20R、TCP/IP层部30R、具有报文的加密/解密功能的TLS部52R、SIP报文处理部53R、域名注册管理处理部60R。SIP报文处理部53R一接收客户机发行的AOR取得请求或SIP代理服务器PRa发行的AOR取得请求，就向域名注册管理处理部60R请求定位数据的检索。域名注册管理处理部60R响应来自SIP报文处理部53R的请求，访问定位服务器LSV所具有的定位服务DB。再有，在域名注册管理机构RGa与SIP代理服务器PRa之间的通信中不适用加密。
图11和图12示出了示出本发明涉及的加密数据通信的第一实施例的时序图。在第一实施例中，客户机CL1a发行AOR取得请求。
在本实施例中，与成为来自客户机CL1a的连接请求目的地的第二网络连接的服务器SV1b，在来自客户机CL1a的连接请求之前，与SIP服务器SIPb的域名注册管理机构RGb之间执行了用于服务器SV1b的认证和加密通信用的参数设定的TLS磋商(S1)之后，向域名注册管理机构RGb发送定位登记请求报文(SIP报文：REGISTER)M1。
定位登记请求报文M1例如如图13所示，用附带了IP报头H1和UDP/TCP报头H2的IP包形式进行发送。IP报头H1包含作为目的地地址的域名注册管理机构RGb(SIP服务器SIPb)的IP地址和作为发送源地址的服务器SV1b的IP地址。
SIP报文由表示SIP报文的种类(Request-Method)的起始行、记述了请求或响应内容的报头部、根据需要记述了对话内容的报文正文部构成。根据报文的种类，在上述起始行中记述表示该报文的目的地的资源标识符(Request-URI)。此外，在报文正文部中的对话内容的记述中，使用用RFC3266标准化后的SDP(Session Description Protocol即，对话描述协议)。
在是服务器SV2b发行的定位登记请求报文M1的情况下，在起始行中，作为SIP报文的种类，包含有“REGISTER”，作为表示报文目的地的资源标识符，包含有域名注册管理机构RGb的SIP-URI即“registrar.bbb.com”。此外，在接着起始行的报头部中包括：示出SIP报文的路径的Via报头、示出报文的目的地的To报头、示出报文的发送源的From报头、示出在发送源中指定了的对话标识符的Call-ID报头、示出请求方法的CSeq报头、包含应该登记在定位服务表中的服务器SV1b的IP地址“sv1@192.0.2.4”的Contact报头、示出报文的有效时间的Expires报头、示出后续的报文正文部的长度的Content-Length报头及其他报头信息。由于在定位登记请求报文M1的情况下省略报文正文部，因此，在Content-Length报头中设定着值“0”，在To报头和From报头中设定着请求源服务器SV1b的URI的值“sv1@bbb.com”。
域名注册管理机构RGb一接收上述定位登记请求报文M1，就在定位服务DB的定位服务表60中登记表示接收报文的From报头所示的请求源URI“sv1@bbb.com”与Contact报头所示的请求源IP地址“sv1@192.0.2.4”的关系的定位数据(S2)，定位数据的登记一结束(S3)，就向请求源服务器SV2b发送图14中示出的定位登记响应报文M2。在定位登记响应报文M2的起始行中，作为SIP报文的种类，包含有表示是响应报文的“200 OK”，在报头部中设定与定位登记请求报文M1大致相同内容的报头信息。
在该状态下，在客户机CL1a的用户调用应用程序、进行了给服务器SV1b的IP地址发送包的操作的情况下，在本发明的第一实施例中，客户机CL1a在与SIP服务器SIPa(域名注册管理机构RGa)之间执行了用于认证客户机和设定加密通信用参数的TLS磋商(S4)之后，向SIP服务器SIPa(域名注册管理机构RGa)发送AOR(Address-of-Record)取得请求报文(SIP报文：GET AOR)M3。
上述AOR取得请求报文M3例如如图15所示，在起始行中包含表示SIP报文种类的“GET AOR”和域名注册管理机构RGa的URI即“registrar.aaa.com”，Via报头示出了成为客户机CL1a的SA/SP控制部51C的标识符的URI的值。此外，在To报头中设定着成为客户机CL1a的连接对象的服务器SV1b的IP地址“192.0.2.4”，在From报头中设定着客户机CL1a的URI“cl1@aaa.com”。
域名注册管理机构RGa一接收AOR取得请求报文M3，就从定位服务DB的定位服务表60中检索与接收报文的To报头所示的IP地址“192.0.2.4”相对应的AOR(服务器SV1b的URI)的值(S5)，定位数据AOR的检索一结束(S6)，就向请求源客户机CL1a发送AOR取得响应报文M4。
AOR取得响应报文M4如图16所示，在起始行中包含示出报文种类是响应报文的“200 OK”，在报头部中记述着与AOR取得请求报文M3大致相同内容的报头信息、和示出从定位服务表60检索到的服务器SV1b的URI的值“sv1@bbb.com”的AOR报头。
通过接收上述AOR取得响应报文M4而取得了连接目的地服务器SV1b的URL的客户机CL1a，在与SIP服务器SIPa的SIP代理服务器PRa之间执行了用于认证客户机和设定加密通信用参数的TLS磋商(S7)之后，向SIP代理服务器PRa发送对服务器SV1b的连接请求报文M5。
连接请求报文M5如图17所示，由连接请求报文的报头部M5-1和正文部M5-2构成，连接请求报文的报头部M5-1在起始行中包含报文种类“INVITE”和作为Request-URI的成为报文目的地的服务器SV1b的SIP-URI“sv1@bbb.com”。此外，作为报头信息，包括示出客户机CL1a中的SIP报文处理部53C的SIP-URI的Via报头、包含服务器SV1b的SIP-URI“sv1@bbb.com”的To报头、包含客户机CL1a的SIP-URI“cl1@aaa.com”的From报头、Content-Type报头、Content-Length报头及其他信息。Content-Type报头示出了正文部M5-2关联的应用程序，Content-Length报头示出了正文部M5-2的长度。
连接请求报文M5的报头部M5-2例如如图18所示，作为适用于客户机CL1a与服务器SV1b之间的加密通信的SA信息，与IKE中的通常的IPsec用SA设定时同样，包含着表示加密协议的识别信息的建议有效负荷91、表示变换识别信息的变换有效负荷92、密钥交换有效负荷93、表示请求源的识别信息的第一ID有效负荷94、表示连接目的地的识别信息的第二ID有效负荷95。
在此，提出了客户机CL1a在2个变换有效负荷92-1、92-2中将“ESP-AES”和“ESP-3DES”作为变换ID，连接目的地服务器SV1b选择其中的1个，用连接响应报文通知给客户机。再有，第一ID有效负荷94的ID数据表示请求源客户机CL1a的IP地址，第二ID有效负荷95的ID数据表示连接目的地服务器SV1b的IP地址。
由于SIP代理服务器PRa一接收上述连接请求报文M5，就向请求源客户机CL1a通知正在与服务器SV1b连接中，因此，在发送了如图19所示的连接中报文M6之后，就在与连接目的地服务器SV1b所属的域的SIP代理服务器PRb之间执行用于相互认证和加密通信用的参数设定的TLS磋商(S8)。连接中报文M6在起始行中包含表示正在执行请求中的“100 Trying”作为报文种类，在报头部中包含从连接请求报文M5中抽出的Via、To、From、Call-ID、Csec等的几个项目的报头信息，省略了报文正文部。
SIP代理服务器PRa与SIP代理服务器PRb之间的TLS磋商一结束，就在从客户机接收到的连接请求报文M5中附加包含自己的SIP-URI“proxy.aaa.com”的新的Via报头、和表示连接请求经由了URI“proxy.aaa.corn”的Record-Route报头，作为图20中示出的连接请求报文M7，发送给SIP代理服务器PRb。
SIP代理服务器PRb一接收上述连接请求报文M7，就从接收报文的起始行中抽出目的地URI“SV1@aaa.com”，如图12所示，向定位服务器LSV请求从定位服务DB中检索与上述目的地URI相对应的IP地址(定位数据检索)(S9)。SIP代理服务器PRb一接收表示定位服务DB的检索结果的定位数据(IP地址“sv1@192.0.2.4”(S10)，就在对上述连接请求报文M7的请求源SIP代理服务器PRa发送了图21中示出的连接中报文M8之后，在与由IP地址“sv1@192.0.2.4”确定的连接目的地服务器SV1b之间，执行用于相互认证和加密通信用的参数设定的TLS磋商(S11)。
SIP代理服务器PRb一结束与连接目的地服务器SV1b之间的TLS磋商，就将连接请求报文M7的Request-URI重写为IP地址“sv1@192.0.2.4”，附加包含自己的SIP-URI“proxy.bbb.com”的新的Via报头、和表示连接请求经由了URI“proxy.bbb.com”的Record-Route报头，作为图22中示出的连接请求报文M9，发送给连接目的地服务器SV1b。
连接目的地服务器SV1b响应上述连接请求报文M9，回送连接响应报文M10。连接响应报文M10如图23所示，由报头部M10-1和正文部M10-2构成，在报头部M10-1的起始行中，作为报文种类，包含有表示是响应报文的“200 OK”，接在起始行之后，包含与连接请求报文M9同样的多个项目的报头信息。此外，正文部M10-2例如如图24所示，保留了连接请求报文M10的正文部M5-2中提出的2个变换有效负荷92-1、92-2中的、服务器SV1b所选择的1个变换有效负荷(在该例子中是EPS-AES)。
SIP代理服务器PRb一接收连接响应报文M10，就从接收报文的报头部中除去包含自身URI的Via报头，变换为图25中示出的连接响应报文M11后，发送给SIP代理服务器PRa。SIP代理服务器PRa一接收连接响应报文M11，就从接收报文的报头部中除去包含自身URI的Via报头，变换为图26中示出的连接响应报文M12，发送给请求源客户机CL1a。
请求源客户机CL1a一接收连接响应报文M12，就分析接收报文的正文部M10-2，决定在与连接目的地服务器SV1b的IPsec通信中应该适用的SA信息，在将其登记在SADB33C中之后，将图27中示出的连接确认报文M13发送给SIP代理服务器PRa。连接确认报文M13在起始行中包含报文种类“ACK”和作为Request-URI的服务器SV1b的SIP-URI，作为报头信息，包含有Via、To、From、Call-ID、CSec、Route报头，省略了报文正文部。在Route报头中设定从连接响应报文M12的Record-Route报头中抽出的URI的值。
上述连接确认报文M13在SIP代理服务器PRa中附加新的Via报头，去掉与SIP代理服务器PRa相对应的Route报头后，作为图28中示出的连接确认报文M14，传送给SIP代理服务器PRb。SIP代理服务器PRb在连接确认报文M14中附加新的Via报头，去掉与SIP代理服务器PRb相对应的Route报头，变换为图29中示出的连接确认报文M15后，传送给连接目的地服务器SV1b。
通过由服务器SV1b接收上述连接确认报文M15，客户机CL1a和服务器SV1b就能进行适用了IPsec加密的应用程序间的数据通信(S20)。即，客户机CL1a按照SADB33C中登记的SA信息，将向服务器SV1b发送的发送数据加密，用IP包形式将其发送。服务器SV1b能够按照SADB33V中登记的SA信息，将来自客户机CL1a的接收数据解密，按照上述SA信息，将向客户机CL1a发送的数据加密，用IP包形式发送。
客户机CL1a一结束与服务器SV1b之间的数据通信，就对SIP代理服务器PRa发送图30中示出的断开请求报文M20。断开请求报文M20在起始行中包含报文种类“BYE”和服务器SV1b的SIP-URI，与连接确认报文M13同样，作为报头信息包含Via、To、From、Call-ID、CSec、Route报头，省略报文正文部。
SIP代理服务器PRa一接收上述断开请求报文M20，就在对请求源的客户机CL1a发送了图31中示出的断开中报文M21之后，在断开请求报文M20中附加新的Via报头，去掉与SIP代理服务器PRa相对应的Route报头，作为图32中示出的断开请求报文M22发送给SIP代理服务器PRb。断开中报文M21在起始行中包含表示正在执行请求中的“100Trying”作为报文种类，在报头部中包含从断开请求报文M20抽出的Via、To、From、Call-ID、Csec等的几个项目的报头信息，省略了报文正文部。
SIP代理服务器PRb一接收上述断开请求报文M22，就在对SIP代理服务器PRa发送了图33中示出的断开中报文M23之后，在断开请求报文M22中附加新的Via，去掉与SIP代理服务器PRb相对应的Route报头，作为图34中示出的断开请求报文M24发送给服务器SV1b。
服务器SV1b一接收断开请求报文M24，就向SIP代理服务器PRb发送图35中示出的断开响应报文M25。断开响应报文M25在起始行中包含表示响应的“200 OK”作为报文种类，在报头部中包含从断开请求报文M24抽出的Via、To、From、Call-ID、Csec等几个项目的报头信息，省略了报文正文部。
SIP代理服务器PRb一接收断开响应报文M25，就从接收报文的报头部去掉包含自身URI的Via报头，变换为图36中示出的断开响应报文M26，发送给SIP代理服务器PRa。SIP代理服务器PRa一接收断开响应报文M26，就从接收报文的报头部去掉包含自身URI的Via报头，变换为图37中示出的断开响应报文M27，发送给请求源客户机CL1a。请求源客户机CL1a一接收上述断开响应报文M27，就结束IPsec加密/解密，等待同一或另外的应用程序的新的包发送请求。
下面，参照图38～48，说明能进行上述的本发明的第一实施例的加密数据通信的客户机CL1a、SIP服务器SIPa(SIP代理服务器PRa、域名注册管理机构RGa)、服务器SV1b的控制工作。
图38示出在客户机CL1a中，响应IPsec引擎31发行的密码密钥交换请求后、SP/SA控制部51C执行的控制工作的流程图。
客户机CL1a的IPsec引擎31C一检测到来自应用程序40C的IP包的发送请求，就参照SPDB(Security Policy Data Base)32C，判断在上述IP包中是否适用IPsec加密。在判断为应该适用IPsec加密的情况下，IPsec引擎31C就从SADB(Security Association Data Base)33C中检索应该适用在上述IP包中的密码密钥等的SA(Security Association)信息。在此，在SADB中未登记应该适用在IP包中的SA信息的情况下，IPsec引擎31C对密钥管理进程50C请求与通信对象之间的加密参数的交换(密钥交换)。
在本实施例中，用SP/SA控制部51C处理来自IPsec引擎31C的上述密钥交换请求。SP/SA控制部51C一接收密钥交换请求，就基于密钥交换请求所示出的TCP/IP通信参数和SP/SA控制部51C管理的可利用的SA信息，制成图18中例示的连接请求报文的正文部M5-2(步骤101)，将该连接请求报文正文部M5-2提供给SIP报文处理部53C(102)，等待接收来自SIP报文处理部53C的连接响应报文正文部(103)。
SP/SA控制部51C从SIP报文处理部53C一接收图24中例示的连接响应报文正文部M10-2，就分析接收到的连接响应报文正文部，决定在这次的IPsec通信中应该使用的SA信息(104)，向IPsec引擎31C通知在SADB33中应该设定的SA信息(105)。
图39(图39A、39B)表示在从SP/SA控制部51C接收了连接请求报文的正文部时，SIP报文处理部53C执行的控制工作的流程图110。
SIP报文处理部53C从SP/SA控制部51C一接收连接请求报文的正文部，就根据第二ID有效负荷的ID数据所示出的连接目的地服务器的IP地址、和SIP报文处理部53C所管理的通信控制参数，制成图15中例示的AOR取得请求报文M3(步骤111)，将该报文通过TSL部52C、TCP/IP部30C和NIC部20C，发送给位于与客户机CL1a同一域中的SIP服务器SIPa(域名注册管理机构RGa)(112)。这时，TLS部52C在与域名注册管理机构RGa之间执行了TLS磋商(图11的S5)之后，将TLS加密后的AOR取得请求报文M3通过TCP/IP部30C、NIC部20C发送给域名注册管理机构RGa。利用TCP/IP部30C，在上述AOR取得请求报文M3上附加包含发送给SIP服务器SV1的目的地IP地址的IP报头H1和UDP/TCP报头H2后，用IP包形式向网络NW1送出。
SIP报文处理部53C等待来自域名注册管理机构RGa的AOR取得响应报文(113)，一接收AOR取得响应报文，就分析接收报文(114)，从AOR报头抽出分配给连接目的地服务器的AOR形式的SIP-URI(115)。之后，SIP报文处理部53C将上述SIP-URI适用在起始行和To报头中，制成由报头部M5-1和从SP/SA控制部51C接收到的正文部M5-2构成的图17中例示的连接请求报文M5(116)。
SIP报文处理部53C通过TSL部52C、TCP/IP部30C和NIC部20C，将上述连接请求报文发送给SIP服务器SIPa的SIP代理服务器PRa(117)，等待来自SIP代理服务器PRa的响应(118)。在从SIP代理服务器PRa接收了连接中报文M6的情况下，在执行连接中报文处理(119)之后，等待来自SIP代理服务器PRa的下一个响应。
SIP报文处理部53C从SIP代理服务器PRa一接收连接响应报文M12，就分析接收报文(120)，将从接收报文中抽出的图24中例示的连接响应报文正文部M12-2提供给SP/SA控制部51C(121)。之后，SIP报文处理部53C制成图27中例示的连接确认报文M13，将其通过TSL部52C、TCP/IP部30C和NIC部20C发送给SIP代理服务器PRa(122)，结束该过程。
图40示出接收了AOR取得请求报文M3时，域名注册管理机构RGa的SIP报文处理部53R执行的控制工作的流程图200。
域名注册管理机构RGa的SIP报文处理部53R分析接收到的AOR取得请求报文M3(步骤201)，将To报头所示的连接目的地服务器SV1b的IP地址作为检索关键字，制成定位数据检索询问(202)，通过域名注册管理处理部60R，将上述检索询问发送给定位服务器LSV(203)，并等待来自定位服务器的响应(204)。
SIP报文处理部53R通过域名注册管理处理部60R从定位服务器LSV一接收定位数据，就制成包含接收数据所示出的SIP-URI作为AOR报头的图16中例示的AOR取得响应报文M4(205)，将该报文M4通过TCP/IP部30R和NIC部20R发送给AOR取得请求报文M3的发送源(在该例子中是客户机CL1a)(206)，结束该过程。
图41(图41A～图41D)示出在从客户机CL1a接收了连接请求报文M5时，SIP代理服务器PRa的SIP报文处理部53P所执行的控制工作的流程图300。
SIP代理服务器PRa的SIP报文处理部53P一接收来自客户机CL1a的连接请求报文M5，就分析接收报文(步骤301)，检验接收报文的起始行中记述的Request-URI(302)，根据上述Request-URI所示的域名判定接收报文的传送目的地(303)。
在判定为接收报文的传送目的地属于其他域中的情况下，SIP报文处理部53P利用DNS检索(NAPTR检索+SRV检索+A检索)等决定接收报文的传送目的地域的SIP服务器(SIP代理服务器)(304)。在图11中示出的例子中，利用DNS检索，判明连接请求报文M5的传送目的地是SIP代理服务器PRb。该情况下，SIP报文处理部53P在通过TLS部52P、TCP/IP部30P和NIC部20P向连接请求报文M5的发送源即客户机CL1a发送了图19中例示的连接中报文M6(305)之后，将在连接请求报文M5中附加了新的Via报头的形式的连接请求报文M7传送给SIP代理服务器PRb(306)，并等待来自SIP代理服务器PRb的响应(307)。
SIP报文处理部53P从SIP代理服务器PRb一接收连接中报文M8，就在执行了连接中报文处理(308)之后，等待来自SIP代理服务器PRb的下一个响应。SIP报文处理部53P从SIP代理服务器PRb一接收连接响应报文M11，就分析接收报文(309)，从接收报文中去掉包含自身SIP-URI的Via报头，作为连接响应报文M12，向连接请求源(客户机CL1a)传送(310)。之后，SIP报文处理部53P等待来自连接请求源(客户机CL1a)的响应(311)。SIP报文处理部53P一接收连接确认报文M13，就分析接收报文(312)，在接收报文中附加包含自身的SIP-URI的新的Via报头，作为连接确认报文M14，传送给SIP代理服务器PRb(313)，结束该过程。
在判定步骤303中，判定为从客户机终端CL1a接收到的连接请求报文的传送目的地是例如服务器SV1a(或SV2a)这样地所属于与SIP代理服务器PRa同一域中的情况下，SIP报文处理部53P就制成将接收报文的Request-URI所示的SIP-URI作为检索关键字的定位数据(IP地址)检索询问(315)，将该定位数据检索询问发送给定位服务器LSV(316)后，等待定位服务响应(317)。
SIP报文处理部53P从定位服务器LSV一接收定位数据，就将上述定位数据所示的连接目的地服务器的IP地址适用在目的地IP地址中，用IP包形式向网络NW1发送连接请求报文(318)，并等待来自连接目的地服务器的响应(319)。在上述连接请求报文中附加了包含SIP代理服务器PRa的SIP-URI的新的Via报头。
从连接目的地服务器一接收连接响应报文，SIP报文处理部53P就分析接收报文(320)，将去掉了与自身相对应的Via报头的形式的连接响应报文传送给连接请求源(321)，并等待来自连接请求源(客户机CL1a)的响应(322)。SIP报文处理部53P从连接请求源一接收连接确认报文，就分析接收报文(323)，将附加了新的Via报头的形式的连接确认报文传送给连接目的地服务器(324)，并结束该过程。
图42表示连接目的地服务器SV1b的SIP报文处理部53S在从SIP代理服务器PRb接收了连接请求报文M9时执行的控制工作的流程图400。
从SIP代理服务器PRb发送到连接目的地服务器SV1b的连接请求报文M9，在TLS部52S中解密后，被输入到SIP报文处理部53S中。SIP报文处理部53S一接收连接请求报文M9，就分析接收报文(步骤401)，将从接收报文中抽出的连接请求报文正文部M5-2提供给SP/SA控制部51S(402)，等待来自SP/SA控制部51S的响应(403)。
SIP报文处理部53S从SP/SA控制部51S一接收连接响应报文正文部M10-2，就制成图25中例示的连接响应报文M11(404)。SIP报文处理部53S通过TLS部、TCP/IP部和NIC部，将上述连接响应报文M11传送给SIP代理服务器PRb(405)，等待来自SIP代理服务器PRb的响应(406)。SIP报文处理部53S从SIP代理服务器PRb一接收连接确认报文M15，就分析接收报文(407)，向SP/SA控制部51S通知已接收了连接确认报文M15(408)，并结束该过程。
图43表示在从SIP报文处理部53S接收了连接请求报文正文部M5-2时，服务器SV1b的SP/SA控制部51S执行的控制工作的流程图420。
SP/SA控制部51S分析从SIP报文处理部53S接收到的连接请求报文正文部M5-2(步骤421)，从在连接请求报文正文部M5-2中记述的SA信息(在图18的例子中，是变换有效负荷92-1、92-2)中，选择在与客户机的加密通信中应该适用的SA，制成图24中例示的连接响应报文的正文部M10-2(422)。SP/SA控制部51S将上述连接响应报文正文部M10-2提供给SIP报文处理部53S(423)，等待来自SIP报文处理部53S的响应(424)。SP/SA控制部51S从SIP报文处理部53S一接受连接确认报文的接收通知，就对IPsec引擎31S通知应该设定在SADB33S中的SA信息(425)，并结束该过程。
图44示出在客户机CL1a中，响应IPsec引擎31C所发行的密码密钥删除请求后，SP/SA控制部51C所执行的控制工作的流程图。
当客户机CL1a的用户结束与服务器SV1b进行通信的应用程序时，就从IPsec引擎31C向SP/SA控制部51C发行密码密钥删除请求。SP/SA控制部51C从IPsec引擎31C一接收密码密钥删除请求，就向SIP报文处理部53C请求发行断开请求报文(131)，并等待来自SIP报文处理部53C的响应(132)。SP/SA控制部51C从SIP报文处理部53C一接受断开响应报文的接收通知，就对IPsec引擎31C指示删除与上述密码密钥删除请求相对应的SADB的设定值(133)，结束该过程。
图45示出在从SP/SA控制部51C接收了断开请求报文的发行请求时，SIP报文处理部53C执行的控制工作的流程图140。
SIP报文处理部53C从SP/SA控制部51C一接收断开请求报文的发行请求，就制成图30中例示的断开请求报文M20(步骤141)，通过TLS部52C、TCP/IP部30C的IPsec引擎31C、NIC部20C，将上述断开请求报文M20的IP包发送给SIP服务器SIPa(SIP代理服务器PRa)(142)。
SIP报文处理部53C等待来自SIP代理服务器PRa的响应(143)，在接收了断开中报文M21的情况下，执行断开中报文处理(144)后，等待来自SIP代理服务器PRa的下一个响应。SIP报文处理部53C从SIP代理服务器PRa一接收图37中例示的断开响应报文M27，就分析接收报文(145)，向SP/SA控制部51C通知接收断开响应报文(146)，并结束该过程。
图46(图46A、图46B)示出在从客户机接收了断开请求报文M20时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图340。
SIP报文处理部53P分析接收到的断开请求报文M20(步骤341)，检验接收报文的Request-URI(342)。SIP报文处理部53P根据Request-URI中记述的域名，判定接收报文的传送目的地(343)，在判定为传送目的地属于其他域的情况下，利用DNS检索(NAPTR检索+SRV检索+A检索)等决定接收报文的传送目的地域的SIP服务器(SIP代理服务器)(344)。
在图12中示出的例子中，利用上述DNS检索，判明断开请求报文M20的传送目的地是SIP代理服务器PRb。该情况下，SIP报文处理部53P在通过TLS部52P、TCP/IP部30P和NIC部20P向断开请求报文M20的发送源即客户机CL1a发送了图31中例示的断开中报文M21(345)之后，在断开请求报文M20中附加新的Via报头，将去掉了与SIP代理服务器PRa相对应的Route报头的断开请求报文M22传送给SIP代理服务器PRb(346)，等待来自SIP代理服务器PRb的响应(347)。
SIP报文处理部53P从SIP代理服务器PRb一接收断开中报文M23，就在执行了断开中报文处理(348)之后，等待来自SIP代理服务器PRb的下一个响应。SIP报文处理部53P从SIP代理服务器PRb一接收断开响应报文M26，就分析接收报文(349)，从接收报文去掉包含自身SIP-URI的Via报头，作为断开响应报文M27传送给断开请求源(客户机CL1a)(350)，并结束该过程。
再有，若在判定步骤343中判定为从客户机终端CL1a接收到的断开请求报文M20的传送目的地属于与SIP代理服务器PRa同一域中的情况下，SIP报文处理部53P就制成将接收报文的Request-URI所示的SIP-URI作为检索关键字的定位数据(IP地址)检索询问(351)，将该检索询问发送给定位服务器LSV(352)，并等待定位服务响应(353)。
SIP报文处理部53P从定位服务器LSV一接收定位数据，就将上述定位数据所示的服务器IP地址适用在目的地IP地址中，将断开请求报文的IP包向网络NW1发送(354)，并等待来自服务器的响应(355)。再有，在上述断开请求报文中附加了包含SIP代理服务器PRa的SIP-URI的新的Via报头。
从断开请求报文的目的地服务器一接收断开响应报文，SIP报文处理部53P就分析接收报文(356)，将去掉了自身的Via报头的形式的断开响应报文传送给断开请求源(357)，结束该过程。
图47示出从SIP代理服务器接收了断开请求报文M24时，服务器SV1b的SIP报文处理部53S执行的控制工作的流程图430。
SIP报文处理部53S通过TLS部52S一接收断开请求报文M24，就分析接收报文(步骤431)，对SP/SA控制部51S指定应该断开的通信的识别信息(例如，Call-ID)，通知接收断开请求(432)，并等待来自SP/SA控制部51S的响应(433)。SIP报文处理部53S从SP/SA控制部51S一接收断开响应，就制成图35中例示的断开响应报文M25(434)，通过TLS部、TCP/IP部和NIC部传送给SIP代理服务器PRb(435)，结束该过程。
图48示出从SIP报文处理部53S通知了发生断开请求时，SP/SA控制部51S执行的控制工作的流程图440。
SP/SA控制部51S基于通知的通信识别信息，确定应该从SADB33S删除的SA信息(步骤441)，向IPsec引擎31S指示删除上述SA信息(442)，并结束该过程。
下面，参照图49至图59，说明本发明涉及的加密数据通信的第二实施例。
在上述的第一实施例中，在按照用IP地址指定连接目的地服务器的形式产生了包发送请求时，客户机的SIP报文处理部53C发行用于取得与上述连接目的地IP地址相对应的SIP-URI的AOR取得请求，并适用从域名注册管理机构取得的SIP-URI，发行了发送给SIP代理服务器的连接请求报文。
本发明的第二实施例的特征在于，在按照用IP地址指定了连接目的地服务器的形式产生了包发送请求时，客户机发行用IP地址指定了连接目的地服务器的形式的连接请求报文，接收了该连接请求报文的SIP代理服务器检验在接收报文的起始行中记述的Request-URI的形式，在用IP地址指定了连接目的地的情况下，将其重写到SIP-URI，向位于连接目的地服务器的所属域中的其他SIP服务器传送连接请求报文。
图49和图50示出本发明的第二实施例中的加密通信时序图。关于用与图11、图12相同的符号示出的、已经在第一实施例中说明了的步骤和报文，尽量省略说明。
在本发明的第二实施例中，在按照用IP地址指定了连接目的地服务器的形式产生了包发送请求时，客户机CL1a在与SIP代理服务器PRa之间执行了用于客户机认证和加密通信用参数设定的TLS磋商(S7)之后，对SIP代理服务器PRa立即发送连接请求报文M5x。在此发送的连接请求报文M5x如图51所示，起始行中记述的Request-URI和报头部中记述的To报头，是用IP地址“192.0.2.4”指定了连接目的地服务器SV1b。报头部的其他报头信息和连接请求报文正文部M5-2的内容，与图17和图18中示出的第一实施例的连接请求报文M5相同。
由于接收到的连接请求报文M5x的Request-URI成为“SIP：IP地址”形式，因此，SIP代理服务器PRa就从定位服务DB的定位服务表60中检索与上述IP地址“192.0.2.4”相对应的AOR(SIP-URI)(S5)。SIP代理服务器PRa从定位服务表60一取得AOR“sv1@bbb.com”(S6)，在向请求源客户机CL1a发送了图52中示出的连接中报文M6x之后，在与连接目的地服务器SV1b所属的域的SIP代理服务器PRb之间，执行用于相互认证和加密通信用参数设定的TLS磋商(S8)。连接中报文M6x的内容除了成为IP地址描述的To报头以外，与图19中示出的第一实施例的连接中报文M6相同。
SIP代理服务器PRa一结束与SIP代理服务器PRb之间的TLS磋商，就对SIP代理服务器PRb发送图53中示出的连接请求报文M7x。连接请求报文M7x在从客户机CL1a接收到的连接请求报文M5x中附加包含SIP代理服务器PRa的SIP-URI的Via报头，成为将起始行的Request-URI从IP地址“192.0.2.4”重写为SIP-URI“sv1@bbb.com”的内容。以下执行与第一实施例同样的通信顺序，直至应用程序间的数据通信状态(S20)。
从SIP代理服务器PRb向SIP代理服务器PRa发送的连接中报文M8x、从SIP代理服务器PRb向连接目的地服务器SV1b发送的连接请求报文M9x、从服务器SV1b向SIP代理服务器PRb发送的连接响应报文M10x、从SIP代理服务器PRb向SIP代理服务器PRa发送的连接响应报文M11x、从SIP代理服务器PRa向请求源客户机CL1a发送的连接响应报文M12x、从客户机CL1a向SIP代理服务器PRa发送的连接确认报文M13x、从SIP代理服务器PRa向SIP代理服务器PRb发送的连接确认报文M14x、从SIP代理服务器PRb向服务器SV1b发送的连接确认报文M15x，除了成为IP地址描述的To报头以外，各自成为与第一实施例中例示的SIP报文M8～M15相同的内容。
客户机CL1a一结束与服务器SV1b之间的应用数据通信，就对SIP代理服务器PRa发送图54中示出的断开请求报文M20x。断开请求报文M20x中，起始行的Request-URI和To报头，是用IP地址“sv1@192.0.2.4”指定了服务器SV1b。报头部及其他报头信息与图17和图18中示出的第一实施例的连接请求报文M5相同。
SIP代理服务器PRa一接收上述断开请求报文M20x，就在对请求源的客户机CL1a发送了断开中报文M21x之后，将断开请求报文M20x变换为图55中示出的断开请求报文M22x后，向SIP代理服务器PRb发送。断开中报文M21x除了成为IP地址描述的To报头以外，是与图31中示出的第一实施例的断开中报文M21相同的内容。断开请求报文M22x在从客户机CL1a接收的断开请求报文M20x中附加了包含SIP代理服务器PRa的SIP-URI的Via报头，去掉与SIP代理服务器PRa相对应的Route报头，成为将起始行的Request-URI从IP地址重写为SIP-URI的内容。
SIP代理服务器PRb一接收上述断开请求报文M22x，就在对SIP代理服务器PRa发送了断开中报文M23x之后，在断开请求报文M22x中附加新的Via报头，去掉与SIP代理服务器PRb相对应的Route报头，将起始行的Request-URI从SIP-URI重写为IP地址，作为断开请求报文M24x发送给服务器SV1b。断开中报文M23x和断开请求报文M24x，除了成为IP地址描述的To报头以外，成为与图33和图34中示出的第一实施例的SIP报文相同的内容。
服务器SV1b一接收断开请求报文M24x，就向SIP代理服务器PRb发送断开响应报文M25x。断开响应报文M25x，除了成为IP地址描述的To报头以外，成为与图35中示出的第一实施例的SIP报文相同的内容。上述断开响应报文M25x在SIP代理服务器PRb和SIP代理服务器PRa中接受与第一实施例同样的变换处理，最终作为断开响应报文M27x发送给请求源客户机CL1a。请求源客户机CL1a一接收上述断开响应报文M27x，就结束IPsec加密/解密，等待相同或另外的应用程序的新的包发送请求。
下面，参照图56～59，说明能进行本发明的第二实施例的加密通信的客户机CL1a和SIP服务器SIPa(SIP代理服务器PRa、域名注册管理机构RGa)的特征工作。
在第二实施例中，客户机CL1a的IPsec引擎31C和SA/SP控制部51C具有与第一实施例相同的功能。图56示出了在第二实施例中，在从SA/SP控制部51C接收了连接请求报文的正文部时，客户机CL1a的SIP报文处理部53C执行的控制工作的流程图110x。
SIP报文处理部53C从SP/SA控制部51C一接收连接请求报文的正文部M5-2，就将第二ID有效负荷的ID数据所示的连接目的地服务器的IP地址适用在起始行的Request-URI和To报头中，制成由报头部M5x-1和从SP/SA控制部51C接收到的正文部M5-2构成的、图51中例示的连接请求报文M5x(111x)。
SIP报文处理部53C通过TSL部52C、TCP/IP部30C和NIC部20C，将上述连接请求报文发送给SIP服务器SIPa的SIP代理服务器PRa(117)，等待来自SIP代理服务器PRa的响应(118)，在从SIP代理服务器PRa接收了连接中报文M6的情况下，在执行了连接中报文处理(119)之后，进一步等待来自SIP代理服务器PRa的响应。
SIP报文处理部53C从SIP代理服务器PRa一接收连接响应报文M12x，就分析接收报文(120)，将从接收报文中抽出的图24中例示的连接响应报文正文部M12-2提供给SP/SA控制部51C(121)。之后，SIP报文处理部53C制成连接确认报文M13x，将该报文通过TSL部52C、TCP/IP部30C和NIC部20C发送给SIP代理服务器PRa(122)，并结束该过程。
图57示出在从客户机CL1a接收了连接请求报文M5x时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图300x的特征部分。
SIP代理服务器PRa的SIP报文处理部53P一接收来自客户机CL1a的连接请求报文M5x，就分析接收报文(步骤301)，检验接收报文的起始行中记述的Request-URI(302)，判定Request-URI是否包含域名(330)。在Request-URI包含域名的情况下，即，成为“sips：用户名@域名”形式的记述的情况下，就在步骤303中，根据Request-URI的域名，判定连接请求报文的传送目的地。
在Request-URI不包含域名、即成为“sips：IP地址”形式的记述的情况下，就将上述Request-URI示出的连接目的地服务器SV1b的IP地址作为检索关键字，制成定位数据检索询问(331)，将该检索询问发送给定位服务器LSV(332)，等待来自定位服务器的响应(333)。SIP报文处理部53P从定位服务器LSV一接收连接目的地服务器SV1b的SIP-URI作为定位数据，就适用该SIP-URI，将从客户机CL1a接收到的连接请求报文M5x的Request-URI从IP地址重写为SIP-URI，并附加包含自身的SIP-URI的Via报头和Record-Route(334)，在步骤303中，根据Request-URI的域名，判定连接请求报文的传送目的地。步骤303以后的工作与在图41(图41A～图41D)中说明的第一实施例相同。
图58示出在客户机CL1a中，在从SA/SP控制部51C接收了断开请求报文的发行请求时，SIP报文处理部53C执行的控制工作的流程图140x。
SIP报文处理部53C从SA/SP控制部51C一接收断开请求报文的发行请求，就在起始行的Request-URI和To报头中适用当前通信中的服务器SV1b的IP地址“sv1@192.0.2.4”，制成图54中例示的断开请求报文M20x(步骤141x)，通过TLS部52C、TCP/IP部30C的IPsec引擎31C、NIC部20C，发送给SIP服务器SIPa(SIP代理服务器PRa)(142)。
SIP报文处理部53C等待来自SIP代理服务器PRa的响应(143)，在接收了断开中报文M21x的情况下，执行断开中报文处理(144)后，等待来自SIP代理服务器PRa的下一个响应。SIP报文处理部53C从SIP代理服务器PRa一接收断开响应报文M27x，就分析接收报文(145)，向SP/SA控制部51C通知接收断开响应报文(146)，结束该过程。
图59示出在从客户机接收了断开请求报文M20x时，SIP代理服务器PRa的SIP报文处理部53P执行的控制工作的流程图340x。
SIP报文处理部53P分析接收到的断开请求报文M20x(步骤341)，检验接收报文的Request-URI(342)，判定Request-URI是否包含域名(360)。在Request-URI包含域名的情况下，就根据域名来判定接收报文的传送目的地。(343)。在Request-URI不包含域名、即成为“sips：IP地址”形式的记述的情况下，就在接收连接请求报文时适用在图57的步骤331～333中取得的连接目的地服务器的SIP-URI，重写上述断开请求报文M20x的Request-URI(361)，根据该Request-URI所示的域名，判定接收报文的传送目的地(343)。步骤343以后的工作与在图46(图46A～图46C)中说明的第一实施例相同。
如上所述，第二实施例的SIP代理服务器PRa的特征在于，SIP报文处理部53P如图9所示地具有用于将接收SIP报文的Request-URI所示的IP地址变换为SIP-URI的SIP-URI(AOR)检索功能54。
下面，参照图60～图67，说明本发明涉及的加密数据通信的第三实施例。
第三实施例的特征在于，在按照用IP地址指定了连接目的地服务器的形式产生了包发送请求时，客户机CL1a的SIP报文处理部53C使用上述IP地址，向连接目的地服务器询问SIP-URI，通过在Request-URI中记述从连接目的地服务器取得的SIP-URI，来发行能在SIP代理服务器侧、根据接收报文来判定连接目的地域的形式的连接请求报文。
图60示出第三实施例的客户机CL1a具有的基本软件结构，图61示出了连接目的地服务器SV1b具有的基本软件结构。
与图7、图8相比，其不同点在于，客户机CL1a的SIP报文处理部53C和服务器SV1b的SIP报文处理部53S各自具有用于进行SIP-URI请求/响应报文的通信的AOR解决功能55C、55S，服务器SV1b的SIP报文处理部53S具有AOR解决功能55S所参照的定位表70。上述定位表70如图62所示，示出了服务器SV1b的AOR(SIP-URI)71与IP地址72的对应关系。
图63示出第三实施例的加密数据通信的时序图。
在此，在从客户机CL1a发行连接请求之前，在管理客户机CL1a的所属域的SIP代理服务器PRa与管理连接目的地服务器SV1b的所属域的SIP代理服务器PRb之间，已经执行了用于相互认证和加密通信的参数设定的TLS磋商(步骤S0)，在连接目的地服务器SV1b与域名注册管理机构RGb之间，已经执行了TLS磋商(S1)和定位的登记过程。但是，如第一、第二实施例的步骤S8所示，也可以在从客户机CL1a发生了连接请求的时候，根据需要执行SIP代理服务器间的TLS磋商(S0)。
在本实施例中，在客户机CL1a中，在产生了用IP地址指定了服务器SV1b的连接时，SIP报文处理部53C直接给服务器SV1b发送AOR取得请求报文M30，服务器SV1b的SIP报文处理部53S响应上述AOR取得请求报文M30的接收，回送表示服务器SV1b的SIP-URI“sv1@bbb.com”的AOR取得响应报文M40。
AOR取得请求报文M30例如如图64所示，在起始行中，作为报文种类记述着“GETAOR”，作为Request-URI记述着服务器SV1b的IP地址“192.0.2.4”。此外，作为接在起始行后面的报头信息，包括：包含客户机CL1a(SIP报文处理部53C)的识别信息的Via报头、包含服务器SV1b的IP地址的To报头、包含客户机CL1a(SIP报文处理部53C)的SIP-URI的From报头、Call-ID报头、CSeq报头、Content-Length报头。AOR取得请求报文M30中没有正文部，Content-Length成为0。
AOR取得响应报文M40如图65所示，在起始行中包含表示响应报文的报文种类“200 OK”。此外，作为报头信息，包含与AOR取得请求报文M30相同内容的Via报头、To报头、From报头和CSeq，利用AOR报头表示出作为目的AOR的服务器SV1b的SIP-URI值“sv1@bbb.com”。
客户机CL1a的SIP报文处理部53C一接收上述AOR取得响应报文M40，就制成在Request-URI中适用了服务器SV1b的SIP-URI的连接请求报文M5，通过TLS部52C、IPsec引擎30C和NIC部20C向SIP代理服务器PRa送出。这时，TLS部52C在与SIP代理服务器PRa之间执行了TLS磋商(S7)之后，将连接请求报文M5加密后向SIP代理服务器PRa发送。
SIP代理服务器PRa一接收连接请求报文M5，就与第一实施例同样，在向请求源客户机CL1a发送了连接中报文M6之后，将连接请求报文M7发送给SIP代理服务器PRb。以后的过程与图12中说明的第一实施例相同。
图66示出在第三实施例的客户机CL1a中，在从SP/SA控制部51C接收了连接请求报文的正文部时，SIP报文处理部53C执行的控制工作的流程图110y。
SIP报文处理部53C从SP/SA控制部51C一接收连接请求报文的正文部，就根据第二ID有效负荷的ID数据所示的连接目的地服务器SV1b的IP地址、和SIP报文处理部53C所管理的通信控制参数，制成图64中例示的AOR取得请求报文M30(步骤111y)，将该报文通过TCP/IP部30C和NIC部20C，发送给服务器SV1b(112y)。该情况下，由于AOR取得请求报文M30不经由TLS部52C，因此，不执行与服务器SV1b之间的TLS磋商，AOR取得请求报文M30作为没被加密的普通报文，向目的地服务器SV1b发送。
SIP报文处理部53C等待来自服务器SV1b的AOR取得响应报文(113y)，一接收AOR取得响应报文M40，就分析接收报文(114)，从AOR报头抽出分配给连接目的地服务器的SIP-URI(115)。之后，SIP报文处理部53C将上述SIP-URI适用在起始行和To报头中，制成由报头部M5-1和从SP/SA控制部51C接收到的正文部M5-2构成的图17中例示的连接请求报文M5(116)。以后的处理过程与图39中说明的第一实施例相同。
图67示出在从客户机接收了AOR取得请求报文M30时，服务器SV1b的SIP报文处理部53S执行的控制工作的流程图450。
服务器SV1b的SIP报文处理部53S一接收AOR取得请求报文M30，就分析接收报文(步骤451)，从定位表70中取得与接收报文的To报头所示的IP地址相对应的AOR值(SIP-URI)(452)。SIP报文处理部53S在AOR报头中设定取得的AOR值，制成AOR取得响应报文M40(453)，将其发送给AOR取得请求报文M30的发送源即客户机(454)，结束该过程。
在以上的实施例中，说明了在结束加密数据通信时、从客户机CL1a侧发行断开请求时的通信顺序，但由于服务器SV1b所属的SIP代理服务器PRb也具有与客户机侧的SIP代理服务器PRa同样的功能，因此，在从服务器SV1b发行了取得请求的情况下，仅是报文的发送方向相反，结果也执行与实施例同样的过程。
此外，在实施例中，说明了从属于第一域的客户机CL1a向属于第二域的服务器SV1b发行了连接请求时的通信顺序，但在第一实施例中，在客户机CL1a结束了与服务器SV1b的通信之后，启动与另外的服务器例如服务器SV2b(或服务器SV1a)的通信的应用程序的情况下，在客户机CL1a与域名注册管理机构RGa之间、和客户机CL1a与SIP代理服务器PRa之间，就处于用于加密通信的条件设定已经结束的状态。从而，在从应用程序产生了数据的发送请求时，TLS部52C就能省略与SIP服务器SIPa之间的TLS磋商，立即加密从SIP报文处理部53C接收到的AOR取得请求报文或连接请求报文后，向网络NW1发送。
再有，在实施例中，在SIP报文的Request-URI或To报头中适用IP地址时，例如，如图15和图51的“sips：192.0.2.4”所示地进行了记述。该情况下，可以根据在接收了SIP报文的SIP代理服务器、域名注册管理机构或服务器侧，接在注目字段中的“sips：”后面的字符串是否成为用点分隔成3位以下的数字的IP地址记号，来判定是SIP-URI记述还是IP地址记述。为了准确地判定是SIP-URI记述还是IP地址记述，例如，也可以如“sips：192.0.2.4；id＝ipv4”那样，使用URI参数来明示是AOR解决所需的SIP-URI。此外，例如，也可以如“ipv4：192.0.2.4”那样，约定在注目字段中检测出IPv4(或IPv6)的方案(scheme)的情况下、在其后面记述着IP地址。