专利名称：数据通信系统的制作方法
技术领域：
本发明涉及数据通信方法及系统，特别是涉及利用对话管理服务器装 置、可以在通信装置间进行数据通信的数据通信方法及系统。
背景技术：
在进行2个NTT (指例如装置、或在装置上执行软件从而进行具体化 的进程)间的数据通信时，为了进行使该数据通信可行或切断这样的数据 通信的控制，有时使用与数据通信独立的控制用通信协议。例如，在IP电 话中，作为控制用通信协议广泛使用所谓SIP (Session Initiation Protocol:对话启动协议)的协议(对于SIP的详细情况参照IETF, RFC3261 : SIP : Session Initiation Protocol ， http:〃www.ietf.org/rfc/rfc3261.txt (以下，称为文献l))。
下面，简单地说明在SIP中，利用对通信装置间确立的通信对话进行 管理的对话管理服务器，第一通信装置确立与第二通信装置之间的通信对 话(以下，仅称为对话)，可以进行数据通信时的步骤。
并且，在本说明书中，所谓对话是指在通信装置间进行的一连串数据 通信顺序。例如，以SIP中的INVITE消息和对应的200OK和ACK消息 的往返为开始，对应于BYE消息的200OK消息的往返为结束。
首先，第二通信装置在通信对话确立处理之前将该通信装置的IP地址 登记在对话管理服务器中。S口，该通信装置向对话管理服务器发送登记请 求消息(还称为REGISTER消息)，该登记请求消息包含用于在对话管理 服务器中识别该通信装置或通信装置的用户的识别符(还称为SIP—URD、 和该通信装置的IP地址。对话管理服务器将记载于登记请求消息中的识别 符和IP地址对应记录。
而且，记录在对话管理服务器中的、某个通信装置的识别符和IP地址 的对应，当经过了对应被记录时设定的有效期间时被删除。此外，还可以
通过该通信装置发送登录删除请求消息(例如，在上述REGISTER消息中 指示将对应的有效期间设定为O)来删除。
另外，在本说明书中，将某个通信装置(NTT)的识别符和IP地址对 应记录在对话管理服务器的状态还称为该通信装置登录到对话管理服务 器，将未记录的状态还称为该通信装置从对话管理服务器注销。S卩，这里， 第二通信装置成为登录到对话管理服务器的状态。
同样地，第一通信装置也在对话确立处理之前进行向对话管理服务器 的登录。
接着，第一通信装置进行与第二通信装置的对话确立。
艮P，第一通信装置向对话管理服务器发送请求与第二通信装置确立对 话的连接请求消息(以下，也称为INVITE消息)。在该INVITE消息中记 载有第一通信装置的识别符和第二通信装置的识别符。接收到INVITE消 息的对话管理服务器向第二通信装置传输该INVITE消息。接收到INVITE 消息的第二通信装置在受理该连接请求时，向对话管理服务器发送表示其 意思的响应消息(也称为200OK消息)。该对话管理服务器将接收到的 2000K消息向第一通信装置传输。通过第一通信装置接收该响应消息，从 而在与第二通信装置之间确立通信对话。
以上是在SIP中至第一通信装置利用对话管理服务器确立与第二通信 装置之间的对话并可以进行数据通信为止的步骤。
SIP从其扩展性的高度出发，不停留于IP电话，在瞬时消息服务或内 容发布服务等各种多媒体服务中作为在用户与内容提供者之间的控制用通 信协议利用。此外，在NGN即下一代网络(Next Generation Network) 作为其网络的基础而利用的IMS (IP Multimedia Subsystem: IP多媒体 子系统)中也利用SIP。
IMS是用于实现在IP网络上的内容发布或IP电话等多媒体服务的通 信体系。在构成IMS的因素中具有中心作用的是称为呼叫对话控制功能 (CSCF: Call Session Control Function)的SIP服务器装置。
CSCF与连接至IMS的用户侧通信装置或服务侧通信装置、或者向IMS 内的节点提供各种功能的应用程序服务器装置(Application Server,以 下称为AS)等，利用SIP进行数据通信。存在如下三种CSCF:处理来自
用户的访问的P-CSCF (Proxy —CSCF)、成为与其它网络的通道的 I-CSCF(Interrogating — CSCF)、以及进行对话控制的S-CSCF( Serving —CSCF)。
I-CSCF及S-CSCF利用Diameter协议与存储用户信息或过滤准则 的归属用户服务器(Home Subscriber Server,以下称为HSS)装置进 行数据通信。Diameter是用于AAA (认正/授权/记帐)的协议。过滤准则 是S-CSCF与收取的消息内容进行对比、记述了用于判断该消息的处理是 否需要利用哪一个AS的条件的数据(对于IMS的详细情况参照3GPP， 3GPP TS 23.228: IP Multimedia Subsystem (IMS) Stage 2， http:〃www.3gpp.org/ftp/Specs/ html-info/ 23228.htm (以下称为文 献2))。
提供多媒体服务的内容提供者根据提供服务的种类要求对提供服务的 通信装置(服务侧通信装置)安装对服务的访问控制功能或用户与服务之 间的加密通信中使用的对话密钥的生成功能等、对话确立中需要的功能。
但是，将对话确立中需要的各功能搭载于每个服务侧通信装置的情况 下，产生各服务侧通信装置上的软件开发或安装、维护等的工作花费很多 成本的问题。而且，各服务侧通信装置为了实现对话确立中需要的各功能 需要较多的计算资源，并且应管理的数据量也增加。
为了解决该问题考虑了如下方法不在各服务侧通信装置中配置对话 确立中所需的单一至多个处理，而向对话管理服务器或与对话管理服务器 协同工作的服务器配置，从而实现功能的一元化。
例如，在IMS中，作为SIP服务器的AS进行QoS控制或密钥生成等 附加性的服务，从而可以减轻服务侧通信装置的负担。
此外，在(日本)特开2005 — 284753号公报(称为文献3)中，作 为SIP服务器的对话管理服务器具有用于判断可否向用户提供服务的功能、 和在被判断为可以提供该服务时向服务侧通信装置发送对话设定请求数据 包的功能。
这里，对在文献3中用户侧通信装置经由SIP服务器与服务侧通信装 置之间确立对话为止的顺序(sequence)进行说明。SIP服务器最初接收 从用户侧通信装置向服务侧通信装置的INVITE消息。在由文献1制定的
SIP的标准步骤中，SIP服务器立即向服务侧通信装置传输该INVITE消息， 但是在文献3记载的步骤中，追加了该INVITE消息的传输之前向用户管 理服务器询问用户是否保有用户侧通信装置享受服务侧通信装置的服务的 权限的步骤。
权限判断的结果，用户保有上述权限的情况被传到SIP服务器时，SIP 服务器向服务侧通信装置传输INVITE消息。以后执行与文献3同样的步 骤，从而具有享受服务侧通信装置的服务的权限的用户利用的通信装置可 以与服务侧通信装置确立对话。
如上所示，在文献3中公开了如下方法通过每个服务侧通信装置不 具备服务提供的可否判断功能、而一元地安装在用户管理服务器上，从而 在服务侧通信装置中削减进行于用户管理处理的成本。
在专利文献1所示的方法中，对话管理服务器从用户侧通信装置接收 了 INVITE消息时，向服务侧通信装置传输该INVITE消息之前，待机直 到基于用户管理服务器的可否提供服务的判断处理结束为止。因此，该判 断处理所需的时间按原样反映到确立对话所需的整体时间上，在该处理需 要较长时间的状况下，存在确立对话也需要长时间的课题。
除此之外，服务侧通信装置由于服务器内部错误等原因而处于不能提 供服务的状态时，用户侧通信装置在可否提供服务的判断处理结束之后接 收其错误消息，因此，在该判断处理需要较长时间的状况下，存在对于与 用户的权限无关的错误消息也花费用户的等待时间的课题。
发明内容
由于对话确立所需的处理中的一个处理结果影响其它处理，所以本发 明提供一种通过并行进行过去等待其它处理结果而依次处理的多个处理、 从而可縮短处理时间的数据通信系统。
本发明提供一种数据通信系统，管理在通信装置间确立的对话的对话 管理服务器并行进行在通信装置间往返的该对话确立所需的通信消息的传 输处理、和向其它功能提供装置委托的该对话确立所需的处理。
具体地，本发明提供的对话管理服务器的主要特征在于，将从用户侧 通信装置接收的请求对话确立的INVITE消息的传输处理、与该用户是否
具有利用确立的对话享受服务用的权限的询问或处理请求并行，例如在接 收这些结果之前进行。询问或请求处理的对象也可以是功能提供服务器等 其它装置。
具体地，本发明的对话管理服务器从进行用户的权限判断的权限判断 服务器或生成对话密钥的密钥生成服务器等、进行对话确立所需的处理的 各种功能提供服务器接收所请求的结果之前，向服务侧通信装置发送
INVITE消息。向功能提供服务器发送询问或处理请求的消息的定时，在 INVITE消息的发送之前或之后均无妨。
对话管理服务器从服务侧通信装置接收到对传输的INVITE消息的可 提供服务消息时，向服务侧通信装置发送对该可提供服务消息的响应消息， 在该响应消息的发送之后，若有还未接收的结果，则等待接收来自这些功 能提供服务器的结果。
此外，对话管理服务器从功能提供服务器作为对委托的处理的结果接 收到许可基于服务侧通信装置的服务提供的消息时，将对于该许可消息的 响应消息发送给功能提供服务器，在该响应消息的发送之后，若有未接收 的结果，则等待接收对于向功能提供服务器委托的处理、及/或向服务侧通 信装置发送的请求消息的结果。
根据如上所述的特征，在本发明中，在不确定用户侧通信装置是否保 有用于享受服务的权限的阶段，对话管理服务器向服务侧通信装置发送 INVITE消息。接收到该INVITE消息的服务侧通信装置根据由非专利文 献1制定的标准的SIP的步骤，向对话管理服务器发送作为响应的200OK 消息，转移到与用户侧通信装置之间完成对话确立的状态。
该处理不依赖于用户侧通信装置是否保有用于享受服务的权限而执 行，所以具有转移到服务侧通信装置向不保有权限的用户侧通信装置提供 服务的状态的可能性。
对此，在本发明中，排除服务侧通信装置向不保有权限的用户的通信 装置提供服务的可能性，所以确定了用户不保有用于享受服务的权限的情 况下，对话管理服务器对服务侧通信装置进行用于切断该对话的处理、例 如取消消息的发送。
具体地，对话管理服务器若能够确定用户不保有用于享受服务的权限
的情况，则向服务侧通信装置发送用于取消该对话确立的SIP消息。发送
的SIP消息根据服务侧通信装置的状态使用BYE消息或CANCEL消息。 此外，对话管理服务器从服务侧通信装置接收到接受请求的响应消息
之后，从功能提供服务器接收到为了接受服务提供所需的处理结果时，向
服务侧通信装置发送用于追加需要的信息的消息。
此外，从服务侧通信装置接收到对传输的请求消息的、拒绝提供服务
消息时，也可以向功能提供服务器发送对该功能提供服务器委托的处理的
取消消息。
对话管理服务器从服务侧通信装置及委托处理的所有功能提供服务器 接收响应，向服务侧通信装置发送需要的信息，在确认了服务侧通信装置 转移到可提供服务的状态的情况之后，向用户侧通信装置发送对请求消息 的响应消息。
根据上述方式，对话管理服务器并行进行在通信装置间往返的连接请 求消息及连接响应消息的传输处理、和向其它功能委托的对话确立所需的 处理，所以可以縮短对话的确立所需的时间。
并且，根据上述方式，对话管理服务器并行进行从通信装置发送的错 误消息的传输处理、和向其它功能委托的对话确立所需的处理，所以可以 縮短错误消息到达用户为止的时间。
进而，根据上述方式，用户侧通信装置在服务侧通信装置处于不能提 供服务状态时，用户发送对话确立请求消息之后到接收错误消息为止的等 待时间縮短。
根据本发明，可以高速进行利用与功能提供服务器协同工作的对话管 理服务器的可否提供服务判断处理。
图1是表示第一实施例的系统结构的图。
图2是例示第一、第二实施例中使用的各装置的硬件结构的框图。 图3是例示在第一实施例中用户侧通信装置41及服务侧通信装置42 进行对SIP服务器10的登录处理时的顺序的图。
图4是例示在第一实施例中用户侧通信装置41及服务侧通信装置42
登录之后的、SIP服务器10的处理流程的图。
图5是例示在第一实施例中用户侧通信装置41及服务侧通信装置42 登录之后的、SIP服务器10的处理流程的图。
图6是例示在第一实施例中用户侧通信装置41及服务侧通信装置42 登录之后的、SIP服务器10的处理流程的图。
图7是例示第一实施例的对话日志DB70、权限DB80、应用程序曰志 DB50中保存的信息的图。
图8是例示在第一实施例中SIP服务器10在权限判断服务器20、密 钥生成服务器40、服务侧通信装置42之间收发的消息的图。
图9是例示在第一实施例中计费服务器30接收的消息的图。
图10是例示在第一实施例中用户侧通信装置41从服务侧通信装置42 接收服务的提供时的顺序的图。
图11是例示在第一实施例中用户侧通信装置41切断与服务侧通信装 置42的对话时的顺序的图。
图12是例示在第一实施例中服务侧通信装置42拒绝向用户侧通信装 置41提供服务时的顺序的图。
图13是例示在第一实施例中服务侧通信装置42不能向用户侧通信装 置41提供服务时的顺序的图。
图14是例示在第一实施例中服务侧通信装置42不能向用户侧通信装 置41提供服务时的顺序的图。
图15是表示第二实施例的系统结构的图。
图16是表示第二实施例的系统结构的图。
图17是例示在第二实施例中服务侧通信装置42向用户侧通信装置41 提供服务时的顺序的图。
图18是例示在第二实施例中服务侧通信装置42向用户侧通信装置41 提供服务时的顺序的图。
图19是例示在第二实施例中服务侧通信装置42拒绝向用户侧通信装 置41提供服务时的顺序的图。
图20是例示在第二实施例中服务侧通信装置42拒绝向用户侧通信装 置41提供服务时的顺序的图。
图21是例示在第二实施例中服务侧通信装置42拒绝向用户侧通信装 置41提供服务时的顺序的图。
图22是例示在第二实施例中服务侧通信装置42不能向用户侧通信装 置41提供服务时的顺序的图。
图23是例示在第二实施例中服务侧通信装置42不能向用户侧通信装 置41提供服务时的顺序的图。
符号说明0、1:网络
10:SIP服务器
11、14: P-CSCF
12、15: I-CSCF
13、16: S-CSCF
20:权限判断服务器
21、22: HSS
30:计费服务器
31:密钥生成AS
32:权限判断AS
40:密钥生成服务器
41:用户侧通信装置
42:服务侧通信装置
50:应用程序DB
6〇注册DB
70:对话日志DB
80:权限DB
91:CPU
92:存储器
93:硬盘
94:网络接口
95:输入输出装置
具体实施例方式
以下，利用附图对本发明的实施方式进行说明。并且，本发明不通过 以下所述的实施方式进行限定。
此外，下面说明对SIP的应用例子，但是对于SIP以外的在确立通信
对话的情况下经由对话管理服务器收发对话确立请求消息或响应消息的那 样的系统也可以应用本发明。
而且，以下的各实施例的各装置例如包括在图2表示其结构例那样
的处理器(CPU) 91，用于存储在处理器91上执行的各种软件(程序) 和数据的存储器92及/或硬盘93，用于与网络0连接的网络接口 94，鼠 标、键盘等的输入装置，显示装置，以及包括外部存储介质的读写装置的 输入输出装置95;在各构成因素通过总线等内部通信线96相互连接的一 般的电子计算机上实现。
艮P，以下的各实施例的各装置具备的处理部和其处理通过在各装置中， 在需要的定时，处理器91执行存储于硬盘93或存储器92中的、实现上 述各处理部的程序，从而进行具体化。在以下的实施方式的说明中，为了 方便将处理部作为处理的执行主体说明。并且，有时将程序称为代码或模 块。
由处理器91执行的程序可以预先存储在各装置的硬盘93或存储器92 中，也可以在需要时通过该装置可利用的介质从其它装置导入上述存储部。 作为介质例如是指可以由输入输出装置95可利用的可拆卸的存储介质、或 者可以经由网络接口 94利用的通信介质(即，网络或在网络上传播的载波 或数字信号)。此外，也可以由集成电路等硬件构成上述各处理部。
此外，在以下的实施例中使用的域名、URL、 URI、 IP地址等识别符 是为了用于说明而虚构的，即使是实际存在的也无妨。消息 M112，则SIP服务器IO返回其它消息的等待接收状态(S309、 S315)。 这里，权限判断结果[许可]消息M112由权限判断服务器20的权限判断处 理部203制作，具有如图8例示的正文部。即，作为Permission因素的 status属性的值的accept表示权限判断的结果、即用户侧通信装置41保 有用于享受服务侧通信装置42的服务的权限，id属性的值358ala77与 该消息对应的权限判断请求消息中包含的id属性的值一致。
从权限判断服务器20接收到的权限判断结果消息是权限判断结果[拒 绝]消息M121时，即用户侧通信装置41不具有用于享受服务侧通信装置 42的服务的权限时，SIP服务器10立即转移到中断对话的确立的处理
(S309、 S315、 S316)。这里，权限判断结果[拒绝]消息M121由权限 判断服务器20的权限判断处理部203制作，具有如图8例示的正文部。 即，作为Permission因素的status属性的值的reject作为权限判断的结 果，表示用户侧通信装置41不具有用于享受服务侧通信装置42的服务的 权限，id属性的值358ala77与该消息对应的权限判断请求消息中包含的 id属性的值一致。
这里，对SIP服务器10用于中断对话确立的处理流程进行说明。
SIP服务器10的SIP消息处理部102为了表示用户侧通信装置41不 具有用于享受服务侧通信装置42的服务的权限的情况，生成作为SIP消息 的403Forbidden消息，向用户侧通信装置41发送(S50D。
SIP服务器10的应用程序处理部105向请求处理中的功能提供服务器 即这里是密钥生成服务器40发送密钥生成取消消息M122 (S502)。
接着，SIP服务器10的SIP消息处理部102进行用于取消向服务侧 通信装置42的连接请求的处理。对于该处理，在SIP服务器10己经从服 务侧通信装置42接收了对INVITE的200OK消息的情况、和不是这样的 情况下，步骤不同。以下，依次说明每一个。
首先，SIP服务器10从服务侧通信装置42已经接收到对INVITE的 200OK消息时，SIP服务器10的SIP消息处理部102向服务侧通信装置 42发送作为SIP消息的BYE消息，从而解除在与服务侧通信装置42之间 确立的SIP会话(S504)，结束处理(S505)。这里，BYE消息M124由 SIP消息处理部102制作，具有如图8例示的正文部。g卩，附加作为 Sessionlnfo因素的status属性的值的cancel,是为了明示该BYE消息 不是因为用于通知已经确立的对话的结束而发送的，而是用于中断仍未确 立的对话的确立处理而发送的情况。作为From因素的值的SIP—URI"sip: cll@hitachi.com " 及作为 To 因素的值的 SIP — URI "sip:svl@hitachi.com "表示为了中断从作为SIP-URI具有 sip:cll@hitachi.com的用户侧通信装置41向作为SIP-URI具有 sip:svl@hitachi.com的服务侧通信装置42的对话确立而发送了该BYE 消息M124的情况。关于Date因素的值与权限判断取消消息M145相同。
接着，SIP服务器10没有从服务侧通信装置42接收对INVITE的
200OK消息时，通过SIP消息处理部102向服务侧通信装置42发送 CANCEL消息，从而中断在与服务侧通信装置42之间尝试的对话确立。 (S506)
在步骤S506中，由于网络O上的通信障碍等理由，存在SIP服务器 10发送的CANCEL消息未到达服务侧通信装置42的可能性。未到达的情 况下，服务侧通信装置42继续进程启动处理等、用于对话确立的处理，向 SIP服务器10发送作为对INVITE的最终响应的200OK消息，所以从服 务侧通信装置42看来确立了与用户侧通信装置41之间的对话，成为对话 确立的中断不能实现的状态。
因此，SIP服务器10的SIP消息处理部102不管已经发送了 CANCEL 消息，从服务侧通信装置42接收到具有与先前发送的INVITE消息或 CANCEL消息相同的Call —ID标题、且在CSeq标题中包含文字列 "INVITE"的200OK消息时，通过向服务侧通信装置42发送BYE消息， 从而切断在与服务侧通信装置42之间确立的对话(S507、 S504)。这里 发送的BYE消息与图8所示的相同。发送BYE消息之后，SIP服务器10 结束处理(S505)。
向服务侧通信装置42发送CANCEL消息并经过了一定时间时，SIP 服务器10视为服务侧通信装置42接收到该CANCEL消息，结束处理 (S5〇8、 S505)。
以上是SIP服务器10从权限判断服务器20接收到权限判断结果消息 时的、SIP服务器10的处理流程。
另一方面，等待接收中的SIP服务器10从密钥生成服务器40接收到 密钥生成结果消息Ml 13时，SIP服务器10的应用程序处理部105将包 含在该密钥生成结果消息中的密钥信息保存在对话日志DB70中(S310、 S317)。艮P， SIP服务器10在对话日志DB70中，在与密钥生成结果消息 正文部M113 —1中包含的From因素的值、To因素的值、CallID因素的 值对应的表条目中，作为对话密钥信息记录包含在该密钥生成结果消息正 文部中的Key因素的值。这里，密钥生成结果消息M113由密钥生成服务 器40的密钥生成处理部403制作，具有如图8所示的正文部。即，作为 KeyGen因素的status属性的值的response表示该消息是为了传输密钥
生成的结果得到的密钥而发送的。From因素的值、To因素的值、CallID 因素的值与对应的密钥生成请求消息中包含的各因素的值一致。关于Date 因素的值，与权限判断取消消息M145相同。此外，作为Key因素的scheme 属性的值的AES256表示Key因素中包含的信息是密钥长度256比特的 AES算法中使用的密钥，Key因素内的OctetString因素的值表示对话密 钥信息。
以上是SIP服务器10从密钥生成服务器40接收到密钥生成结果消息 时的、SIP服务器10的处理流程。
当等待接收状态的SIP服务器10从服务侧通信装置42、权限判断服 务器20、密钥生成服务器40的所有服务器接收到消息时，转移到对话确 立的最终处理(S311、 S318)。
在对话确立的最终处理中，SIP服务器10最初确认应用程序处理部 105从功能提供服务器取得并记录到对话日志DB70中的信息中是否存在 应向用户侧通信装置及服务侧通信装置传达的信息(S601)D这里，应向 用户侧通信装置及服务侧通信装置传达的信息具体地是指由密钥生成服务 器40生成的对话密钥信息等。
存在应向用户侧通信装置及服务侧通信装置传达的信息的情况下，SIP 服务器10进行为了向用户侧通信装置41及服务侧通信装置42传达信息 所需的处理(S602、 S603)。
艮口， SIP服务器10最初向服务侧通信装置42发送UPDATE消息 (S602)。 UPDATE消息M114由SIP消息处理部102制作，将记录在 对话日志DB70中的密钥信息包含在正文部。
接着，当存在应向用户侧通信装置及服务侧通信装置传达的信息的情 况下，SIP服务器10的SIP消息处理部102对记录在对话日志DB70中 的密钥信息进行复制，并生成200OK消息M116的正文部(S603)。
以上是在存在应向用户侧通信装置及服务侧通信装置传达的信息的情 况下，SIP服务器10为了向各通信装置传达信息而进行的处理流程。
在对话确立的最终处理中，SIP服务器10的SIP消息处理部102在 从服务侧通信装置42接收的200OK消息M109的标题部除去包含自URI 的Via标题从而制作200OK消息M116的标题部，并向用户侧通信装置41发送(S604)。关于消息的正文部，在存在应向用户侧通信装置及服务 侧通信装置传达的信息时，利用在步骤S603中生成的正文部。在不存在 应向用户侧通信装置及服务侧通信装置传达的信息时，在正文部不包含信 息进行发送。
最后，SIP服务器10开始后面计费服务器30进行计费处理时使用的 对话日志的收集(S605)。艮卩，SIP服务器10的对话管理部104对于与 INVITE消息M101的From标题表示的通信源SIP—URI、 To标题表示 的通信目的地SIP—URI、和Call—ID标题表示的通信对话的识别信息对 应的条目，在对话日志DB70中记录当前时刻作为该通信对话的开始时刻。 图7表示保存在对话日志DB70中的对话日志信息的一例。
以上是SIP服务器10从完成了登录处理的用户侧通信装置41接收到 INVITE消息M101之后的SIP服务器10的处理流程。
接着，用图10到图14表示完成了登录处理的用户侧通信装置41向 服务侧通信装置42请求提供服务时的顺序。
首先，利用图10对用户侧通信装置41具有用于享受服务侧通信装置 42的服务的权限时的顺序进行说明。
首先，用户侧通信装置41向服务侧通信装置42请求提供服务时，用 户侧通信装置41向SIP服务器10发送作为SIP消息的INVITE消息 MlOl。
SIP服务器10从用户侧通信装置41接收到INVITE消息MlOl时， 根据处理流程S302，注册处理部103访问注册DB60检索接收到的 INVITE消息的To标题表示的接收者SIP—URI的IP地址。若发现登记 的用户侧通信装置41的IP地址，则SIP服务器10根据处理流程S305， 对话管理部104在对话日志DB70中与当前时刻一起记录通信源SIP — URI、通信目的地SIP—URI、通信对话的识别信息、和该通信对话处于"确 立处理中(等待来自通信目的地的响应)"状态(M102)。
接着，SIP服务器10根据处理流程S306向权限判断服务器20发送 权限判断请求消息M103,向密钥生成服务器40发送密钥生成请求消息 M104。此外，SIP服务器10根据处理流程S307向服务侧通信装置42 发送INVITE消息M105。
权限判断请求消息M103由应用程序处理部105制作，具有如图8所 示的正文部。
此外，密钥生成请求消息M104由应用程序处理部105制作，具有如 图8所示的正文部。
此外，INVITE消息M105由SIP消息处理部102在从用户侧通信装 置41接收到的INVITE消息M101的标题部追加新的Via标题，将Max —Forward标题的值减1来制作。
在从图10到图U中，SIP服务器10按照权限判断请求消息M103、 密钥生成请求消息M104、 INVITE消息M105的顺序发送消息，但是本 发明不限于该顺序。这些3个消息可以按任意的顺序发送。
接收到权限判断请求消息M103的权限判断服务器20由权限判断处理 部203对权限DB80进行权限信息的询问(M106)。
此外，接收到密钥生成请求M104的密钥生成服务器40由密钥生成处 理部403开始密钥生成处理(M107)。
此外，接收到INVITE消息M105的服务侧通信装置42由服务器处 理部423开始在服务的提供中所需的初始化处理(进程的启动等)(M108)。
服务侧通信装置42完成该初始化处理时，SIP消息处理部423生成作 为SIP消息的200OK消息M109,向SIP服务器10发送。
SIP服务器10从服务侧通信装置42接收到200OK消息M109时， 根据处理流程S313， SIP消息处理部102生成对该200OK消息的ACK 消息MllO，向服务侧通信装置42发送。
服务侧通信装置42从SIP服务器10接收到ACK消息M110时，服 务器处理部423开始收集对用户侧通信装置41的服务的提供记录(应用 程序日志)(Mlll)。应用程序日志被记录在应用程序日志DB50内。图7 表示保存在应用程序日志DB50中的应用程序日志信息的一例。
权限判断服务器20进行权限判断处理的结果，若确认用户侧通信装置 41具有用于享受服务侧通信装置42的服务的权限，则向SIP服务器10 发送权限判断结果[许可]消息M112。权限判断结果[许可]消息M112由 权限判断处理部203制作，具有如图8所示的正文部。
当密钥生成服务器40完成密钥生成处理时，向SIP服务器10发送密
钥生成结果消息M113。密钥生成结果消息M113由密钥生成处理部403 制作，具有如图8所示的正文部。
当SIP服务器10从密钥生成服务器40接收到密钥生成结果消息 M113时，根据处理流程S317，应用程序处理部105将该密钥生成结果消 息中包含的密钥信息保存在对话日志DB70中。
当SIP服务器10从服务侧通信装置42、密钥生成服务器40、权限判 断服务器20这三者中接收到消息时，根据处理流程S311转移到对话确立 的最终处理。
在本实施例中，作为应向用户侧通信装置及服务侧通信装置传达的信 息，存在由密钥生成服务器生成的对话密钥信息，所以SIP服务器10根据 处理流程S602，由SIP消息处理部102生成UPDATE消息M114，向服 务侧通信装置42发送。
当服务侧通信装置42从SIP服务器10接收到UPDATE消息M114 时，SIP消息处理部422取得在该UPDATE消息的正文部中包含的对话 密钥信息之后，向SIP服务器10发送对该UPDATE消息的2000K消息 M115，转移到可以向用户侧通信装置41提供服务的状态。
此外，根据处理流程S603， SIP服务器10由SIP消息处理部102 生成200OK消息M116的正文部，与在从服务侧通信装置42接收到的 200OK消息M109的标题部中除去包含自URI的Via标题从而生成的标 题部结合，作为200OK消息M116向用户侧通信装置41发送。
当用户侧通信装置41接收到200OK消息M116时，SIP消息处理部 412生成ACK消息M117，向SIP服务器10发送。
SIP服务器10从用户侧通信装置41接收到ACK消息M117时，根 据处理流程S605，对话管理部104开始向对话日志DB70收集用户侧通 信装置41和服务侧通信装置42之间的对话记录(对话日志)(M118)。
通过以上的步骤，在用户侧通信装置41和服务侧通信装置42之间确 立通信对话(M119)，可以进行从用户侧通信装置41向服务侧通信装置 42的访问、和从服务侧通信装置42向用户侧通信装置41的信息服务。用 户侧通信装置41和服务侧通信装置42之间的通信使用对话确立中得到的 对话密钥信息来加密。此外，到对话开放为止的期间，继续基于SIP服务
器10的对话日志的收集和基于服务侧通信装置42的应用程序日志的收集。
以上是用户侧通信装置41具有用于享受服务侧通信装置42的服务的
权限时的顺序。
在本顺序中，并行进行基于权限判断服务器20的权限判断处理M106、 基于密钥生成服务器的密钥生成处理M107及基于服务侧通信装置42的进 程启动处理等M108。因此，与一个一个依次进行各处理的过去的步骤相 比，具有可以縮短到通信开始所需的时间的效果。
接着，用图11对用户侧通信装置41向服务侧通信装置42请求对话 的切断时的顺序进行说明。
用户侧通信装置41向服务侧通信装置42请求对话的切断时，用户侧 通信装置41首先由SIP消息处理部412向SIP服务器10发送作为SIP 消息的BYE消息M301。
SIP服务器10从用户侧通信装置41接收到BYE消息M301时，对 话管理部104在对话日志DB70中与密钥生成结果消息正文部M113 — l 中包含的From因素的值、To因素的值、和CallID因素的值对应的表条 目中，记录该通信对话处于"切断处理中(等待来自通信目的地的响应)" 状态的情况。
接着，SIP服务器10由SIP消息处理部102在BYE消息M301的标 题部追加新的Via标题，通过将Max—Forward标题的值减1来制作BYE 消息M302，并向服务侧通信装置42发送。
服务侧通信装置42从SIP服务器10接收到BYE消息M302时，SIP 消息处理部422向SIP服务器IO发送作为对该BYE消息的响应的200OK 消息M303之后，服务器处理部423结束向用户侧通信装置41提供服务， 并且停止应用程序日志的收集。此外，SIP消息处理部422确认在接收到 的BYE消息M302的标题部是否包含status属性是cancel的Sessionlnfo 因素。在本顺序中，在BYE消息的正文部不包含该因素，所以服务侧通信 装置42生成应用程序日志信息消息M305，向计费服务器30发送。这里， 应用程序日志信息消息M305由服务器处理部423制作，具有如图9所示 的正文部。
SIP服务器10从服务侧通信装置42接收到200OK消息M303时，
SIP消息处理部102从该200OK消息的标题部除去包含自URI的Via标 题来制作200OK消息M304并向用户侧通信装置41发送。接着，对话管 理部104向与200OK消息M303的From标题所示的通信源SIP — URI、 To标题表示的通信目的地SIP—URI、和Call—ID标题表示的通信对话的 识别信息对应的对话日志DB70中的表条目中记录当前时刻作为对话结束 时刻，并停止对话日志的收集。
然后，SIP服务器IO生成在标题部包含对话日志信息的对话日志信息 消息M306，并向计费服务器30发送。这里，对话日志信息消息M306由 对话管理部104制作，具有如图9所示的正文部。
以上是用户侧通信装置41向服务侧通信装置42请求对话的切断时的 顺序。
接着，用图12说明用户侧通信装置41不具有用于享受服务侧通信装 置42的服务的权限的情况下、且比权限判断的结果先通知来自服务侧通信 装置42的200OK消息的情况下的顺序。
关于用户侧通信装置41向SIP服务器10发送INVITE消息M101之 后到服务侧通信装置42开始应用程序日志的收集(Mill)为止的顺序与 图10所示的顺序相同，所以省略说明。
然后，权限判断服务器20进行权限判断处理的结果，确认用户侧通信 装置41不具有用于享受服务侧通信装置42的服务的权限时，向SIP服务 器10发送权限判断结果[拒绝]消息M121。权限判断结果[拒绝]消息 M121由权限判断处理部203制作，并具有如图8所示的正文部。
SIP服务器10从权限判断服务器20接收到权限判断结果[拒绝]消息 M121时，根据处理流程S501， SIP消息处理部102生成作为SIP消息的 403Forbidden消息M122，并向用户侧通信装置41发送。
用户侧通信装置41从SIP服务器10接收到403Forbidden消息 M122时，SIP消息处理部412生成ACK消息M123并向SIP服务器10 发送。
SIP服务器10向用户侧通信装置41发送403Forbidden消息M122 之后，根据处理流程S502向密钥生成服务器40发送密钥生成取消消息 M124。密钥生成取消消息M124由应用程序处理部105制作，具有如图8所示的正文部。
密钥生成服务器40从SIP服务器10接收到密钥生成取消消息M124 时，密钥生成处理部403结束处于处理中的密钥生成处理。接着，消息处 理部402生成密钥生成取消响应消息M125，向SIP服务器10发送。这 里，密钥生成取消响应消息M125具有如图8所示的正文部。
这里，用图8对密钥生成取消响应消息正文部M125 — 1的一例进行说 明。作为KeyGen因素的status属性的值的canceled表示该消息是作为 对密钥生成的取消请求的响应而发送的。KeyGen因素的内容与对应的密 钥生成取消消息正文部M124 — 1的KeyGen因素的内容相同。
接着，SIP服务器10根据处理流程S503，判断是否从服务侧通信装 置42接收到200OK消息。在本顺序中，处理在该时刻从服务侧通信装置 42接收到200OK消息的情况，所以根据处理流程S504，向服务侧通信装 置42发送BYE消息M126。 BYE消息M126由SIP消息处理部102生 成，具有如图8所示的正文部。
服务侧通信装置42从SIP服务器10接收到BYE消息M126时，SIP 消息处理部422生成作为对该BYE消息的响应的200OK消息M127，向 SIP服务器10发送。接着，服务侧通信装置42由服务器处理部423结束 向用户侧通信装置41的可提供服务状态，并且停止应用程序日志的收集。 此外，SIP消息处理部422确认在接收的BYE消息M126的正文部是否包 含status属性为cancel的Sessionlnfo因素。在本顺序中，该因素包含 在BYE消息的正文部，所以服务侧通信装置42不向计费服务器30发送 应用程序日志信息消息,
最后，SIP服务器10从服务侧通信装置42接收对BYE消息的200OK 消息M127，结束处理。
以上是用户侧通信装置41不具有用于享受服务侧通信装置42的服务 的权限的情况下、且来自服务侧通信装置42的200OK消息比权限判断的 结果先通知的情况下的顺序。
在本顺序中，其特征在于，在为了消除暂时在SIP服务器IO和服务侧 通信装置42之间确立的SIP会话而使用的BYE消息的正文部中，包含表 示用户侧通信装置41未能确立对话的信息(图8的BYE消息正文M126
一l表示的、作为Sessionlnfo因素的status属性的值的cancel)。通过 包含该信息，服务侧通信装置42可以判断接收到的BYE消息是为了结束 对话而发送的，或者为了表示对话确立处理在中途中断而发送的。由此， 防止向计费服务器30发送不需要的应用程序日志，作为结果具有防止发生 不当的计费处理的效果。
接着，用图13对用户侧通信装置41不具有用于享受服务侧通信装置 42的服务的权限的情况、且权限判断的结果比来自服务侧通信装置42的 200OK消息先通知的情况的顺序进行说明。
从用户侧通信装置41向SIP服务器10发送INVITE消息M101之后 到服务侧通信装置42开始进程启动处理等(M108)为止的顺序，与图10 所示的顺序相同，所以省略说明。
然后，权限判断服务器20由权限判断处理部203在服务侧通信装置 42发送200OK消息之前完成权限判断处理，确认用户侧通信装置41不 具有用于享受服务侧通信装置42的服务的权限时，向SIP服务器10发送 权限判断结果[拒绝]消息M121。权限判断结果[拒绝]消息M121由消息 处理部202制作，具有如图8所示的正文部。
SIP服务器10从权限判断服务器20接收到权限判断结果[拒绝]消息 M121时，根据处理流程S5〇l， SIP消息处理部102发送403Forbidden 消息M122。
用户侧通信装置41从SIP服务器10接收到403Forbidden消息 M122时，SIP消息处理部412生成ACK消息M123，向SIP服务器10 发送。
SIP服务器10向用户侧通信装置41发送403Forbidden消息M122 之后，根据处理流程S502，向密钥生成服务器40发送密钥生成取消消息 M124。密钥生成取消消息M124由应用程序处理部105生成，具有如图 8所示的正文部。
密钥生成服务器40从SIP服务器10接收到密钥生成取消消息M124 时，密钥生成处理部403结束处于处理中的密钥生成处理。接着，消息处 理部402生成密钥生成取消响应消息M125，向SIP服务器10发送。这 里，密钥生成取消响应消息M125具有如图8所示的正文部。
接着，SIP服务器10根据处理流程S503，判断是否从服务侧通信装
置42接收到200OK消息。在本顺序中，处理在该时刻仍未从服务侧通信 装置42接收200OK消息的情况，所以根据处理流程S506， SIP消息处 理部422向服务侧通信装置42发送作为SIP消息的CANCEL消息M131 。
服务侧通信装置42从SIP服务器10接收到CANCEL消息M131时， SIP消息处理部422生成作为对该CANCEL消息的响应的200OK消息 M132，向SIP服务器IO发送。
接着，服务侧通信装置42由SIP消息处理部422向SIP服务器10 发送SIP最终响应消息即487 Request Terminated消息。
SIP服务器10从服务侧通信装置42接收到对CANCEL消息M131 的2000K消息M132时，根据处理流程S508、 S505结束处理。
接着，用图14对服务侧通信装置42成为不能提供服务的状态时的顺 序进行说明。
对于从用户侧通信装置41向SIP服务器10发送INVITE消息M101 到SIP服务器10向服务侧通信装置42发送INVITE消息M105为止的顺 序，与图10所示的顺序相同，所以省略说明。
接着，为了传达服务侧通信装置42因任意的理由成为不能提供服务的 状态的情况，SIP消息处理部422向SIP服务器10发送SIP错误响应消 息M141。例如，服务侧通信装置42发送作为SIP消息的486Busy Here 消息，从而可以通知服务侧通信装置42已经与其它用户侧通信装置确立多 个对话、并且处于不能再确立新的对话的状况的情况。
SIP服务器10接收到SIP错误响应消息M141时，根据处理流程 S401， SIP消息处理部102向服务侧通信装置42发送ACK消息M142。
接着，SIP服务器10根据处理流程S402，由SIP消息处理部102在 从服务侧通信装置42接收到的SIP错误响应消息M141的标题部中除去 包含自URI的Via标题来生成SIP错误响应消息M143，向用户侧通信装 置41发送。
用户侧通信装置41从SIP服务器10接收到SIP错误响应消息M143 时，SIP消息处理部412向SIP服务器10发送ACK消息M144。
接着，SIP服务器10根据处理流程S403，向功能提供服务器发送用
于取消处理请求的消息。在本顺序中，作为请求处理中的功能提供服务器 存在权限判断服务器20及密钥生成服务器40。
首先，SIP服务器10由应用程序处理部105生成权限判断取消消息 M145，向权限判断服务器20发送。权限判断取消消息M145具有如图8 所示的正文部。
权限判断服务器20从SIP服务器10接收到权限判断取消消息M142 时，权限判断处理部203结束处于处理中的权限判断处理。接着，消息处 理部202生成权限判断取消响应消息M146，向SIP服务器10发送。权 限判断取消响应消息M146具有如图8所示的正文部。
这里，用图8对权限判断取消响应消息正文部M146 — l的一例进行说 明。作为Permission因素的status属性的值的canceled表示该消息是作 为对权限判断的中断请求的响应而发送的，id属性的值358ala77与该消 息对应的权限判断中断消息中包含的id属性的值一致。Permission因素 的内容与对应的权限判断中断消息正文部M142—1的Permission因素的 内容相同。
此外，SIP服务器10由应用程序处理部105生成密钥生成取消消息 M124，向密钥生成服务器40发送。密钥生成取消消息M124具有如图8 所示的正文部。
密钥生成服务器40从SIP服务器10接收到密钥生成取消消息M124 时，密钥生成处理部403结束处于处理中的密钥生成处理。接着，消息处 理部402生成密钥生成取消响应消息M125，向SIP服务器10发送。这 里，密钥生成取消响应消息M125由密钥生成处理部403生成，具有如图 8所示的正文部。
SIP服务器10从权限判断服务器20接收权限判断取消响应消息 M146，并且从密钥生成服务器40接收密钥生成取消响应消息M123，结 束处理。
在本顺序中，在执行权限判断处理或密钥生成处理的期间，SIP服务器 10可以接收来自服务侧通信装置42的SIP错误响应消息，并且可以向用 户侧通信装置41传输该SIP错误响应消息。因此，具有以下效果，即用户 侧通信装置41可以比过去的步骤早知道服务侧通信装置42处于不能提供
服务的状态的情况。
以上是服务侧通信装置42为不能提供服务的状态时的顺序。
在本实施例中，与过去的步骤相比，接收到INVITE消息的服务侧通 信装置42能够与基于权限判断服务器20的权限判断处理和基于密钥生成 服务器40的密钥生成处理并行执行进程启动处理等提供服务所需的初始 处理。因此，具有縮短到对话确立为止所需的时间的效果。
而且，在本实施例中，在对话确立中从功能提供服务器提供的信息中 不存在应向用户侧通信装置及服务侧通信装置传达的信息时，SIP服务器 10不需要发送UPDATE消息M114，并且，服务侧通信装置不需要发送 对UPDATE消息的200OK消息M115。具体地，在各通信装置内或SIP 服务器上进行密钥生成处理的系统的情况下，不需要本实施例中使用的密 钥生成服务器，不存在应向用户侧通信装置及服务侧通信装置传达的信息。 因此，可以省略UPDATE消息及200OK消息的收发处理，可以实现更高 速的对话确立。
并且，在本实施方式中，作为分别不同的独立的装置进行说明的功能 提供服务器的每一个和对话管理服务器，任意的两个以上作为一个装置实 现也无妨。功能提供服务器包含在对话管理服务器装置中的情况下，不需 要其IP地址，多个功能提供服务器结合为一个时，具有共同的IP地址和 不同的端口号。
此外，在本实施例中，权限判断服务器20对用户用于享受由服务侧通 信装置提供的服务的权限进行判断，但是，作为该例子的变形，也可以在 权限判断服务器20中对于用户侧通信装置与服务侧通信装置确立对话用 的权限进行判断，由各服务侧通信装置进行对于用户用于享受在该对话上 提供的服务的权限判断的构成。
接着，参照从图15到图23对基于本发明的数据通信的第二实施例进 行说明。
在第二实施例中表示在作为Application Server (应用程序服务器， AS)向IMS体系上配置进行用户的权限判断或对话密钥的生成的功能提供 服务器的系统中，S—CSCF并行进行INVITE消息的传输和对AS的处理
请求消息的发送，从而縮短到对话确立为止所需的时间的过程。
图15及图16中示出结构的第二实施例的系统，在网络0和网络1的 两个网络上构成。网络0和网络1由路由器等连接，在两网络上存在的装
置可以互相进行通信。在网络0上存在P-CSCFll、 I—CSCF12、 S— CSCF13、 HSS21、进行密钥生成的应用程序服务器即密钥生成AS31、以 及用户侧通信装置41。此外，在网络1上存在P-CSCF14、 I一CSCF15、 S — CSCF16、进行用户信息的管理的HSS22、进行权限判断的应用程序 服务器即权限判断AS32、以及服务侧通信装置42。
P—CSCFll分配有192.168.11.11的IP地址。P—CSCFll作为其 功能例如包括用于经由网络0与其它CSCF及通信装置通信的网络接口卡 部(NIC) 111、处理SIP消息的SIP消息处理部112、处理Diameter消 息的Diameter消息处理部113、以及基于来自各通信装置的请求处理SIP 消息的传输等的P—CSCF处理部114。
P — CSCF14分配有192.168.14.11的IP地址。P — CSCF14的功能 构成与P—CSCF11相同，所以省略说明。
I—CSCF12分配有192.168.12.11的IP地址。I—CSCF12作为其功 能例如包括用于经由网络0与其它CSCF及通信装置通信的网络接口卡部 (NIC) 121、处理SIP消息的SIP消息处理部122、处理Diameter消息 的Diameter消息处理部123、以及进行网络内的S — CSCF的检索等的I 一CSCF处理部124。
I一CSCF15分配有192.168.15.11的IP地址。I—CSCF15的功能构 成与1—CSCF12相同，所以省略说明。
S—CSCF13分配有192.168.13.11的IP地址。S — CSCF13作为其 功能例如包括用于经由网络0与其它CSCF及通信装置通信的网络接口卡 部(NIC) 131、处理SIP消息的SIP消息处理部132、处理Diameter消 息的Diameter消息处理部133、以及与AS等协同进行对话的控制的S— CSCF处理部134。
S—CSCF16分配有192.168.16.11的IP地址。S—CSCF16的功能 构成与S — CSCF13相同，所以省略说明。
HSS21分配有192.168.21.11的IP地址。HSS21作为其功能例如包
括用于经由网络0与其它服务器及通信装置通信的网络接口卡部(NIC)
211、处理Diameter消息的Diameter消息处理部212、以及进行用户信 息的管理的HSS处理部213。
HSS22分配有192.168.22.11的IP地址。HSS22的功能构成与 HSS21相同，所以省略说明。
HSS21、 HSS22分别作为Diameter服务器工作，各Diameter消息 处理部可以接收Diameter消息LIR (Location — Info — Request)，并发 送Diameter消息LIA (Location—Info—Answer)。
密钥生成AS31分配有192.168.31.11的IP地址。密钥生成AS31 例如包括用于经由网络0与其它服务器及通信装置通信的网络接口卡部 (NIC) 311、处理SIP消息的SIP消息处理部312、以及基于处理请求进 行用户侧通信装置和服务侧通信装置之间的加密通信所使用的对话密钥的 生成处理的密钥生成处理部313。
权限判断AS32分配有192.168.32.11的IP地址，具备管理与各用户 是否可以享受服务侧通信装置提供的服务有关的权限信息的权限DB80。与 实施例1同样地，权限DB80的管理对象不仅包含用于享受服务的权限， 还包含用于确立对话的权限。权限判断AS32例如包括用于经由网络0与 其它服务器及通信装置通信的网络接口卡部(NIC) 321、处理权限判断请 求消息的消息处理部322、以及控制对权限DB80的处理的权限判断处理 部323。
用户侧通信装置41分配有192.168.41.11的IP地址。用户侧通信装 置41的功能构成与第一实施例相同，所以省略说明。
服务侧通信装置42分配有192.168.42.11的IP地址。服务侧通信装 置42的功能构成与第一实施例相同，所以省略说明。
P—CSCFll、 14、 I—CSCF12、 15、 S—CSCF13、 16分另U作为SIP 服务器工作，各SIP消息处理部收发作为SIP消息的INVITE消息、BYE 消息、CANCEL消息、UPDATE消息或对其的响应消息等。
Jl:匕夕卜，P—CSCFll、 14、 I一CSCF12、 15、 S — CSCF13、 16么、另U 作为Diameter客户机工作，各Diameter消息处理部可以发送Diameter 协议的LIR消息等。
下面，说明图15所示的用户侧通信装置41通过图16所示的服务侧
通信装置42进行经由IMS的数据通信的情况的通信步骤。
首先，用户侧通信装置41及服务侧通信装置42分别对网络0及网络 1上的P—CSCF开始登录。关于该登录处理，按照非专利文献2所示的在 IMS规格下制定的步骤，所以省略说明。
以下，用图17到图23，对完成了向IMS的登录处理的用户侧通信装 置41确立与服务侧通信装置42的对话为止的顺序进行说明。
网络0上的S—CSCF13及网络1上的S—CSCF16的处理流程与第 一实施例的SIP服务器10的处理流程大致相同。
首先，用图17及图18表示完成了登录处理的用户侧通信装置41对 服务侧通信装置42请求服务提供时的顺序。
首先，用户侧通信装置41向网络 上的P — CSCFll发送INVITE 消息M401。
P —CSCF11从用户侧通信装置41接收到INVITE消息M401时，SIP 消息处理部112基于该INVITE消息生成INVITE消息M402，向S — CSCF13发送。
S —CSCF13从P—CSCF11接收到INVITE消息M402时，对比在 用户侧通信装置41的登录时从HSS21取得的过滤准则和该INVITE消息 中包含的用户信息(M403)。其结果，在该实施例中，判断为在对话确立 时需要密钥生成AS31提供的功能，向密钥生成AS31发送密钥生成请求 消息M404。作为密钥生成请求消息M404，使用作为SIP消息的 MESSAGE消息。该MESSAGE消息由SIP消息处理部132和S—CSCF 处理部134生成。此外，该MESSAGE消息的正文部具有与图8所示的密 钥生成请求消息正文部M104 — 1相同的结构。
接着，S—CSCF13不等待来自密钥生成AS31的响应，向网络1上 的I—CSCF15发送INVITE消息M405。
并且，S—CSCF13以密钥生成请求消息M404、 INVITE消息M405 的顺序发送消息，但是这两个消息不限于该顺序，可以按任意的顺序发送。
密钥生成AS31从S — CSCF13接收到密钥生成请求消息M404时， 密钥生成处理部313开始密钥生成处理(M406)。
与此并行，网络1上的I一CSCF15从S—CSCF13接收到INVITE 消息M405时，为了取得担任该INVITE消息的目的地即服务侧通信装置 42的S—CSCF的IP地址，Diameter消息处理部153生成Diameter协 议的LIR消息M407，向相同的网络1上的HSS22发送。
HSS22从I一CSCF15接收到LIR消息M407时，将从该LIR消息中 提取的服务侧通信装置42的IP地址作为密钥检索内部DB，得到担任服务 侧通信装置42的S—CSCF16的IP地址。接着，HSS22的Diameter处 理部222生成包含所得到的S—CSCF16的IP地址的LIA消息M408， 向I一CSCF15发送。
I—CSCF15的Diameter消息处理部153在从HSS22接收到的LIA 消息M408中提取出S — CSCF16的IP地址时，SIP消息处理部152基于 INVITE消息M405生成INVITE消息M409，向S —CSCF16的IP地址 发送。
S—CSCF16从I一CSCF15接收到INVITE消息M409时，对比在服 务侧通信装置42的登录时从HSS22取得的过滤准则和该INVITE消息中 包含的服务信息(M410)。其结果，在本实施例中，判断为对话确立时需 要权限判断AS32的功能，向权限判断AS32发送权限判断请求消息 M411。作为权限判断请求消息M411，与密钥生成请求消息同样地，使用 作为SIP消息的MESSAGE消息。该MESSAGE消息由SIP消息处理部 162和S—CSCF处理部164生成。此外，该MESSAGE消息的正文部具 有与图8所示的权限判断请求消息正文部M103-1相同的结构。
接着，S—CSCF16不等待来自权限判断AS32的响应，向网络1上 的P—CSCF14发送INVITE消息M412。
并且，S—CSCF16按照权限判断请求消息M411 、INVITE消息M412 的顺序发送消息，但是这两个消息不限于该顺序，可以按任意的顺序发送。
权限判断AS32从S—CSCF16接收到权限判断请求消息M411时， 权限判断处理部323对权限DB80进行权限信息的询问(M413)。
与此并行，网络1上的P—CSCF14从S—CSCF16接收到INVITE 消息M412时，SIP消息处理部142基于该INVITE消息生成INVITE消 息M414，向相同的网络1上的服务侧通信装置42发送。
接收到INVITE消息M414的服务侧通信装置42由服务器处理部423 开始在提供服务中需要的初始化处理(进程的启动等)(M415)。完成初始 化处理时，服务侧通信装置42向P — CSCF14发送200OK消息M416。
从服务侧通信装置42接收到200OK消息M416的P—CSCF14由 SIP消息处理部142基于该200OK消息生成200OK消息M417,向S — CSCF16发送。
S — CSCF16从P—CSCF14接收到200OK消息M417时，SIP消息 处理部162生成对该200OK消息的ACK消息M418，向P — CSCF14发送。
P —CSCF14从S—CSCF16接收妾ij ACK消息M418时，SIP消息处 理部142基于该ACK消息生成ACK消息M419，向服务侧通信装置42 发送。
进行了权限判断处理M413的权限判断AS32结束该权限判断处理， 确认用户侧通信装置41具有用于享受服务侧通信装置42的服务的权限时， 向S—CSCF16发送权限判断结果[许可]消息M420。作为权限判断结果 [许可]消息M420，使用作为SIP消息的2000K消息。该2000K消息由 SIP消息处理部322和权限判断处理部323生成。此外，该2000K消息 的正文部具有与图8所示的权限判断结果[许可]消息正文部M112 — 1相同 的结构。
S—CSCF16从服务侧通信装置42、权限判断AS32的两者接收到消 息时，SIP消息处理部162从对INVITE消息M409的200OK消息M417 的标题部除去包含自URI的Via标题，从而生成对INVITE消息M409的 2000K消息M421，向I一CSCF15发送。
I一CSCF15从S—CSCF16接收妾U 2000K消息M421日寸，基于该 200OK消息生成200OK消息M422，向网络0上的S—CSCF13发送。
S—CSCF13从I—CSCF15接收到2000K消息M422时，SIP消息 处理部132生成对该200OK消息的ACK消息M423，向S — CSCF16发 送。
进行密钥生成处理M406的密钥生成AS31完成该密钥生成处理时， 向S — CSCF13发送密钥生成结果消息M424。作为密钥生成结果消息
M424，使用作为SIP消息的200OK消息。该200OK消息由SIP消息处 理部312和密钥生成处理部313生成。此外，200OK消息的正文部具有 与如图8所示的密钥生成结果消息正文部M113 — l相同的效果。
S—CSCF13从服务侧通信装置42、密钥生成AS31的两者接收消息 时，向网络1上的S—CSCF16发送作为SIP消息的UPDATE消息M425。 UPDATE消息M425由SIP消息处理部132及S — CSCF处理部134生 成。在该UPDATE消息的正文部包含由密钥生成结果消息M424传输的 对话密钥信息。
S—CSCF16从S—CSCF13接收至ij UPDATE消息M425时，SIP消 息处理部162基于该UPDATE消息生成UPDATE消息M426，向P — CSCF14传输。
P—CSCF14从S—CSCF16接收至廿UPDATE消息M426日寸，SIP消 息处理部142基于该UPDATE消息生成UPDATE消息M427，向服务侧 通信装置42传输。
服务侧通信装置42从P—CSCF14接收到UPDATE消息M427时， SIP消息处理部422取得在该UPDATE消息的正文部中包含的对话密钥 信息之后，生成对该UPDATE消息的200OK消息M428。接着，向P — CSCF14发送该200OK消息，转移到可以向用户侧通信装置41提供服务 的状态。
P—CSCF14从服务侧通信装置42接收到200OK消息M428时，SIP 消息处理部142基于该200OK消息生成200OK消息M429，向S — CSCF16发送。
S—CSCF16从P—CSCF14牛妾收至廿200OK消息M429时，SIP消息 处理部162基于该200OK消息生成200OK消息M430，向S—CSCF13 传输。
S—CSCF13从S—CSCF16接收200OK消息M430时，SIP消息处 理部132在从P—CSCF11接收到的INVITE消息M402的标题部除去包 含自URI的Via标题来生成200OK消息M431的标题部。此外，根据从 密钥生成AS31接收到的密钥信息结果消息的正文部包含的对话密钥信息 生成200OK消息M431的正文部，并与标题部结合来生成200OK消息
M431，向P—CSCF11发送。
P — CSCFll从S—CSCF13接收到200OK消息M431时，SIP消息 处理部112基于该200OK消息生成200OK消息M432，向用户侧通信装 置41发送。
用户侧通信装置41从P — CSCF11接收到200OK消息M432时，SIP 消息处理部412取得在该200OK消息的正文部中包含的对话密钥信息之 后，作为对该200OK消息的响应，向P—CSCFll发送ACK消息M433。
P—CSCFll从用户侧通信装置41接收到ACK消息M433时，SIP 消息处理部112基于该ACK消息生成ACK消息M434，向S-CSCF13 发送。
S-CSCF13从P—CSCFll接收ACK消息M434，结束处理。
通过以上的步骤，在用户侧通信装置41和服务侧通信装置42之间确 立通信对话，可以进行从用户侧通信装置41向服务侧通信装置42的访问 和从服务侧通信装置42向用户侧通信装置41的信息服务(M435)。用户 侧通信装置41和服务侧通信装置42之间的通信利用在对话确立中得到的 对话密钥信息进行加密。
在本实施例中，并行进行基于密钥生成AS31的密钥生成处理M406、 基于权限判断AS32的权限判断处理M413、基于服务侧通信装置42的进 程启动处理等M415。因此，与依次逐一进行各处理的步骤相比，具有縮 短到通信开始为止所需的时间的效果。
关于用户侧通信装置41向服务侧通信装置42请求对话的切断时的顺 序，按照由IMS的规格制定的步骤，所以省略说明。
接着，用图19及图20说明用户侧通信装置41不具有用于享受服务 侧通信装置42的服务的权限的情况、且来自服务侧通信装置42的200OK 消息比权限判断的结果先通知的情况的顺序。
关于用户侧通信装置41向P—CSCFll发送INVITE消息M401之 后到P—CSCF14向服务侧通信装置42发送ACK消息M419为止的顺序， 与用图17及图18所示的顺序相同。
然后，权限判断AS32进行权限判断处理的结果，确认用户侧通信装 置41不具有用于享受服务侧通信装置42的服务的权限时，向S—CSCF16
发送权限判断结果[拒绝]消息M441。作为权限判断结果[拒绝]消息
M441,使用作为SIP消息的403 Forbidden消息。该403 Forbidden消 息由SIP消息处理部322及权限判断处理部323生成。此外，该403 Forbidden消息的正文部具有与图6所示的权限判断[拒绝]消息正文部 M121 — l相同的结构。
S—CSCF16接收到权限判断结果[拒绝]消息M441时，SIP消息处理 部162生成对INVITE消息M409的403 Forbidden消息M442,向I— CSCF15发送。
此外，S—CSCF16由SIP消息处理部162生成BYE消息M443，向 P—CSCF14发送。
P — CSCF14从S—CSCF16接收到BYE消息M443时，SIP消息处 理部142基于该BYE消息生成BYE消息M444，向服务侧通信装置42 发送。
服务侧通信装置42从P — CSCF14接收到BYE消息M444时，SIP 消息处理部422作为对该BYE消息的响应生成2000K消息M445，向P —CSCF14发送。
P—CSCF14从服务侧通信装置42接收到200OK消息M445时，SIP 消息处理部142基于该200OK消息生成2000K消息M446，向S— CSCF16发送。
在图20中，I一CSCF15从S—CSCF16接收到403 Forbidden消息 M442时，SIP消息处理部152基于该403 Forbidden消息生成403 Forbidden消息M447，向网络0上的S—CSCF13发送。
S —CSCF13 ,人I—CSCF15接收至U 403 Forbidden消息M447日寸， SIP消息处理部132生成作为对该403 Forbidden消息的响应的ACK消 息M448，向网络1上的S—CSCF16发送。
此外，S—CSCF13基于从I一CSCF15接收到的403 Forbidden消 息消息M447， SIP消息处理部132生成403 Forbidden消息M449，向 P—CSCFll发送。
P—CSCF11从S—CSCF13接收至廿403 Forbidden消息M449时， SIP消息处理部112基于该403 Forbidden消息生成403 Forbidden消
息M450，向用户侧通信装置41发送。
用户侧通信装置41从P—CSCFll接收至ij 403 Forbidden消息M450 时，SIP消息处理部412生成作为对该403 Forbidden消息的响应的ACK 消息M451，向P—CSCF11发送。
P—CSCF11从用户侧通信装置41接收到ACK消息M451时，SIP 消息处理部112基于该ACK消息生成ACK消息M452，向S—CSCF13 发送。
此外，S—CSCF13向密钥生成AS31发送密钥生成取消消息M453。 作为密钥生成取消消息M453，使用作为SIP消息的MESSAGE消息。该 MESSAGE消息由SIP消息处理部132生成。此外，该MESSAGE消息 的正文部具有与图8所示的密钥生成取消消息正文部M124 — l相同的结 构。
密钥生成AS31从S—CSCF13接收到密钥生成取消消息M453时， 密钥生成处理部313结束处于处理中的密钥生成处理。接着，SIP消息处 理部132生成密钥生成取消响应消息M454，向S-CSCF13发送。作为密 钥生成响应消息M454，使用作为SIP消息的2000K消息。此外，该200OK 消息的正文部具有与图8所示的密钥生成取消响应消息正文部M125—l 相同的结构。
接着，用图21对用户侧通信装置41不具有用于享受服务侧通信装置 42的服务的权限、且权限判断的结果比来自用户侧通信装置42的200OK 消息先通知时的顺序进行说明。
关于用户侧通信装置41向P — CSCFll发送INVITE消息M401之 后到服务侧通信装置42开始进程启动处理等M415的执行为止的顺序，与 用图17及图18所示的顺序相同。
然后，权限判断AS32进行权限判断处理的结果，确认用户侧通信装 置41不具有用于享受服务侧通信装置42的服务的权限时，在服务侧通信 装置42发送200OK消息之前向S—CSCF16发送权限判断结果[拒绝]消 息M441。作为权限判断结果[拒绝]消息M441，是与图19所示的顺序中 的权限判断结果[拒绝]消息M441相同的消息。
S-CSCF16从权限判断AS32接收到权限判断结果[拒绝]消息M441
时，SIP消息处理部162生成对INVITE消息M409的403 Forbidden 消息M442，向I一CSCF15发送。
此夕卜，S—CSCF16由SIP消息处理部162生成CANCEL消息M461， 向P —CSCF14发送。
然后，关于在接收到403Forbidden消息M442的I一CSCF15、和网 络0内的各装置中进行的顺序，与图20所示的顺序相同，所以省略说明。
P — CSCF14从S—CSCF16接收至U CANCEL消息M461时，SIP消 息处理部142基于该CANCEL消息，生成CANCEL消息M462，向服务 侧通信装置42发送。
此外，P—CSCF14由SIP消息处理部142生成对CANCEL消息M461 的响应消息即200OK消息M463，向S — CSCF16发送。
服务侧通信装置42从P—CSCF14接收到CANCEL消息M462时， SIP消息处理部422作为对该CANCEL消息的响应生成200OK消息 M464，向P—CSCF14发送。
接着，服务侧通信装置42由SIP消息处理部422生成作为SIP最终 响应消息的487 Request Terminated消息，向P — CSCF14发送。
P —CSCF14从服务侧通信装置42接收到487 Request Terminated 消息时，SIP消息处理部142基于该487 Request Terminated消息生成 487 Request Terminated消息M466，向S—CSCF16发送。
S—CSCF16从P—CSCF14接收至U487 Request Terminated消息 M466时，SIP消息处理部162生成作为对该487 Request Terminated 消息的响应的ACK消息M467，向P—CSCF14发送。
P—CSCF14从S—CSCF16接收到ACK消息M467时，SIP消息处 理部142基于该ACK消息生成ACK消息M468，向服务侧通信装置42 发送。
接着，用图22及图23对服务侧通信装置42处于不能提供服务的状 态时的顺序进行说明。
用户侧通信装置41向P—CSCFll发送INVITE消息M401之后到P 一CSCF14向服务侧通信装置42发送INVITE消息M414为止的顺序与 图17及图18所示的顺序相同。
接着，服务侧通信装置42为了传达因任意的理由处于不能提供服务的
状态的情况，向P—CSCF14发送SIP错误响应消息M471。例如，服务 侧通信装置42发送作为SIP消息的486Busy Here消息，从而通知服务 侧通信装置42已经与其它用户侧通信装置确立了多个对话、并且处于不能 再确立新的对话的状况。
P — CSCF14从服务侧通信装置42接收到SIP错误响应消息M471时， SIP消息处理部142基于该SIP错误响应消息生成SIP错误响应消息 M472，向S—CSCF16发送。
S—CSCF16从P —CSCF14接收至ij SIP错误卩向应消息M472日寸，SIP 消息处理部162生成作为对该SIP错误响应消息的响应的ACK消息 M473，向P—CSCF14发送。
P—CSCF14从S—CSCF16接收到ACK消息M473时，SIP消息处 理部142基于该ACK消息生成ACK消息M474,向服务侧通信装置42 发送。
接着，S—CSCF16由SIP消息处理部162基于接收到的SIP错误响 应消息M472生成SIP错误响应消息M475，向I一CSCF15发送。
接着，S—CSCF16向权限判断AS32发送权限判断取消消息M476。 作为权限判断取消消息M476，使用作为SIP消息的MESSAGE消息。该 MESSAGE消息由SIP消息处理部162生成。此外，该MESSAGE消息 的正文部具有与图8所示的权限判断取消消息正文部M145 — l相同的结 构。
权限判断AS32从S—CSCF16接收到权限判断取消消息M476时， 权限判断处理部323结束处于处理中的权限判断处理。接着，SIP消息处 理部322生成权限判断取消响应消息M477,向S—CSCF16发送。作为 权限判断取消响应消息M477,使用作为SIP消息的200OK消息。并且， 该2O0OK消息的正文部具有与图8所示的权限判断取消响应消息正文部 M146—l相同的结构。
另一方面，I一CSCF15基于从S—CSCF16接收到的SIP错误响应消 息M475生成SIP错误响应消息M478,向网络0上的S—CSCF13发送。
S—CSCF13从网络1上的I一CSCF15接收到SIP错误响应消息 M478时，SIP消息处理部132生成作为对该SIP错误响应消息的响应的 ACK消息M479，向网络1上的S — CSCF16发送。
接着，S — CSCF13由SIP消息处理部132基于SIP错误响应消息 M478生成SIP错误响应消息M480，向P—CSCFll发送。
接着，S—CSCF13向密钥生成AS31发送密钥生成取消消息M481。 作为密钥生成取消消息M481，使用作为SIP消息的MESSAGE消息。该 MESSAGE消息由SIP消息处理部132生成。此外，该MESSAGE消息 的正文部具有与图8所示的密钥生成取消消息正文部M124—l相同的结 构。
密钥生成AS31从S—CSCF13接收到密钥生成取消消息M481时， 密钥生成处理部313结束处于处理中的密钥生成处理。接着，SIP消息处 理部312生成密钥生成取消响应消息M482，向S—CSCF13发送。作为 密钥生成取消响应消息M482，使用作为SIP消息的200OK消息。此外， 该200OK消息的正文部具有与图8所示的密钥生成取消响应消息正文部 M125—l相同的结构。
另一方面，P — CSCFll从S — CSCF13接收到SIP错误响应消息 M480时，SIP消息处理部112基于该SIP错误响应消息生成SIP错误响 应消息M483，向用户侧通信装置41发送。
用户侧通信装置41从P—CSCFll接收到SIP错误响应消息M483 时，SIP消息处理部412生成作为对该SIP错误响应消息的响应的ACK 消息M楊，向P—CSCFll发送。
P—CSCFll从用户侧通信装置41接收到ACK消息M484时，SIP 消息处理部112基于该ACK消息生成ACK消息M485，向S—CSCF13 发送。
在该实施例中，在执行权限判断处理或密钥生成处理的期间，S_ CSCF16及S-CSCF13也可以接收由P—CSCF或I一CSCF传输的来自 服务侧通信装置42的SIP错误响应消息。该SIP错误响应消息经由P_ CSCFll，送到用户侧通信装置41处。因此，具有用户侧通信装置41比 过去的步骤早知道服务侧通信装置42处于不能提供服务的状态的情况的 效果。
此外，在本实施例中，权限判断AS32关于用户用于享受由服务侧通 信装置42提供的服务的权限进行了判断，但是，作为该例子的变形例也可 以是如下结构在权限判断AS32中关于用户侧通信装置用于与服务侧通 信装置确立对话的权限进行判断，由各服务侧通信装置进行用户用于享受 在该对话上提供的服务的权限判断。
权利要求
1. 一种数据通信系统，其特征在于，包括第一通信装置；第二通信装置；对话管理服务器，管理用于上述多个通信装置进行数据通信的对话；以及功能提供服务器，提供上述对话确立所需的功能，上述对话管理服务器在接收到以上述第一通信装置为通信源、请求与上述第二通信装置的对话确立的请求消息时，并行进行传输上述请求消息并等待响应的处理、和向功能提供服务器委托上述对话确立所需的处理并等待响应的处理。
2. 如权利要求1所述的数据通信系统，其特征在于， 向上述功能提供服务器委托的处理包括判断上述第一通信装置是否具有为了利用所确立的上述对话享受上述 第二通信装置提供的服务所需的权限的处理。
3. 如权利要求1所述的数据通信系统，其特征在于， 向上述功能提供服务器委托的处理包括利用上述第一通信装置与上述第二通信装置的上述对话而进行的通信 的加密所需的加密密钥的生成处理。
4. 如权利要求1所述的数据通信系统，其特征在于， 上述对话管理服务器从上述第二通信装置接收到与所发送的上述请求消息对应的响应消息之前、从上述功能提供服务器接收到拒绝从上述第二 通信装置向上述第一通信装置的服务提供的消息时，发送向上述第二通信装置发送了的上述对话确立请求的取消消息、及/ 或取消在向上述功能提供服务器委托之后还未接收到结果的处理的取消消
5. 如权利要求1所述的数据通信系统，其特征在于，上述对话管理服务器从上述第二通信装置接收到与传输的上述请求消 息对应的可提供服务消息时，向上述第二通信装置发送与上述可提供服务 消息对应的响应消息，在发送该响应消息后，等待接收与在向上述功能提 供服务器委托之后还未接收到结果的处理对应的结果。
6. 如权利要求1所述的数据通信系统，其特征在于，上述对话管理服务器从上述功能提供服务器作为与上述委托的处理对 应的上述结果、接收到许可从上述第二通信装置向上述第一通信装置的服 务提供的消息时，向上述功能提供服务器发送与许可上述服务提供的消息 对应的响应消息，在发送该响应消息后，等待接收与向上述功能提供服务 器委托的处理、及/或向上述第二通信装置发送的上述请求消息对应的结果。
7. 如权利要求6所述的数据通信系统，其特征在于，上述对话管理服务器从上述第二通信装置及委托处理的所有上述功能 提供服务器接收到响应时，以上述第二通信装置及上述第一通信装置为目 的地，发送在从上述功能提供服务器接收的消息中包含的信息。
8. 如权利要求5所述的数据通信系统，其特征在于， 上述对话管理服务器从上述功能提供服务器作为与上述委托的处理对应的上述结果、接收到拒绝从上述第二通信装置向上述第一通信装置的服 务提供的消息时，发送基于向上述第二通信装置传输的上述请求消息的对 话确立请求的取消消息、及/或向其它上述功能提供服务器委托的处理的取 消消息。
9. 如权利要求6所述的数据通信系统，其特征在于， 上述对话管理服务器从上述第二通信装置及委托处理的所有上述功能提供服务器接收到响应时，向上述第一通信装置发送与请求对话确立的上 述请求消息对应的响应消息。
10. 如权利要求1所述的数据通信系统，其特征在于，上述对话管理服务器从上述第二通信装置接收到与传输的上述请求消 息对应的服务提供拒绝消息时，向该功能提供服务器发送向上述功能提供 服务器委托的处理的取消消息。
11. 如权利要求8所述的数据通信系统，其特征在于，所谓上述对话管理服务器向上述第二通信装置发送的对话确立请求的 取消消息，包括用于明示对话确立处理在处理的中途中断的信息。
全文摘要
本发明涉及的数据通信系统，提供一种对话确立的高速化方法及系统，对话管理服务器在对话的确立所需的各功能(可否提供服务的判断、或对话密钥的生成等)的处理需要较长时间时，缩短到对话确立为止所需的时间。对话管理服务器设置并行进行向对话确立所需的各功能(可否提供服务的判断、或对话密钥的生成等)的处理请求、和通过要确立对话的通信装置或其它对话管理服务器而发送的通信消息的传输处理的手段。
文档编号H04L29/08GK101388890SQ200810212579
公开日2009年3月18日 申请日期2008年9月5日 优先权日2007年9月10日
发明者入部真一, 山本暖, 矢户晃史, 藤城孝宏, 锻忠司 申请人:株式会社日立制作所