CN1729672A - 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构 - Google Patents

用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构 Download PDF

Info

Publication number
CN1729672A
CN1729672A CNA2003801070463A CN200380107046A CN1729672A CN 1729672 A CN1729672 A CN 1729672A CN A2003801070463 A CNA2003801070463 A CN A2003801070463A CN 200380107046 A CN200380107046 A CN 200380107046A CN 1729672 A CN1729672 A CN 1729672A
Authority
CN
China
Prior art keywords
e2enp
peer
session
api
sip
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
CNA2003801070463A
Other languages
English (en)
Other versions
CN1729672B (zh
Inventor
D·曼达托
T·古恩科瓦-鲁伊
A·卡斯勒
M·诺斯塞
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.)
Sony Deutschland GmbH
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Sony International Europe GmbH
Siemens AG
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 Sony International Europe GmbH, Siemens AG filed Critical Sony International Europe GmbH
Publication of CN1729672A publication Critical patent/CN1729672A/zh
Application granted granted Critical
Publication of CN1729672B publication Critical patent/CN1729672B/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/1096—Supplementary features, e.g. call forwarding or call holding
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

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)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明一般涉及具有分布式多媒体应用(130)的无线移动组网环境中的移动计算领域。更具体来说，它针对基于会话层协议(SIP)结合会话描述协议实现(SDP、SDPng)的扩充以及用于定义允许实行和使用分级结构QoS合同规范的用户简档和终端能力信息的可扩展标记语言(XML)的新颖使用、用于移动装置上运行的自适应实时服务的服务质量(QoS)管理和端对端协商协议(E2ENP)的领域。因此，所述端对端协商协议(E2ENP)适用于导出可协商信息，它通过使移动应用能够有效及时地对QoS违反作出反应，对于两个或多个终端对等体和/或中间件的多个配置，以一致、可靠及递增的方式实现电信会话的端对端质量和能力的预协商、快速协商和快速动态重新协商。此外，本发明涉及新颖E2ENP用户代理(128)的概念和实现，它封装E2ENP的信令部分，并以下列方式、以可交换格式表达要协商的信息：异构应用(130)可易于约定用于根据相应用户的偏好和简档、以协调方式来结合本地、对等体及网络资源的参考模型。根据本发明的一个实施例，所采用的E2ENP会话层协议应用编程接口(101a－e)与实际使用的会话层协议和会话描述协议实现无关。

Description

用于分布式多媒体应用的能力和服务 质量协商和会话建立的软件体系结构
本发明一般涉及具有分布式多媒体应用及***的移动无线组网环境中分布式移动计算的领域。更具体来说，它针对在动态无线因特网协议(IP)网络中支持不同接入技术的固定和移动装置中运行的自适应实时流服务的质量协商和会话建立的领域，从而包括特别涉及多媒体中间件和资源保留机制的研发问题。
分布式***最可能面临的一个问题是如何应付在终端***和在网络中的有限资源以及不稳定的环境状况。移动用户实际上预计会更频繁地遇到以下不利情况：因例如无线链路质量下降、水平和/或垂直切换、有限量的移动终端资源等各种原因，使他们的QoS合同不再受到网络基础设施的支持，这将被称作“QoS违反”。通过假设干线中的适当资源过度提供，可以预期QoS违反最可能因切换而引起或者在接入网中、尤其是在它的无线电部分中。
此外，处理与多个对等体同时交换的多个媒体信息流的移动多媒体应用要求协商能力以及处理QoS要求、尤其是考虑到上述不稳定环境状况的实际有效方式。
应付不稳定环境状况的一种可能方式是使移动用户的应用能够对QoS违反实时有效地作出反应。对等体实际上可在不同的抽象层次上脱机协商各种备选QoS合同，使得在建立连接时以及每当QoS违反出现时，关于如何最有效地适应变化状况的协定可在对等体之间及时实现。
目前技术发展水平简述
在欧洲专利申请EP01122366.6中，已经引入及详细描述了端对端协商协议(E2ENP)。由于本发明进一步发展了此欧洲专利申请中描述的概念，因此其公开通过引用结合于此。
下表给出描述QoS和能力协商协议的概念的最近发行的文章的概述(按字母顺序)：
  缩写   发行物
  [Ber]   T.Berners-Lee等人：“统一资源标识符(URI)：通用语法”，Networking Working Group，Standards Track RFC 2396。
  [Bos1]   L.Bos等人：“用于端对端用户感受服务质量协商的框架”，IETF Internet Draft，正在拟定中，<draft-bos-mmusic-sdpqos-framework-00.txt>。它描述利用SIP和SDP在两个对等体之间协商QoS的过程。但是，它没有描述使用这个过程的实体的任何体系结构。
  [Bos2]   L.Bos等人：“用于服务质量协商的SDPng扩充”，IETFInternet Draft，正在拟定中，<draft-bos-mmusic-sdpng-qos-00.txt>。它描述利用SIP和SDP在两个对等体之间协商QoS的过程。但是，它没有描述使用这个过程的实体的任何软件体系结构。
  [BRAIN]   “移动性启用网络上服务自适应、缩放性和QoS处理的概念”，IST-1999-10050BRAN Deliverable 1.2(http://www.ist-brain.org/)。
  [BRENTA]   A.Kassler等人：“BRENTA-支持可适应多媒体通信的移动性和服务质量”，Proceedings of the IST MobileCommunications Summit 2000，Galway，Ireland，2000年10月，第403-408页。
  缩写 发行物
  [Cam1] G.Camarillo、W.Marshall、J.Rosenberg：“资源管理与SIP的集成”，IETF Internet Draft，正在拟定中，<draft-ietf-sip-manyfolks-resource-07.txt>。它发展了基于SDP的“提议/应答模型”的要求，另外还在保留方面进行了发展。但是，它没有描述执行这类特定协商的实体的任何软件体系结构。
  [Cam2] G.Camarillo等人：“SDP中的媒体线路的分组”(IETFInternet Draft，正在拟定中，<draft-ietf-mmusic-fid-04.txt>)。
  [Gam] E.Gamma等人：“设计模式-可再用面向对象软件的元素”，Addison-Wesley，Reading-Massachusetts(USA)，1994。
  [Gu] X.Gu、K.Nahrstedt等人：“万维网的基于XML的服务质量使能语言”，Project Report of the National ScienceFoundation，2001。
  [Gue] T.Guenkovy-Luy、A.Kassler、J.Eisl、D.Mandato：“有效的端对端QoS信令-概念和特征”，IETF Intemet Draft，正在拟定中，<draft-guenkova-mmusic-e2enp-sdpng-00.txt>。
  [Kly1] G.Klyne：“描述媒体特征集的语法”，IETF RFC 2533。
  [Kly2] G.Klyne：“标识合成媒体特征”，IETF RFC 2938。它描述了通过引入数据句柄和散列对[Kly1]公开的算法的优化。
  [Kut1] D.Kutscher等人：“会话描述和能力协商的要求”，(IETFInternet Draft，正在拟定中，<draft-kutscher-mmusic-sdpng-req-01.txt>)。
  [Kut2] D.Kutscher等人：“会话描述和能力协商”，IETF InternetDraft，正在拟定中，<draft-ietf-mmusic-sdpng05.txt>。
 缩写   发行物
 [Man1]   D.Mandato、A.Kassler、T.Robles、G.Neureiter：“移动性驱动网络上服务自适应、缩放性的概念和QoS概念”(ISTGlobal Summit 2001，Barcelona，2001年9月，第285-293页)。这篇文章描述端对端协商协议(E2ENP)的核心概念。2001年10月在San Diego的PIMRC 2001提供了类似的论文。
 [Man2]   D.Mandato、A.Kassler、T.Robles、G.Neureiter：“处理移动异构组网环境中的端对端QoS”(PIMRC 2001，SanDiego，30/9/2001至3/10/2001，第C-49至C-54页)
 [ReqSpec]   “端对端协商协议”，IST-2000-28584/SO/WP1/PI/I/003/al，MIND Intemal Contribution to WP1，Activity 1.3，Work Item2。
 [Ros1]   J.Rosenberg、H.Schulzrinne等人：“SIP：会话发起协议”，IETF Standards Track，Network Working Group，RFC3261。这份文件描述会话发起协议(SIP)，它是应用层控制(信令)协议，用于创建、修改和终止与一个或多个参与者的会话。
 [Ros2]   J.Rosenberg、H.Schulzrinne：“采用SDP的提议/应答模型”，IETF Internet Draft，正在拟定中，<draft-ietf-mmusic-sdp-offer-answer-02.txt>。这份文件定义一种机制，通过这种机制，两个实体可利用SDP来提供它们之间的多媒体会话的共同视图。
[Cam1]提供多阶段呼叫建立机制，它使网络QoS和安全性建立成为由会话发起协议(SIP)发起并由会话描述协议(SDP)描述的会话的前提。网络资源在开始会话之前被保留，从而利用现有网络资源保留机制(例如RSVP)。
[Kly1]提供一种表达表示媒体处理能力的媒体特征集的格式。另外，提供一种算法，它匹配特征集。它可能用来确定发送方和接收方的能力是否兼容。另外，在[Kly2]中，公开了一种利用特征表示的散列描述合成物的合成媒体特征集的缩略格式。
在[Ros2]中，描述采用SDP的一对一能力协商的完整模型。但是，这个模型遇到由相互引用的信息以及关于分组媒体流的信息的定义因SDP的平面分级结构而导致的问题。
[Kut1]描述在多方多媒体会议情况中与会话描述和端点能力协商的框架相关的一组要求。根据用户偏好、***能力或其它限制，可为会议选择不同配置。因此，在对等体之间的协商过程的需要被识别，但没有被描述以便确定可能配置的公共集合并选择要用于信息交换的公共配置之一。这个能力协商用来得到与终端***能力以及可能参与方的用户偏好一致的有效会话描述。不同的协商策略可用来反映不同的会议类型。他们还认识到与会话建立相关联的网络资源保留的需要。最后，起草建议，用于描述能力并提供协商语言，但不是协议。因此，[Kut1]中提出的解决方案既没有考虑用于确定QoS配置的公共集合的协商协议，也没有综合本地、对等体及网络资源保留。
以下称作[Kut2]的这个IETF草案的最新版本提供详细的XML模式规范和音频编解码器的原型以及实时协议(RTP)简档。
在[Bos1]中，描述了端对端用户感受QoS协商，其中假定：某种中间件和服务可能极大程度地涉及到关于终端对等体的协商QoS信息的最后判定。所述的判定可承担某些标准“合同类型”。虽然据说信令和数据通路可采用不同方式通过网络，但建议在协商通路上的某个中间件可能影响协商，但一般对于数据通路没有影响。如果这个协议模型被部署，则网络不是透明的。根据[Bos1]的协商过程以与一些非QoS信息(例如安全性、网络许可等)的一次***织来执行，而没有考虑协议模块性以及相对QoS的信息一致性。采用[Bos1]的模型，只能够使用推送模式用于协商，它对于一些应用和服务可能是限制性的。自适应通路只是降级及固定的。
在文章[Man1]、[Man2]和[Cam2]中，论述分组媒体流的可能性。但是，作者没有考虑分组的标准、递归组构建(许多组中的一组)的可能性以及也可被分组的实时、伪实时和非实时信息媒体流的处理。另外，[Man1]和[Man2]定义可以或者不可以一次性运行但不可以在独立协商阶段中运行的协商步骤。为此，它们不满足协商阶段及其后的协商QoS信息的一致性的要求。因此，在[Man1]中，公开了E2ENP的核心概念。也没有考虑冲突“经济原则”应用的处理。此外，[Man1]和[Man2]描述设置和管理由第三方组件-QoS中介器控制的QoS自适应的自适应通路的可能性。但是，作者没有考虑终端各方独自执行和控制协商的任何可能性。
要通过本发明解决的问题
当今，自适应应用和/或中间件(例如QoS中介器)没有包括能够处理QoS预协商、QoS协商和/或QoS重新协商、提供技术无关应用编程接口(API)的资源保留和/或释放协调的任何组件，它屏蔽了用于实现那些机制的信令协议的类型。相反，自适应多流多媒体应用和/或中间件必须直接针对诸如H.323、会话发起协议(SIP)和/或会话描述协议(SDP，如[Kut2]所述的未来SDPng)被编码。此外，基于所述SIP和/或SDP的应用或中间件直接执行SDP数据的分析，并且必须通过检验SDP数据对于其先前交换版本的变化，来推断要采取的动作。
另一个问题在于，自适应应用和/或中间件(例如QoS中介器)无法以可交换格式来表达要协商的信息(例如能力、应用层QoS合同、网络层QoS合同、流层自适应通路以及流组层自适应通路)。要求异构应用和/或中间件可易于约定参考模型，所述应用和/或所述中间件则可用于对它们本身进行动态配置，以便根据相应用户的偏好和简档、相应***和网络提供商的策略在各种对等体使用的多个异构应用和中间件中以协调方式结合本地、对等体和网络资源。
在欧洲专利申请EP01122366.6中，公开了整体E2ENP概念、它的要求及其可能的实现思路，但没有详细说明任何实现。没有及时完成任何预协商信息。
虽然如[Kut2]所述的SDPng的当前形式以模块方式来构造，但它没有考虑E2ENP方面，并且不能以模块方式在不同SIP消息(或者其它协议消息)之间使用。基于SDPng的能力协商利用[Ros2]中所述的SDP提议方/应答方模型，其中，诸如E2ENP的范围中建议的复杂多阶段协商过程没有明确考虑。
在欧洲专利申请EP01122366.6以及在SDPng中均没有针对能够把用户简档信息看作整个QoS协商过程的输入的过程。
本发明的目的
鉴于上述说明，本发明的主要目的是提出一种协商方法和一种软件体系结构，它与自适应实时服务和多媒体应用的资源保留机制结合，支持能力和QoS协商以及会话建立。
这个目的通过独立权利要求的特征来实现。有利的特征在从属权利要求中定义。在以下的详细说明中，本发明的其它目的和优点十分明显。
本发明的内容
本发明基本上针对端对端协商协议(E2ENP)的新颖用户代理(UA)-封装如[ReqSpec]中所述的E2ENP的端对端信令过程的软件模块-的概念和实现，它可有利地用于以下列方式定义用户简档和终端能力信息：分级QoS合同规范(例如，相关媒体流的QoS合同的不同集合之间的强制相关)可被实行并用于导出可协商信息。作为此概念的参考实现，本发明根据可扩展标记语言(XML)描述了由因特网工程任务组(IETF)标准化的会话发起协议(SIP)与会话描述协议的扩充-下一代(SDPng)规范结合的新颖使用，以便实现端对端QoS协商协议(E2ENP)概念。更具体来说，在此建议的模型通过定义允许实行和使用分级QoS合同规范的用户简档和终端能力信息，扩展了SDPng协商机制。
因此，所述端对端协商协议(E2ENP)适用于导出可协商信息，它通过使移动应用能够有效及时地对QoS违反作出反应，对于两个或多个终端对等体和/或中间件的多个配置，以一致、可靠及递增的方式实现电信会话的端对端质量和能力的预协商、快速协商和快速动态重新协商。此外，本发明涉及封装E2ENP的信令部分的新颖E2ENP用户代理的概念和实现。所述E2ENP用户代理以可交换格式、以下列方式表达要协商的信息：异构应用可易于约定参考模型，该模型则可用于动态配置有限状态机，以便根据相应用户的偏好和简档以协调方式结合本地、对等体和网络资源。
根据本发明，内部(应用和/或中间件特定的)与外部(SIP用户代理特定的)表示之间的可交换格式的对话由分析器和工厂实现来执行。这些软件组件也是根据基本载波协议代理、E2ENP用户代理和相应应用和/或中间件的特定需要可配置的。就此而论，特定E2ENP用户代理会话标识以及所应用的协商过程和子过程的相应应用和/或中间件会话标识相互唯一映射并被高速缓存，以便能够唯一标识预协商、协商和/或重新协商会话。因此，分析器、工厂和高速缓存与相应E2ENP用户代理的实现耦合。应当注意，这四个软件组件-分析器、工厂、高速缓存和E2ENP用户代理-以及所应用的载波协议的用户代理的配置是专用任务，它取决于分别使用的应用和/或中间件组件的需要。
附图概述
通过所附权利要求书以及以下通过附图和表对本发明的优选实施例的描述，得到本发明的其它优点及可能的应用：
图1提供框图，表示根据本发明的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构，
图2表示根据本发明的一个实施例、采用基于Java的SIP栈(JSIP)、SDPng分析器和工厂的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第一实现实例，
图3表示根据本发明的一个实施例、采用Sun的Java远程方法调用(RMI)的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第二实现实例，
图4表示根据本发明的一个实施例、采用基于套接字的用户数据报协议(UDP)或传输控制协议(TCP)的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第三实现实例，
图5给出UML类图，表示org∷mind∷e2enp包，
图5bis表示E2ENP UA工厂与管理实体之间的E2ENP管理API，
图6提供文档，表示E2ENP通用资源标识符(URI)的语法的实例，从而利用扩充巴克斯-诺尔范式(ABNF)，
图7概述第一消息序列图(MSC)，表示由所建议端对端协商协议(E2ENP)的用户代理(UA)启用的预协商过程，
图8概述第二消息序列图(MSC)，表示采用由所建议端对端协商协议(E2ENP)的用户代理(UA)启用的QoS协商和资源保留协调的会话建立，
图9给出UML类图，表示org∷mind∷e2enp∷Cache子包，
图10提供示意图，表示用于端对端协商协议(E2ENP)的可扩展标记语言(XML)描述的顶层视图，
图11提供示意图，表示用于端对端协商协议(E2ENP)的XML替换组，
图12提供示意图，表示用于端对端协商协议(E2ENP)的XML目的元素，
图13提供示意图，表示用于端对端协商协议(E2ENP)的XMLqosdef元素，
图14提供示意图，表示用于端对端协商协议(E2ENP)的XMLqoscfg元素，
图15给出UML消息序列图(MSC)，表示根据本发明的E2ENP用户代理(E2ENP UA)与所应用的分析器和高速缓存之间的交互，
图17给出UML类图，表示文档对象模型(DOM)树的一般结构，
图18给出UML类图，表示利用访问者设计模式的分析器实现的结构概观，
图19提供UML消息序列图(MSC)，表示根据本发明的E2ENP用户代理(E2ENP UA)与所应用的工厂和高速缓存之间的交互，
图20提供UML类图，表示工厂实现的结构概观，
图21给出UML类图，表示org∷mind∷sip∷sipApi包，
图22给出UML类图，表示org∷mind∷sip∷sipApi∷userAgent包，
图23给出UML类图，表示org∷mind∷sip∷sipApi∷registrar包，
图24给出UML类图，表示org∷mind∷sip∷sipApi∷management包，
图25给出UML类图，表示org∷mind∷sip∷sipApi∷time包，
图26给出UML消息序列图(MSC)，表示服务提供商的配置以及服务用户与所述服务提供商的绑定，
图27给出UML消息序列图(MSC)，表示客户机的用户代理与服务器之间的连接建立，
图28给出UML消息序列图(MSC)，表示用于端对端协商协议(E2ENP)的“选项”方法，
图29给出UML消息序列图(MSC)，表示客户机的用户代理与服务器之间的连接释放，
图30表示嵌套有限状态机(FSM)的第一状态转变图，表示在根状态中执行的互斥相关程序，
图31表示嵌套有限状态机(FSM)的第二状态转变图，表示在NegOfferer子状态中执行的互斥相关程序，
图32表示嵌套有限状态机(FSM)的第三状态转变图，表示在NegAnswerer子状态中执行的互斥相关程序，
图33表示嵌套有限状态机(FSM)的第四状态转变图，表示在ReNegOfferer子状态中执行的互斥相关程序，
图34表示嵌套有限状态机(FSM)的第五状态转变图，表示在ReNegAnswerer子状态中执行的互斥相关程序，
图35表示“ResvMtx”有限状态机(FSM)的第六状态转变图，允许多个请求根据其优先级以协调方式占用互斥，
图36表示嵌套有限状态机(FSM)的第七状态转变图，表示在WaitForCoordDone子状态中执行的互斥相关程序，
图37给出UML消息序列图(MSC)，表示E2ENP用户代理(E2ENPUA)的应用编程接口(API)和SIP用户代理(SIP UA)的通用应用编程接口(API)的相关所需的预协商过程，从而利用E2ENP用户代理(E2ENPUA)的上述有限状态机(FSM)，
图38给出UML消息序列图(MSC)，表示采用E2ENP用户代理(E2ENP UA)的应用编程接口(API)和SIP用户代理(SIP UA)的通用应用编程接口(API)的相关所需的QoS协商程序和资源保留协调的会话建立，从而利用E2ENP用户代理(E2ENP UA)的上述有限状态机(FSM)，
表1表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由服务提供商实现的原语的列表，
表2表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由服务用户实现的原语的列表，
表3表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由作为提议方的服务用户实现的原语的列表，
表4表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由作为应答方的服务用户实现的原语的列表，
表5表示第一高速缓存级的应用编程接口(API)提供的方法，
表6表示第二高速缓存级的应用编程接口(API)提供的方法，
表7表示必须由分析器的应用编程接口(API)实现的原语的列表，
表8表示必须为产生特定分析器示例实现的原语的列表，
表9表示必须由工厂的应用编程接口(API)实现的原语的列表，
表10表示必须为产生特定工厂示例实现的原语的列表，
表11表示众所周知的工厂-工厂类E2ENPContentHandlerFactory提供的方法，
表12表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由端对端协商协议(E2ENP)的用户代理(UA)的服务提供商实现的原语的列表，
表13表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的客户机端特定原语的列表，
表14表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的服务器端特定原语的列表，
表15表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的客户机端以及服务器端特定原语的列表，
表16表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务提供商实现的原语的列表，
表17表示根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的原语的列表，
表18是状态转变表，说明所应用的例外事件的综述，以及
表19表示应用于根据本发明的端对端协商协议(E2ENP)的应用计时器。
本发明的详细说明
根据本发明的一个实施例，E2ENP UA 128支持以下平台：Win32和Linux。质量、健壮性、可维护性、可扩充性、灵活性和效率是该体系结构及其解决方案的难题。
-质量包括已经在发展过程中的***的可测试性和检验。健壮性是***在出错情况中也保持稳定和可用的能力。两个目标直接影响***的可用性和接受。
-可维护性和可扩充性包括在以后阶段中***的全部费用(涉及纠错和扩充)。这些费用必须为最小。
-灵活性还针对改变应当以尽可能节省成本的方式来应用的方面。
-效率针对资源使用的最小化(涉及存储器和处理器)。
对于此体系结构，可得出以下基本概念和技术要求：
◆具有适当选择和定义的责任及特征的设计组件的定义；
◆设计组件之间的小相关性(松耦合)，使得改变仅具有有限的影响；
◆最小资源消耗，尤其是涉及所应用的随机存取存储器(RAM)；
◆接口和实现之间严格的分隔(实现的改变不会影响接口)；
◆限制的定义，如果这简化了实现概念-但是，限制及其影响必须与风险承担者协商。
图1所示的E2ENP UA 128设计为通过以下五个API与环境通信的软件组件：
●E2ENP管理API 101a(IF1)：在配置、监测和控制方面，这个API表示E2ENP UA 128与管理它的任何实体102之间的接口。
●E2ENP UA API 101b(IF2)：这个API表示E2ENP UA 128与利用所述E2ENP UA 128提供的服务的任何应用130或中间件之间的接口。通过这个API交换的信息可建模为由设置在E2ENP UA 128之上的应用130或中间件130相应地解释的对象结构或基于XML的文档。
●SIP UA通用API 101c(IF3)：这个API表示E2ENP UA 128与用于实现E2ENP规范的会话层协议之间的接口。这个API的名称清楚地表明，[Ros1]中所述的会话发起协议(SIP)用作参考会话层协议。但是，通过较小的修改，这个API可易于在以后的设计审查中一般化，从而消除E2ENP UA对SIP的依赖性。不过，通过利用这个设计，能够具有SIP UA通用API 101c(IF3)的完整Java远程方法调用(RMI)实现。
●分析器API 101d(IF4)：这个API表示E2ENP UA 128与用于对E2ENP会话描述解码的任何分析器实现112之间的接口。
●工厂API 101e(IF5)：这个API表示E2ENP UA 128与用于对E2ENP会话描述编码的任何工厂工具114之间的接口。
在内部，E2ENP UA 128由处理与上述接口及其相互关系关联的程序的协调的不同有限状态机106(FSM)组成。更明确地说，E2ENPUA 128应当主要包含客户机FSM 106和服务器FSM 106，用于独立且同时地分别处理E2ENP(预)协商的发起和/或会话建立以及对这类程序的响应。这意味着把接口101b(IF2)的原语映射到接口101c(IF3)的原语，或者反之。原语的映射涉及对象以及对象标识符映射。映射的对象和标识符存储在E2ENP UA 128上的相应高速缓存104中和/或IF2以上的应用130处。
在这个映射过程中，E2ENP UA FSM 106还应当能够访问接口101d(IF4)和101e(IF5)，用于分别处理E2ENP会话描述解码和编码。
虽然是用于实现E2ENP概念的必要实体，但分析器和工厂实现112、114分别设计为分开的软件组件，使得它们可以各种方式来实现(基于SDP、SDPng、SDPng方言或其它任何精选的会话描述语言)。
在以下小节，将描述***的基本问题域以及它们在E2ENP UA128中是如何解决的。每个问题域单独在***上论述。如果存在对其它问题域的干扰，或者问题域的一部分在另外的部分更详细地论述，则它引用其它问题域。
E2ENP UA 128根据面向对象的范例来设计，以及根据这种设计的基于Java的原型据此进行描述。它允许采用各种XML分析工具(通过IF4)和各种会话级协议(通过IF3)来传输E2ENP原语。基于上述E2ENP UA设计的据此描述的原型采用如[Ros1]所述的SIP作为会话层协议。由于IF3的抽象性，因此各种SIP实现由E2ENP UA设计来支持。
在本发明的范围中，E2ENP UA FSM 106和SIP UA通用API(IF3)都明确地设计成支持SIP。预计在未来的设计审查中，这些相关性将通过使IF3甚至更为抽象来消除。E2ENP UA 128还能够利用E2ENPUA服务的多个示例同时支持多个应用130的多个用户。
E2ENP UA 128支持三种对象类别：标识符(ID)、描述对象(对象图或对象图的形式描述、如XML)以及事件对象。这些类别对应于以两个方向通过IF2、IF3、IF4和IF5传递给代理的对象。
-需要ID来唯一标识会话描述对象。存在也作为对象的两种标识符：
●E2ENP内部对象ID，对应于E2ENP UA FSM 106中处理的对象，
●应用ID，也指向相应的E2ENP UA FSM 106对象，它们由应用130用来操纵协商事件。
-会话描述对象是由E2ENP UA FSM处理使用的对象图或者是分析器实现112、工厂实现114和E2ENP UA 128根据协商过程使用的外部描述。所有这些会话描述对象可由使用它们的应用130(在IF2以上)来持久保存。保存对象的管理(租赁描述、租赁描述的刷新等)是应用特定的任务。
-事件对象对应于应用协商事件，它们通过触发自适应序列来影响E2ENP UA FSM 106的功能性。
ID、E2ENP UA FSM对象图和事件对象为Java对象。外部协议表示可以是SDP、SDPng、SDPng方言或精选的其它任何会话描述语言对象。通过接口IF2传递的Java对象的实现取决于IF2的接口定义。通过接口IF4和IF5传递的对象是E2ENP UA FSM 106对象表示或者外部协议表示。通过IF3传递的对象是外部协议表示。通过IF3、IF4和IF5传递的会话描述对象的所有外部表示应当实现java.io.Serializable，以便与SIP代理RMI实现兼容。
通过IF2、IF3、IF4和IF5传递的会话描述对象的内部表示应被确定为java.lang.Object类型，并且应当由E2ENP UA 128、分析器112和工厂114转换为预计类型。这种要求是通过平衡(leverage)通用API使SIP UA 110以及分析器112和工厂114的实现保持模块化所必要的。
以下部分包含分析器112和工厂114的应用实现的简述。
由于协商过程涉及通过网络互连的至少两个实体，因此必需提供从***内部表示到网络上的传输表示和反向的映射功能性。提供这种映射的机构称作分析器API 101d(以下仅称作分析器112)和工厂API101e(称作工厂114)，其中，分析器112把以网络表示编码的对象作为输入，并产生所述对象的***内部表示。相反，工厂114产生给定***内部表示的网络表示。
对于所述分析器API 101d、所述工厂API 101e以及它们所定义的功能性的需要由以下事实所产生：***内部表示可能不适合于可通过网络发送的传输表示，以及传输表示可能不适用于***内部表示。
另外，把这些组件引入***把较高的应用层与较低的面向传输层分离。因此，实际使用的传输协议对于高应用层无关紧要，并且在理论上应当是可插拔的。
可扩展标记语言(XML)作为传输语法的使用是由于广泛采用XML作为工业标准来促进的，并且它还允许内部特征(SDPng库和简档)的结合以及提供与相关工作(SDPng模式)的兼容性。XML的另一个特征是其简单可扩充性。
如上所述，不同载波协议的使用要求分析器112和工厂114是通过与协议同样的方式可配置的，这意味着，如果协议在运行时是可配置的，则所述分析器112和所述工厂114也可能在***正运行时必须被改变。这意味着抽象接口的指定，因为实际实现取决于特定基础载波协议。
不同载波协议的具体工厂114实现将产生不同的结果。例如，RMI工厂可能只是一种伪实现。因此，能够仅通过使用Java远程方法调用(RMI)，直接通过网络连接来传递Java对象、如对象“as is”。
但是，如果SIP用作载波协议，则必须产生要通过网络发送的外部表示(更明确地说是协议数据单元或PDU)。可能性包括但不限于例如与SDP类似的某个专有文本格式，或者例如SDPng那样采用XML的更结构化方法。
分析器API 101d和工厂API 101e的API定义没有确定类型，以便支持E2ENP UA 128和分析器112以及工厂114的松耦合。如上所述的传输表示仅通过采用固有地无类型的java.io.Serializable接口来实现。***内部表示选择成表示为java.lang.Object。分析器112和工厂114的实际实现与E2ENP UA 128中使用的对象表示之间的匹配必须通过配置来建立。
该机制通过以下两个软件组件来实现：
◆分析器API 101d：这个API的原语应当作为参数接受实现java.io.Serializable接口的任何对象。分析过程的结果产生根据IF2的对象表示，它抽象地确定为java.lang.Object类型。
◆工厂API 101e：这个API的原语应当作为参数接受根据IF2的任何对象表示，它抽象地确定为java.lang.Object类型，并产生符合java.io.Serializable接口的表示。
另外，为了实现可配置性，“工厂设计模式”用于创建分析器112和工厂114示例是一种可能的解决方案。为此，工厂方法采用传输协议来参数化(不同分析器112/工厂114实现的区别特征)。如果需要对不同载波协议的动态支持，则工厂类必须为新的协议提供注册程序。
在下一个部分，简要描述SIP代理的使用。
所应用的SIP UA通用API 101c(IF3)要求支持这种API的SIP UA实现的可用性。同样，分析器API 101d(IF4)和工厂API 101e(F5)假定分别与UA实现110兼容的分析器和工厂实现的可用性。为了允许对E2ENP模型进行验证和快速原型设计，IF3、IF4和IF5的设计方式是：实际SIP UA实现的代理以及兼容分析器112和工厂114实现的代理可用作便利的备选方案，用于实验目的。
通过使用SIP UA 110的继承实现(已经提供的代码/API和/或软件，可能来自外部实施者)用于测试和/或更新E2ENP UA 128，可能有时难以建立E2ENP UA 128与SIP UA 110之间的连接，因为继承SIP实现提供的接口可能不直接匹配E2ENP UA所要求的接口101c。一般来说，每当测试新的E2ENP UA 128特征时，由于协议代理(SIP与E2ENP)之间可能的概念矛盾，不建议利用SIP UA 110来提供E2ENP UA 128的网络连通性。这些矛盾可能导致载波协议-SIP的规范变化，这就是对于E2ENP UA 128的测试，SIP仿真器(它可易于采用概念变化)的使用更可取的原因。
为了执行SIP仿真，可采用SIP代理(例如远程过程调用机制RPC)。当E2ENP会话描述净荷必须被测试、而不一定采用“成熟的”分析器112和工厂114实现时，也可运用与所选SIP代理结合的解决方案。
如上所述，基于据此提出的体系结构模型的原型E2ENP UA 128实现已经被选择用于证明E2ENP概念。由于这种实现基于Java，因此基于RPC的内建Java RMI机制已经被选作SIP代理。
由于RMI直接管理对SIP UA通用API 101c(IF3)原语净荷的编组或解组，因此传递给API的所有参数必须实现java.io.Serializable接口。
为了测试E2ENP会话描述净荷而不一定采用“成熟的”分析器112和工厂114实现(由于以上对SIP代理的使用阐述的同样原因)，通过IF3作为字符串传递这种内容可能是不需要的，因为RMI能够处理对象。相反，表示给定E2ENP会话描述净荷的整个对象结构可能直接通过RMI编组或解组机制来交换。因此，根据据此提出的体系结构模型的原型E2ENP UA 128实现的设计方式是：IF3原语将作为参数接受实现java.io.Serializable接口的任何对象，而不只是java.lang.String类的示例。
所述机制通过以下软件组件来实现：
◆SIP UA通用API 101c：这个API的原语将作为参数接受实现java.io.Serializable接口的任何对象，而不只是java.lang.String类的示例。SIP UA 110实现将经由类型转换机制把所传递对象解释为java.lang.String类的示例。RMI代理SIP实现将直接对上述对象“asis”进行串行化或解串。
◆分析器API 101d：这个API的原语将作为参数接受实现java.io.Serializable接口的任何对象。
◆工厂API 101e：这个API的原语将作为参数接受实现java.io.Serializable接口的任何对象。
图2表示根据特定SIP UA 110实现(例如基于Java的SIP栈-JSIP)以及根据处理SDPng的修改版本的工厂114和分析器112实现的上述体系结构模型的实现。
图3表示根据RMI SIP代理的上述体系结构模型的实现：在这种情况下，工厂114b和分析器112b实现只是伪的。
伪ParserFactory(分析器工厂)118b和伪FactoryFactory 120b分别创建“伪分析器”运行时示例112b和“伪工厂”运行时示例114b。
虽然表示为“伪”，但所述分析器112b和所述工厂114b仍然可检查和/或实施，用于对象图中的对象被确定为“java.io.Serializable”类型。
图4表示利用基于套接字的SIP代理的上述体系结构模型的实现：在这种情况下，工厂114c和分析器112c实现只是伪的。不过，也可使用SDPng分析器112a和SDPng工厂114a，利用适当适配器126c通过套接字来发送基于XML的字符串。原语以手动方式映射到要通过套接字发送的消息，从而实现专有远程过程调用(RPC)机制。
伪FactoryFactory 120c和伪ParserFactory 118c分别创建“伪分析器”运行时示例112c和“伪工厂”运行时示例114c。
虽然表示为“伪”，但所述分析器112c和所述工厂114c仍然可检查和/或实施，用于对象图中的对象被确定为“java.io.Serializable”类型。
在以下小节，在根据本发明的E2ENP UA 128的范围内应用的软件组件将从组件的角度简要说明。对于各软件组件，描述其要求、所提供服务和约束，还描述它与其它软件组件的关系。这个描述用作详细设计的基础。
图1表示所有软件组件及其使用关系。软件组件分配到某层，并且可与相同或下层的组件有关系，但与上层的软件组件没有关系。这些层没有封装下层的严格意义。
因此，采用给定API所提供的服务的实体将被称作服务用户，而实现所述API的服务的实体将被称作服务提供商。
根据[BRENTA]所述的BRENTA模型，E2ENP UA API 101b(上述IF2)把E2ENP UA功能性向服务用户、如QoS感知应用130和/或QoS中介器130显示。这个组件通过定义一组接口以及通过所述API交换的复杂数据类型，实现通用API的规范。
因此，所述E2ENP UA API 101b允许服务用户的多个示例同时访问E2ENP UA 128功能性。更明确地说，E2ENP UA 128提供如[ReqSpec]中所述的下列服务：
1.多个备选能力和/或QoS合同(在应用和网络级)的预协商；
2.租赁预协商信息的管理；
3.采用多个备选能力和/或QoS合同(在应用和网络层)的协商的会话建立，可能引用预协商信息；
4.与第2点相同，但采用附加的本地、对等体及网络资源保留协调；
5.重新协商，与第2和第3点相似；
6.会话释放，采用可能的保留释放协调。
为了暴露这些服务，E2ENP UA API 101b将分别暴露下列原语：
1.预协商；
2.leaseRenewal，它可用于刷新或终止租赁；
3.协商，参数化以表明是否要求资源保留协调。如果要求资源保留协调，则E2ENP UA 128允许提议方侧的服务用户经由bookNegotiation和/或bookRenegotiation原语预订对资源保留阶段的互斥访问。
4.重新协商：如果如原始协商阶段中所要求的已经指定资源保留协调，则E2ENP UA 128允许提议方侧的服务用户经由bookRenegotiation原语预订对资源保留阶段的互斥访问。
5.释放。
E2ENP UA API 101b根据下列设计原理来设计：
1.根据ISO/OSI模型，原语被分类为请求(Req)、指示(Ind)、响应(Rsp)和确认(Cfm)原语。请求(Req)和响应(Rsp)原语由客户机应用130或中间件130实现(又称作服务用户)来调用，以便分别发起或响应特定消息交换。(在一些情况下，由于给定E2ENP UA实现所提供的抽象，消息交换可调用在对等体之间交换的一组不同消息，而在另一些情况下，消息交换仅限于给定消息及其确认。)指示(Ind)和确认(Cfm)原语由E2ENP UA 128(又称作服务提供商)调用到服务用户130的注册客户机端，以便分别指示特定消息交换的到达或者确认给定消息交换的结束。(同样，在一些情况下，由于给定服务提供商提供的抽象，消息交换可调用在对等体之间交换的一组不同消息，而在另一些情况下，消息交换仅限于给定消息及其确认。)服务用户130的客户机端必须实现这些原语。对于发起给定协议消息交换的对等体产生的请求原语，对应目标对等体上的指示(Ind)原语。对于响应给定协议消息交换的目标对等体产生的响应(Rsp)原语，对应发起对等体上的确认(Cfm)原语。
2.为了区别不同的服务用户130，E2ENP UA 128在接口101b(IF2)对每个注册服务用户130暴露一个服务接入点(SAP)。因此，任何给定服务用户130可在所述接口101b(IF2)以一对多关系使用一个以上SAP。
3.用户一次只可向一个服务用户130登记，它意味着每个用户在所述接口101b(IF2)最多与一个SAP关联。
4.为了同时独立地使用不同会话层协议110(例如各种SIP实现和/或RMI)，E2ENP UA 128在接口101c(IF3)对每个注册的会话层协议暴露一个SAP。
5.为了适当地关联服务用户130与基础会话层协议，E2ENP UA128在接口101a(IF1)暴露适当的配置机制，它允许以一对一关系来关联接口101b(IF2)上的SAP与接口101c(IF3)上的SAP。这样，使用给定类型的应用130的用户将自动透明地使用所配置的关联会话层协议。
6.当配置接口101c(IF3)上的SAP时，自动进行E2ENP UA 128与会话层协议110的绑定。通过接口101c(IF3)上的给定SIP UA 110通用API，在向E2ENP UA 128注册用户时，进行相反方向的绑定，并且这导致用户对已配置会话层协议110的注册。
7.服务用户130对E2ENP UA 128的双向绑定通过bindReq和bindCfm原语来进行，其中参数之一是特殊标识符，以及SAP ID(spId)唯一地标识接口101b(IF2)上的已配置SAP之一。
8.任何给定服务用户130的任何给定用户通过registrationReq和registrationCfm原语在适当的上SAP上注册他/她本身，其中，参数之一是上述spId，它唯一地标识接口101b(IF2)上选择的SAP。
9.为了在本地发起任何E2ENP会话时选择适当的上SAP，下列原语现在表征表明本地注册用户的新参数“String user”，它唯一地标识所述用户注册到的接口101b(IF2)上的SAP：
-renewLeaseReq以及
-bookNegotiationReq
10.为了在本地发起任何E2ENP会话时选择适当的上SAP，下列原语的现有“String form”参数表明本地注册的用户，它唯一地标识所述用户注册到的接口101b(IF2)上的SAP：
-preNegotiationReq以及
-negotiationReq
11.应用或中间件FSM 130的示例以及E2ENP UA FSM 106的示例分别由serviceUserId(服务用户标识)和serviceProviderId(服务提供商标识)唯一地标识。
12.如[Gam]中所述的“观察者设计模式”的一种简化形式(以具有Java Beans事件模型的派生的Java来实现)提供允许服务用户130(经由称作“Bind Request(绑定请求)”的原语)为指示(Ind)和/或确认(Cfm)原语回调注册的机制。
13.为了允许支持E2ENP信令可扩充性，大部分原语允许传递净荷：当今，这些原语中一部分实际上不是设计用于携带净荷，但存在对E2ENP规范复查的可能性。因此，可能要求一些附加的E2ENP信息搭载。
14.为了允许不同类型的服务用户130访问E2ENP UA 110的服务，净荷被确定为Java根类java.lang.Object类型：这样，应用130或中间件可使用要经由E2ENP交换的信息的内部自定义表示(例如基于XML的表示)，或者借助于上述缺省信息结构。
因此，所述E2ENP UA API 101b取决于使用所述E2ENP UA 128的服务的相应应用130和/或中间件130，所应用的E2ENP UA FSM106，涉及请求(Req)和响应(Rsp)原语的实现以及所应用的工厂114和分析器112：这些组件的所选实现规定用于通过这个API交换的信息的表示类型。
E2ENP UA API 101b借助于面向对象的范例来设计，因而利用统一建模语言(UML)在此进行描述。以上描述了要经由E2ENP交换的信息。组件由如图5所示的基本包org∷mind∷e2enp组成。
下列接口属于这个基本包：
-Provider(提供商)504表示符合所附规范的E2ENP UA服务提供商实现将支持实现请求(Req)和响应(Rsp)原语的接口。表1列出Provider接口504暴露的原语。
-E2ENPUserAgentListener(E2ENP用户代理收听器)502使服务用户将为截收E2ENP UA 128产生的指示和/或确认(Cfm)原语而实现的所有接口一般化。
表2列出E2ENPUserAgentListener接口502暴露的原语。
E2ENPUserAgentListener接口502被专门化为OffererListener(提议方收听器)接口506和AnswererListener(应答方收听器)接口508。前者是专门为应用或中间件发起的E2ENP过程而设计的；后者是专门为响应所述E2ENP过程的应用130或中间件130而设计的。
表3列出OffererListener接口506暴露的原语，以及表4列出AnswererListener接口508暴露的原语。
通过预协商和协商原语传递的“to/from”参数是标识E2ENP用户(分别为提议方和应答方)的地址。E2ENP UA 128把这些地址映射到用于搭载E2ENP信息的给定会话层协议所用的特定语法：在这种写入的情况下，为SIP。因此，E2ENP地址与特定会话层协议以及可能与底层由E2ENP UA 128使用的传输协议无关。为此，在此提出已经专门为E2ENP设计的新语法。
图5bis表示通过面向对象的范例设计的、E2ENP UA工厂108与管理实体102之间的E2ENP管理API 101a(IF1)。因此，E2ENP管理API 101a(IF1)由下列组件所属的基本包组成：Manager-Provider(管理者-提供商)接口510和ManagerListener(管理者收听器)接口512。对于经由所述接口IF1的分析器实现112和工厂实现114的配置，采用类ConfigurationRequest(配置请求)514和ParserFactoryConfiguration(分析器工厂配置)516。
图6通过利用扩充巴克斯-诺尔范式(ABNF)提供这种通用资源标识符(URI)语法的格式描述。因此，所述规范与[Ros1]所述的SIP URI语法规范相似，但特意没有指明任何传输协议参数，除了IP地址和/或端口号之外。作为E2ENP URI的一个实例，“e2enp://dave:[email protected]”表示在“acme”机构中的名为“Dave”的用户，使用密码“vG$1809”。“//”指示是当地址中没有指明用户时用于缺省用户情况的分隔符的一种形式。实例“e2enp://:xyz％[email protected]”表示具有密码“xyz％45637”的缺省用户(没有指明)。
E2ENP地址组件的完全或部分使用取决于域模型(代理机制)和地址解析机制，它们主要是相应地应用的会话层协议(例如SIP)的一部分。如果会话层协议已经提供某种代理机制和/或重定向机制来标识网络路径，则E2ENP UA 128应当至少使用用户(缺省用户)名称和域名来标识通信合作方。
在以下小节中，E2ENP UA API 101b执行的过程将通过一组UML消息序列图(MSC)来描述。
图7根据通过E2ENP API的原语交换来说明简单的预协商情况。对于这些原语，特定传输协议消息在OffererServiceProvider 704与AnswererServiceProvider 706之间交换，但为了一般性，它们没有在图7中标明。
图8说明简单会话建立情况的MSC，其中QoS协商和资源保留协调过程被突出显示。在所提供的情况中，为了简洁起见，来自提议方侧的资源保留完成的确认在应答方侧发生同样情况之前到达。同样，为了简洁起见，这个简单情况假定，资源保留过程成功地确切保留最初请求的资源量。
重新协商过程与协商过程相似，只不过原语的名称被如下变更：
  旧名称   新名称
  bookNegotiation<type>   bookReNegotiation<type>
  negotiation<type>   reNegotiation<type>
  negotiationStatus<type>   reNegotiationStatus<type>
高速缓存104是用于保存不同对象标识符的数据库。为了分离服务用户标识方案与为E2ENP[ReqSpec]指定的一个，E2ENP高速缓存104用于：
◆保存和检索在[ReqSpec]中指定的E2ENP会话标识符，
◆保存和检索由E2ENP UA FSM 106处理的E2ENP会话标识符(serviceProviderId)，以及
◆保存和检索E2ENP UA API服务用户的会话标识符(serviceUserId)。
高速缓存104应当可搜索不同标识符，并且遵循E2ENP UA 128设定的不同标准。E2ENP UA 128负责高速缓存管理。
高速缓存对象对应于标识符对象类别。高速缓存104维护两种类型的数据：
◆预先高速缓存的数据：在给定E2ENP预协商或协商过程的执行中，E2ENP UA预先高速缓存信息(根据serviceProviderId作为主关键字以及serviceUserId和[ReqSpec]中指定的E2ENP会话标识符作为次关键字进行索引)。一旦成功完成给定的过程，预先高速缓存的数据保持被高速缓存，使得E2ENP UA API 101b服务用户在如[ReqSpec]中所述的稍后的E2ENP会话中可以引用这种数据。
◆高速缓存的数据：这个信息可在以后在新的E2ENP预协商或协商过程中用作对已经在对等体之间(预)协商的数据的引用。对于所述E2EPN会话中的每个，高速缓存104存储给定ServiceUserId与[ReqSpec]中所述的相应E2ENP会话标识符之间的关联。这个高速缓存104中的每个条目在对等体之间被租用，并且应当随时间刷新，如[ReqSpec]中所述。服务用户130本身负责管理其本身的租赁和(预)协商信息。高速缓存104只是非持久地存储先前E2ENP会话之间的相关。
E2ENP高速缓存104是用于管理协商对象ID的数据库。E2ENPUA FSM 106请求高速缓存104服务。在本发明的一个实施例中，高速缓存104设计成相互引用的一组java.util.Hashtable对象。基于元组(tupel)-空间技术的一个备选实现留待进一步研究。
为了使E2ENP UA 128实现保持简单，高速缓存104与E2ENP UAFSM 106之间的高速缓存API 103表示同步接口。
在本发明的实现形式中，采用两级高速缓存104：
◆所述高速缓存104的第一级(L1)用以下元组的形式(serviceProviderId，serviceUserId，FromSIPAddress，ToSIPAddress，E2ENPSessionID)来保存预先高速缓存的信息，其中FromSIPAddress和ToSIPAddress允许检测双重占用；主关键字是serviceProviderId。
◆所述高速缓存104的第二级(L2)用以下元组的形式(serviceUserId，E2ENPSessionID)来保存预先高速缓存的信息，其中主关键字是serviceProviderId。
高速缓存104的两级实现为[Gam]中所述的两个不同的单态对象，它们由E2ENP UA 128发起和管理。高速缓存对象在E2ENP UA128的示例内运行。图9描绘包含高速缓存实现的org∷mind∷e2enp∷Cache子包的UML类图。
单态LevelOneCache 902和LevelTwoCache 904分别表示高速缓存级L1和高速缓存级L2，并提供用于创建、搜索和释放高速缓存条目(分别为LevelOneEntry 906和LevelTwoEntry 908)的API。
第一和第二高速缓存级(L1和L2)的API提供的方法分别如表5和表6所示。
在以下小节，基于XML的串行化传输表示将通过XML模式定义来定义。不是从零开始定义这种格式，传输表示是基于并使用基线SDPng格式定义。除了提供兼容性之外，还能够使用并受益于为如[Kut2]所述的SDPng设计的第三方库和简档定义。实例包括但不限于实时协议(RTP)以及音频和视频编解码器简档。
为了说明工厂API 101e和分析器API 101d如何共享公共传输表示语法，以下小节为这种格式提供一个可能的定义。E2ENP的XML描述扩展及使用基线SDPng XML描述格式。
E2ENP的XML表示(E2ENP在下文中将同义地用于这个表示)已经选择为对于SDPng基线XML定义的扩充。这种决定的主要原因在于，预计SDPng将由IETF标准化，这产生一些主要利益：
◆作为SDPng的扩充的E2ENP将能够受益于对于SDPng之类的简档和库定义的外部贡献。已经有SDPng草案[Kut2]中指出的实例，即音频和RTP简档。这些扩充已经结合到E2ENP XML的规范中。
◆实现未来SDPng标准的应用130可在理论上通过仅把E2ENP模块链接到应用130，更易于增强到还支持E2ENP。同样，在异构环境中，不支持E2ENP的应用130仍然能够与SDPng特定的部分配合，并且没有完全破坏互通性。
E2ENP XML表示由W3C所定义的XML模式定义正式规定。模式定义可大致分为三个部分，一个包含诸如属性值的枚举等类型定义或者公共内容模型作为复型的定义。主要部分定义顶层E2ENP部分(即元素)，它还利用替换组机制被***SDPng。最后，第三部分定义与SDPng没有关系的E2ENP特定的元素，它们用来完整地定义顶层元素的内容模型。
在图10中可以看到，descType 1001-最初在SDPng中定义的-按照下列方式重新定义：E2ENP特定的首标部分“purpose(目的)”1002表现为“desc root(描述根)”元素的合法子。E2ENP定义“qosdef”部分，它可用作“sdpng:d”元素的替代，即“sdpng:def”1003部分的唯一有效子，同样，“qoscfg”可用来代替“sdpng:c”，又作为“sdpgn:cfg”1004部分的唯一有效子。下面将描述E2ENP特定元素类型。
对SDPng的扩充和***在图11中说明，它表示替换组中的元素如何可用来替代该组的头元素。
这里，“sdpng:d”1107是头元素，它可由替换组的成员中的任一个来代替，即“audio:codec(音频：编解码器)”1108、“e2enp:qosdef”1109、“rtp:pt”1110、“rtp:transport(rtp:传输)”1111(它又再次作为嵌套替换组的头元素)以及“video:codec(视频：编解码器)”1113。这样，通过使用与XML名称空间概念结合的替换组机制，能够定义对任何XML模式定义的模块化扩充。另外，替换组成员“rtp:udp”1112可进一步扩展，以便支持[Bos2]中所述的选项子组，从而结合与[Bos2]所建议的相似的选项(图11中未示出)。
上述“qoscfg”元素1400在以“sdpng:c”开头的替换组中定义，“sdpng:c”又是“sdpng:cfg”部分的有效子。
利用图12中所示的“purpose”1201元素，能够传递关于外部描述中的协商过程的附加信息。如何定义目的元素的一般结构如图12所示。
因此，首标定义当前消息属于哪个会话。通过“use(使用)”1202元素还可建立对先前会话的引用，使得能够引用来自这些会话的定义。
根据E2ENP消息要用于什么方面，应当提供“description(描述)”1203或者“mediation(调解)”1204元素。例如，借助于“description”1203元素，能够说明消息的种类、即请求(Req)或响应(Rsp)，以及应当使用什么协商模式(推、拉、推-拉)。
图13说明“qosdef”元素1300的一般结构。但是，存在对合法子元素的使用的限制，取决于qosdef元素1300的“name(名称)”属性的值。存在两个可能的值，即“capabilities(能力)”和“contracts(合同)”。根据那个方面，“qosdef”部分1300或者指定对等体的能力，或者在合同的情况下，定义已经由利用E2ENP UA 128的实体验证的有效合同。
-指定能力：如果“qosdef”元素1300的“name”属性值为“capabilities”，则有效子元素为“audio:codec”1301、“video:codec”1302和“rtp:pt”1303。相应的编解码器元素以音频和视频编解码器及其配置来表示对等体的***能力。通过使用“rtp:pt”1303元素，能够指定给定能力的预期RTP净荷格式。
-指定合同：在这种情况下，qosdef元素1300的“name”元素的属性值必须为“contracts”。然后，有效子元素为“policy(策略)”1304、“audio(音频)”1305和“video(视频)”1306。“policy”元素必须正好出现一次。它指定协商要强制执行的资源管理策略的使用。能够使用策略来优化***性能的一个或数个方面，例如存储器使用、CPU负荷、网络业务量或功耗的优化。为了实现更大的灵活性，这些原子方面可通过使用谓词来组合。“policy”1304元素之后的元素可以是一个或许多个“audio”1305、“video”1306、“data(数据)”1308和“control(控制)”1307元素。这些元素描述相应数据流的QoS合同。通过使用“rtp:map”1309元素，能够定义应用层QoS合同与特定RTP净荷格式之间的映射。
图14说明“qoscfg”元素1400的一般结构。这个部分允许定义自适应路径(AP)以及在各种抽象层的QoS相关和时间同步约束，从流层QoS合同开始。各抽象层由这个部分的属性“name”来标识。可能的值包括“stream(流)”、“stream-group(流-组)”、“session(会话)”和“application(应用)”。因此，自适应路径的定义在不同层是可行的，其中包括流层自适应路径以及高层AP。“context(上下文)”1401元素定义给定流的可能关联，从而允许定义时间同步和/或QoS相关约束。因此，“context”1401元素基本上描述高层QoS合同。
在以下小节，将给出分析器API 101d的简要概述。
分析器API 101d提供原语，它们可用来分析某个传输表示中的描述，并根据IF2产生对象表示。为了能够松耦合E2ENP UA 128和分析器112，这个对象表示以表达为java.lang.Object的方式来抽象。如已经指出的那样，传输表示的唯一要求在于，它实现java.io.Serializable接口。这可在传输表示是无类型的意义上来解释，从而提供与这个表示可实际上看起来的样子有关的更大灵活性。
传输表示可包含对外部先前定义的实体的引用。这些引用保留不变并且没有被分析器112解析。这个问题稍后在E2ENP UA 128或者高层实体中处理。
分析器API 101d为要传递的每个消息类型提供一个原语。这样，消息类型隐式表示，并且不需要在对象模型中考虑。对于各消息类型，分析器112提供一个原语来分析相应消息类型的提议和应答。因此，图15所示的用于分析器API 101d原语的一般模式为
对象分析XXX(可串行化输入)。在此，“XXX”表示用于像NegOffer或PreNegAnswer等原语的名称的占位符(参见以下API定义以获得更多详细情况)。
除了这些一般分析方法之外，分析器API 101d还提供用于浏览串行化表示中包装的内容的某些专门原语。这些原语可由客户机用来独立于实际表示来访问某个抽象层上的特定信息或数据。因此，如果表示因将来协议增强而改变，则使用表示的较旧版本的客户机没有受到新变化的影响，因为信息访问方法没有改变。
由于实际的载波协议应当是可交换的，因此也需要提供功能性来交换实际分析器112实现。如上所述，这个机制对于分析器112实现以及对于载波协议必须是同样的。
因此，ParserFactory API被定义，它提供原语来创建实际分析器112实现示例(图1所示的工厂118表示这样一种ParserFactory的实现)。另外，还能够为任何给定载波协议注册新的实际分析器112实现。
E2ENP UA 110与分析器112之间的通信可能是异步的，例如由主动请求接口和被动确认接口来实现。但是，这个选项不适合于基础设计，因为性能及灵活性的某种增益与E2ENP的FSM 106的更为复杂的状态模型不相容。这个判定的一个结果是，E2ENP UA 128和分析器112(以及还有工厂114)同步地通信，因而必须共用公共地址空间，这在大部分情况下是合理的假定。
这个判定的另一个结果是，分析器112(以及还有工厂114)必须被设计为线程安全、可重入的库。
在分析过程中产生的并作为结果回送给调用E2ENP UA 128的对象表示通过仅使用java.lang.Object类来极抽象地描述，以便提供分析器112与E2ENP UA 128的松耦合。实现在E2ENP UA 128中使用的给定传输表示和给定对象模型的分析器112的实际类必须通过配置来装配在一起。
实际分析器和工厂实现112、114必须分别约定传输表示的公共格式。三种格式的定义是实现特定的，并且对应于实际分析器112和工厂114组件，即使鼓励和设想现有标准的使用。因此，一种格式已经被定义，它与基线SDPng定义兼容。
ParserFactory API提供的注册功能性可用不同方式来处理。但是，这归实际ParserFactory 112实现负责。可能与注册有关的一些选项为：
◆注册可永久地存储，以便继续存在于多个应用寿命周期。
◆可使注册变为公共的，供其它应用130使用，这也意味着永久存储。
◆注册对于当前应用寿命周期只可按短暂方式来存储。
应用130可检查它们是否已经通过调用这些示例的相应getType()方法并比较相等性的返回值，来例示分析器112和工厂114的匹配对。分析器112和工厂114的不匹配对被应用130使用可能导致不可预测的结果以及未定义、甚至是错误的行为。
下面简要总结相关性。
◆IF2对象模型：这只是隐含的相关性，分析器112的实际实现必须履行。一般来说，这种相关性通过分析器112仅创建java.lang.Object示例的事实来消除。但是，在实际上要创建的特别配置的***中，特定对象模型类的示例用于E2ENP UA 128中。
◆传输表示：与以上相关性相似，实际分析器112无疑需要它必须创建的明确定义的结构。因此，它取决于传输表示的相应定义。但一般来说，通过利用java.io.Serializable抽象地描述传输表示，这个相关性从设计中消除。
要由分析器API 101d实现的原语可取自表7。相反，要为产生特定分析器112所实现的原语在表8中列出。
ParserFactory API通过包org.mind.e2enp.content中的类E2ENPContentHandlerFactory来实现，又称作分析器-工厂实现。它设计为单态示例，使得它的所有客户机可使用先前进行的注册。目前，所创建的单态示例是缺省实现，但对于将来的版本，计划提供可配置的方式(根据特定***属性)来确定要用于单态示例的类。E2ENPContentHandlerFactory类所提供的方法如表11所述。
在以下小节，简要描述基于XML的传输表示所需的分析器112的实现。由此提出基于XML的传输表示的可能的分析器112实现。图17描述作为类DocumentTree(文档树)1702建模的文档对象模型(DOM)树的一般结构，它聚集一个DocumentNode(文档节点)1704，并且可解释为文档根元素。每个DocumentNode 1704又在0与N个子之间聚集，从而递归地描述树结构。
这个表示的分析器112可通过利用如[Gam]中所述的“访问者设计模式”来实现。结构概述如图18所示。因此，通用分析器112访问者类pVisitor 1808被定义以使用，或者为精确访问1至N个DOMNode 1806。为了处理每个特别导出的DOMNode子类的导出DOMNode，专门访问者被定义。(即使“访问者模式”被设计用于仅处理子类，这个概念也可易于通过以下方式来扩展：不同元素节点被解释为其自身的类别。)
下面简要描述应用于工厂114的应用编程接口(API)。
工厂API 101e提供原语，它们可用来根据IF2为给定对象表示创建传输表示。E2ENP UA 128与工厂114的松耦合经由对象表示(经过工厂接口101e)作为java.lang.Object的抽象来实现。如已经指出的那样，传输表示的唯一要求在于，它实现java.io.Serializable接口。因此，这个API定义的原语均返回“java.io.Serializable”对象。
对象描述可包含对外部先前定义的实体的引用。这些引用不是通过工厂方法来处理或解除引用的，它们只是被使用。
与分析器112相似，工厂API 101e为要传递的每个消息类型提供一个原语。这样，消息类型被隐式表示，并且不需要在对象模型中考虑。图19所示的用于工厂API原语的一般模式为：
可串行化创建XXX(对象输入)在此，“XXX”表示例如NegOffer或PreNegAnswer等原语的名称的占位符(参见以下API定义以便获得更多详细情况)。
由于实际的载波协议应当是可交换的，因此还需要提供功能性来使实际工厂114实现成为可交换的。如上所述，这个机制对于工厂114实现以及对于载波协议必须是同样的。因此，FactoryFactory API被定义，它提供原语来创建实际工厂114实现示例。(图1中的工厂120表示这样一种FactoryFactory的实现。)另外，还能够为任何给定载波协议注册新的实际工厂114实现，以便说明工厂API 101e与分析器API 101d如何共用公共传输表示语法。
E2ENP UA 128与工厂114之间的通信可能是异步的，例如由主动请求接口和被动确认接口来实现。这个选项没有用于本发明的范围，因为性能及灵活性的一些增益与E2ENP的FSM 106的更为复杂的状态模型不相容。这个判定的一个结果是，E2ENP UA 128和工厂114(还有分析器112)同步进行通信，因而必须共用公共地址空间，它在大部分情况下是合理的假定。
这个判定的另一个结果是，工厂114(以及还有分析器112)必须设计为线程安全、可重入的库。
为了提供工厂114与E2ENP UA 128的松耦合，由工厂114产生并作为结果送回给调用E2ENP UA 128的传输表示通过使用java.io.Serializable类来抽象描述。同样，java.lang.Object类抽象地描述工厂114原语的输入。因此，实现在E2ENP UA 128中使用的给定传输表示和给定对象模型的工厂114的实际类必须通过配置来装配在一起。
实际分析器112和工厂114实现必须约定传输表示的公共格式。这些格式的定义是实现特定的，并对应于实际分析器112和工厂114组件，即使鼓励和设想现有标准的使用。因此，一种格式被提出，它与基线SDPng定义兼容。
FactoryFactory 120提供的注册功能性可用不同方式来处理。注册的某些选项包括但不限于：
◆注册可永久地存储，以便继续存在于多个应用寿命周期。
◆可使注册变为公共的，供其它应用130使用，这还意味着永久存储。
◆注册对于当前应用寿命周期只可按照短暂方式来存储。
应用130可检查它们是否已经通过调用这些示例的相应getType()方法并比较相等性的返回值，来例示分析器112和工厂114的匹配对。分析器112和工厂114的不匹配对被应用130使用可能导致不可预测的结果以及未定义、甚至是错误的行为。
下面简要总结相关性：
◆IF2对象模型：这只是隐含的相关性，即工厂114的实际实现必须履行。一般来说，这个相关性通过工厂114仅预期java.lang.Object示例作为输入数据的事实来消除。但是，在实际上要传递到创建过程的特别配置的***中，特定对象模型类的示例用于E2ENP UA 128中。
◆传输表示：与以上相关性相似，实际工厂114无疑需要它必须创建的明确定义的结构。因此，它取决于传输表示的相应定义。但一般来说，通过利用java.io.Serializable抽象地描述传输表示，这个相关性从设计中消除。
由工厂API 101e指定的原语可取自表9。另外，要为产生特定工厂114而实现的原语在表10中列出。
FactoryFactory API通过包org.mind.e2enp.content中的类E2ENPContentHandlerFactory来实现，又称作工厂-工厂实现。它设计为单态示例，使得它的所有客户机可使用先前进行的注册。目前，所创建的单态示例是缺省实现，但对于将来的版本，计划提供可配置的方式(例如根据特定***属性)来确定要用于单态示例的类。E2ENPContentHandlerFactory类所提供的方法可取自表11。
在以下小节，提供用于基于XML的传输表示的可能的工厂114实现。
与分析器112相似，工厂114实现采用如[Gam]中所述的“访问者设计模式”。该结构如图20所示。
同样，通用工厂114访问者类fVisitor 2002被定义，它访问ObjectGraphNode(对象图形节点)2004类的1至N个示例。对于ObjectGraphNode的每个具体子类，定义相应的具体访问者类。
在以下小节，将给出SIP用户代理通用API 101c(IF3)的简要概述。
由于SIP用户代理通用API 101c向E2ENP UA 128暴露通用SIPUA 110的功能性，因此这个API的主要目的是从E2ENP UA FSM 106屏蔽SIP UA 110的实际实现。SIP用户代理通用API 101c通过定义一组接口以及通过所述API交换的复杂数据类型，实现这种通用API的规范。特定SIP UA 110实现能够通过特定适配器来暴露其本土(最终为标准)API，它们将把SIP API本土接口映射到SPI UA通用API101c，或者反之。
SIP UA通用API 101c允许多个用户同时访问给定SIP UA 110实现(经由多媒体应用130或中间件130)，以便同时建立多个SIP会话。
SIP UA通用API 101c还通过这些实体所需的SIP信令支持SIP注册员实现。为此，应当注意，SIP UA通用API 101c没有设计成允许同时支持相同存储器地址空间中的用户应用130和SIP注册员。通过这种设计选择，SIP注册员实现因而被迫作为独立服务器端实体来运行，不同于纯应用130和中间件130实体(在此上下文中为E2ENPUA FSM 106)。应用130和/或中间件130(在此上下文中为E2ENP UAFSM 106)和SIP注册员实现是服务用户的实例。暴露SIP UA通用API101c的SIP UA 110实现表示服务提供商。
SIP UA通用API 101c最初设计为从特定开放源SIP UA 110实现、Mitre的JSIP v.0.8库(http://jsip.sourceforge.net/)暴露API，其中API支持相当差。SIP UA通用API 101c根据下列设计原则来设计：
1.标识各种SIP程序的一组原语的定义在较高层抽象，从而简化E2ENP UA FSM 106设计。当然，SIP UA通用API 101c的当前版本所暴露的程序的粒度在某种程度上反映JSIP实现的能力。其它SIPUA 110实现可能提供或多或少的能力，这会分别要求嵌入上述相应适配器的或多或少的逻辑。
2.SIP UA通用API 101c的当前版本仅把重点放在对E2ENP UA128进行原型设计和测试所需的最小特征集。因此，当前版本的SIPUA通用API 101c故意不是完整的SIP API规范，也不是要进行什么标准化。
3.根据ISO/OSI模型，原语被分类为请求(Req)、指示(Ind)、响应(Rsp)和确认(Cfm)原语。请求(Req)和响应(Rsp)原语由IF3 101c的客户机服务用户或者由SIP注册员实现来调用，以便分别发起或响应特定消息交换。(在一些情况下，由于给定SIP UA 110实现所提供的抽象，消息交换可调用在对等体之间交换的一组不同消息，而在另一些情况下，消息交换仅限于给定消息及其确认。)指示(Ind)和确认(Cfm)原语由服务提供商110调用到IF3 101c的服务用户的注册客户机端，以便分别指示特定消息的到达或者特定消息交换的发起或者确认给定消息交换的结束。IF3 101c的服务用户的客户机端必须实现这些原语。对于发起给定协议消息交换的对等体产生的请求(Req)原语，对应目标对等体上的指示(Ind)原语。对于响应给定协议消息交换的目标对等体产生的响应(Rsp)原语，对应发起对等体上的确认(Cfm)原语。
4.如[Gam]中所述的“观察者设计模式”的一种简化形式(以具有Java Beans事件模型的派生的Java来实现)提供允许服务用户(经由称作“绑定请求”的原语)为指示(Ind)和/或确认(Cfm)原语回调注册的机制。
5.为了允许支持在SIP上的E2ENP搭载，各原语允许传递净荷、例如SDP、SDPng或多用途因特网邮件扩充(MIME)内容。
6.为了允许没有实际SIP UA 110实现和SDP/SDPng分析器112和/或工厂114的支持的E2ENP信令逻辑的试运转测试，原语设计成作为可在利用远程过程调用(RPC)机制、例如与Java RMI结合的Java串行化或解串时被编组或解组的通用对象(取代表示ASCII字符串的普通对象)来处理净荷。
7.由于用于设计这个SIP UA通用API 101c的Mitre的JSIP版本0.8实现缺少SIP到期首标字段的适当支持，它通常由服务用户来操纵，这个SIP首标字段的抽象已经被创建，用于处理这个字段的任何类型的实现。这对于其它更好的SIP UA 110实现是不必要的，在其它更好的实现中，设计者可以选择相应地改变SIP UA通用API101c(因此改变E2ENP UA FSM 106实现)或者提供映射给定服务提供商的到期首标字段的适配器126c(没有改变E2ENP UA FSM 106实现)。
其它设计选择为：
●[ReqSpec]中所述的E2ENP协商模型是E2ENP的主要方面以及用于嵌入SDPng净荷并在对等体之间进行端对端交换的一段信息。为了快速对E2ENP UA 128进行原型设计，表示E2ENP协商模型信息的命名为SipNegotiationModel的帮助程序类2216暂时被包含在SIP UA通用API 101c中。
●不是通过利用字母数字SIP调用标识符首标字段在应用层唯一标识活动会话，SIP UA通用API 101c利用数字整数标识符、即connectionId(连接标识)。这个选择由以下原因来规定：
-服务用户可以更易于处理具有数字标识符而不是具有字母数字标识符的列表。
-如果E2ENP UA 128将来使用其它协议来代替SIP，则具有通用原语和通用会话标识符将有助于部分再用现有E2ENP UAFSM 106设计。
SIP UA 110把connectionId的未使用的值与入局“邀请”、“选项”、“消息”或“注册”方法的SIP调用标识符首标字段相关联。通过应用相同的设计原理，请求那些方法中任一个的传输的服务用户将获得服务提供商在与原始请求(Req)原语关联的确认(Cfm)原语中选取的connectionId值。
然而，这个解决方案受到两个问题的影响：
1.若还不了解与给定请求(Req)原语关联的connectionId值，服务用户无法把确认(Cfm)原语与其相应的请求(Req)原语相关。
2.在确认(Cfm)原语到达之前，中间消息(最终表明失败情况)可能产生附加原语(例如连接状态指示)，这将导致前一点中所述的同样的相关问题。
为了解决这些问题，服务用户必须负责选择未使用的connectionId值，并迫使SIP UA 110把这种值与适当的SIP调用标识符首标字段值关联。
由服务提供商在入局“邀请”、“选项”、“消息”或“注册”方法的情况下、以及由服务用户在出局“邀请”、“选项”、“消息”或“注册”方法的情况下分配的connectionId值的集合应当不同，使得入局和出局“邀请”、“选项”、“消息”或“注册”方法的处理可以没有干扰地同时进行。
但是，为了简洁起见，SIP UA通用API 101c已经采用嵌入服务提供商本身的connectionId值分配的集中管理来设计。服务用户仍然负责分配出局“邀请”、“选项”、“消息”或“注册”方法的connectionId值，但实际分配则通过调用服务提供商所暴露的getConnectionId()方法委托给服务提供商。这个方法绝不能看作是原语本身，因为它直接返回值(所选connectionId值)：例如，这将防止实现松耦合接口，其中原语经由基于(非RPC类)消息的协议在服务用户和服务提供商之间交换。在任何情况下，服务用户和服务提供商可在没有集中connectionId值分配管理的情况下来设计，并且仍然符合SIP UA通用API 101c，只是通过不使用相应地实现getConnectionId()方法。作为特例，connectionId可在SIP重新“邀请”的情况下再用：在这种情况下，表明这是否为重新“邀请”的适当布尔参数将被传递给connectionReq原语(参见下文)。
●SIP UA通用API 101c的一些原语是SIP特定的：
-provisionalAck(Req|Ind|Rsp|Cfm)，它用来实现PRACK方法，
-register(Req|Ind|Rsp|Cfm)，它用来实现“注册”方法，
-options(Req|Ind|Rsp|Cfm)，它用来实现“选项”方法，以及
-message(Req|Ind|Rsp|Cfm)，它用来实现“消息”方法。
这些原语在将来的E2ENP UA 128设计重审中最终将映射到更通用的原语，以便把SIP UA通用API 101c转换成E2ENP会话层协议API，它将完全与实际使用的会话层协议无关。
●SIP UA通用API 101c设计的当前版本只是部分符合[Ros1]中所述的SIP规范的最近工作(到编写本文时)版本。例如，“REFER(引用)”、“DO(执行)”、“NOTIFY(通知)”、“SUBSCRIBE(预订)”方法以及其它许多特征已经省略，因为它们对于测试E2ENP概念不是必要的。“BYE(再见)”和“CANCEL(取消)”方法由同一个断开原语来支持。
因此，所述E2ENP UA API 101b取决于应用的E2ENP UA FSM106，涉及指示(Ind)和确认(Cfm)原语以及用于配置、控制和重置基础SIP UA 110的管理组件102的实现。
SIP UA通用API 101c利用面向对象的范例来设计，因而利用统一建模语言(UML)在此进行描述。它由基本包、即如图21所示的所谓org∷mind∷sip∷sipApi组成。类SipEndUser(Sip终端用户)2214和SipExpiresHandling(Sip到期处理)2112属于这个基本包。SipEndUser类2214表示访问SIP UA通用API 101c所提供的SIP服务的用户。SipExpiresHandling类使操纵SIP到期首标字段的功能性一般化。SipListener(Sip收听器)2108使服务用户将实现的用于截收SIP UA110产生的指示(Ind)和/或确认(Cfm)原语的所有接口一般化。SipProvider(Sip提供商)2110使服务提供商将支持的、用于实现请求(Req)和响应(Rsp)原语的所有接口一般化。
四个子包完成SIP UA通用API 101c规范：一个是org∷mind∷sip∷sipApi∷time，处理SIP到期首标字段抽象；而其它三个表征服务用户的不同作用：
●org∷mind∷sip∷sipApi∷userAgent表示应用130/中间件130实现(在本上下文中为E2ENP UA FSM 106)；
●org∷mind∷sip∷sipApi∷management表示管理实体102；
●org∷mind∷sip∷sipApi∷registrar表示SIP注册员实现2306。
org∷mind∷sip∷sipApi∷userAgent子包(参见图22)包含指定IF3101c的服务用户(在本上下文中为E2ENP UA FSM 106)用于访问服务提供商的SIP UA通用API 101c的一部分的接口和类。它由三个主要部分构成：
1.IF3101c的服务用户将实现的、用于截收服务提供商110产生的指示(Ind)和确认(Cfm)原语的接口：
-SipUserAgentListener(Sip用户代理收听器)2202：客户机和服务器端共同的；org∷mind∷sip∷sipApi∷SipListener接口2108的专门化。
-SipUserAgentClientListener(Sip用户代理客户机收听器)2206：专用于客户机端；SipUserAgentListener接口2202的专门化。
-SipUserAgentServerListener(Sip用户代理服务器收听器)2204：专用于服务器端；SipUserAgentListener接口2202的专门化。
2.特定原语的类捆绑参数(当前只有连接请求(Req)原语的SipConnectionReq类2208、注册请求(Req)原语的SipRegistrationReq类2218以及注册确认(Cfm)原语的SipRegistrationCfm类2220)。这些类的示例作为给定原语的参数传递给实现原语的模块。这个解决方案允许扩展和/或改变AIP细节而没有破坏原语签名。
3.指定服务提供商为与SIP UA通用API 101c兼容而应支持的API的接口和类。SipUserAgentType(Sip用户代理类型)接口2210指定基础SIP UA 110实现为与SIP UA通用API 101c兼容而支持的请求(Req)和响应(Rsp)原语的集合。SipUserAgentType接口2210是
org∷mind∷sip∷sipApi∷SipProvider接口的专门化。SipUserAgent类2214通过运用如[Gam]中所述的“抽象工厂”和“单态”设计模式来包裹上述SipUserAgentType接口2210的任何给定实现。“抽象工厂”由SipUserAgentFactor(Sip用户代理工厂)接口2212来定义。SipUserAgent类2214设计成通过利用保持缺省实现的完全合格类名的defImpl类属性，来使用缺省实现。上述SipUserAgentType接口2210的定制实现可通过提供实现上述SipUserAgentFactory接口2212的特定工厂类来创建。SipUserAgent类2214提供称作setUserAgentFactory()的类方法，它存储给定定制工厂的单态示例。
最后，这个子包包含称作SipNegotiationModel的类2216，它表示E2ENP协商模型。
org∷mind∷sip∷sipApi∷registrar子包(参见图23)包含指定SIP注册员实现用来访问服务提供商的SIP UA通用API 101c的一部分的接口和类。它由三个主要部分构成：
1.IF3101c的服务用户将实现的、用于截收服务提供商产生的指示(Ind)和确认(Cfm)原语的接口：
SipRegistrarListener(Sip注册员收听器)2302：客户机和服务器端共同的；对
org∷mind∷sip∷sipApi∷SipListener接口2108的专门化。
2.特定原语的类捆绑参数(当前只有注册指示(Ind)原语的SipRegistrationInd类2308以及注册响应(Rsp)原语的SipRegistrationRsp类2310)。这些类的示例作为给定原语的参数传递给实现原语的模块。这个解决方案允许扩展和/或改变AIP细节而没有破坏原语签名。
3.指定服务提供商110为与SIP UA通用API 101c兼容而应支持的API的接口和类。SipRegistrarType(Sip注册员类型)接口2304指定基础SIP UA 110实现为与SIP UA通用API 101c兼容而应支持的请求(Req)和响应(Rsp)原语的集合。SipRegistrarType接口2304是
org∷mind∷sip∷sipApi∷SipProvider接口2110的专门化。SipRegistrar(Sip注册员)类2306通过运用如[Gam]中所述的“抽象工厂”和“单态”设计模式来包裹上述SipRegistrarType接口2304的任何给定实现。“抽象工厂”由SipRegistrarFactor(Sip注册员工厂)接口2312来定义。SipRegistrar类2306设计成通过利用保持缺省实现的完全合格类名的defImpl类属性，来使用缺省实现。上述SipRegistrarType接口2304的定制实现可通过提供实现上述SipRegistrarFactory接口2312的特定工厂类来创建。SipRegistrar类2306提供称作setRegistrarFactory()的类方法，它存储给定定制工厂的单态示例。
org∷mind∷sip∷sipApi∷management子包(参见图24)包含指定应用于用来配置和控制服务提供商的管理实体102的SIP UA通用API101c的一部分的接口和类。它由三个主要部分构成：
1.服务用户将实现的、用于截收服务提供商产生的指示(Ind)和确认(Cfm)原语的接口：
SipManagementListener(Sip管理收听器)。
2.特定原语的类捆绑参数(当前只有配置请求(Req)原语的SipConfigurationReq类2406)。这些类的示例作为给定原语的参数传递给实现原语的模块。这个解决方案允许扩展和/或改变AIP细节而没有破坏原语签名。
3.指定服务提供商为与SIP UA通用API 101c兼容而应支持的API的接口。SipManager(Sip管理器)接口2404指定基础SIP UA实现为与SIP UA通用API 101c兼容而应支持的请求(Req)和响应(Rsp)原语的集合。
org∷mind∷sip∷sipApi∷time子包(参见图25)包含指定允许服务用户操纵SIP到期首标字段的SIP UA通用API 101c的一部分的接口和类。它由两个主要部分构成：
1.指定服务提供商为与SIP UA通用API 101c兼容而应支持的API的接口和类。SipExpiresType(Sip到期类型)接口2502指定基础SIP UA 110实现为与SIP UA通用API 101c兼容而应支持的SIP到期首标字段操纵操作的集合。SipExpires(Sip到期)类2506通过运用如[Gam]中所述的“抽象工厂”和“单态”设计模式来包裹上述SipExpiresType接口2502的任何给定实现。“抽象工厂”由SipExpiresFactor(Sip到期工厂)接口2508来定义。SipExpires类2506设计成通过利用保持缺省实现的完全合格类名的defImpl类属性，来使用缺省实现。上述SipExpiresType接口2502的定制实现可通过提供实现上述SipExpiresFactory接口2508的特定工厂类来创建。SipExpires类2506提供称作setSipExpiresFactory()的类方法，它存储给定定制工厂的单态示例。
2.SipParseException(Sip分析异常)类2504表示每当SIP到期首标字段的分析因异常形成的语法而失败时由服务提供商发出的异常。
在以下小节中，SIP UA通用API 101c所启用的过程将采用一组UML消息序列图(MSC)来描述。
图26表示服务提供商110如何被配置，以及IF3 101c的服务用户如何创建、作为服务用户如何绑定其客户机和服务器子单元与服务提供商110。图27表示SIP会话如何可通过根据[Ros1]中所述的过程的SIP UA通用API 101c来建立。
这个过程以作为主叫方(或发起者)的对等体所调用的connectionReq原语开始，触发仅当作为被叫方(或应答者)的对等体在最初收到通知发起者的建立SIP会话的邀请的connectionInd原语之后最终接受这种邀请(在多个协商和信令步骤之后)时才终止的消息交换，以及采用connectionRsp原语进行应答。
应答者通过connectionStatusReq原语调用产生SIP临时响应，它在发起者端映射到connectionStatusInd原语调用。发起者通过分别利用在应答者端对应于ProvisionalAckInd/Rsp原语的ProvisionalAckReq/Cfm原语、采用PRACK方法确认临时响应。
这个过程以发起者接收connectionCfm原语以及应答者接收connectionStatusInd原语而结束。后者是因为[Ros1]中所述的SIP三向确认方案。
这个MSC中的两个过程被假定为由服务提供商自动执行：在应答者端“100尝试”临时响应的产生以及在发起者端的最终ACK信号的产生。但是，后者可由服务用户本身经由connectionStatusRsp原语来强制执行，但这意味着服务用户必须相应地被配置成不自动产生ACK信号。
表明除成功之外的其它原因的最终SIP响应或者由服务提供商自动产生，或者由应答者的服务用户经由connectionStatusReq原语显式产生。经由connectionStatusInd原语向发起者的服务用户通知这些SIP响应。
图28表示“选项”方法如何经由optionsReq|Ind|Rsp|Cfm原语来处理。图29表示SIP会话如何可经由disconnectionReq|Ind|Rsp|Cfm原语来释放。MSC表示“再见”的情况，但在连接建立期间调用的相同过程产生“取消”。
在以下小节，简要描述应用于E2ENP UA 128的有限状态机106(FSM)。
E2ENP UA 128的核心由有限状态机106(FSM)组成，它协调整体功能性以及实现上述接口的一部分。更明确地说，FSM 106实现IF3、IF4和IF5的服务用户部分以及IF1和IF2的服务提供商部分。此外，E2ENP UA FSM 106利用以上所述的高速缓存104。
FSM 106以分级结构设计为StateChart(状态图)。在根状态(参见图30)，FSM 106处理与本地或者远程用户的决定关联的会话终止事件。此外，根状态处理预协商、租赁更新、作为提议方/应答方的协商、重新协商以及会话释放过程。应当注意，术语“协商”过程用于表明如[ReqSpec]中所述的、与资源保留协调和QoS协商纠缠的多媒体会话建立。
提议方的作用由发起具有QoS协商和资源保留的会话建立的对等体来承担，但也可由决定发起重新协商的对等体来承担。应答方的作用始终由响应邀请以执行具有QoS协商和资源保留的会话建立过程的对等体来承担，但也可由决定响应邀请以执行重新协商的对等体来承担。这意味着，最初起到提议方作用的对等体稍后可在重新协商中承担提议方或应答方的作用。反之，最初起到应答方作用的对等体稍后可在重新协商中承担提议方或应答方的作用。
为了简洁起见，图30没有详细说明与IF1(管理API)关联的原语的处理；也没有考虑与FSM工厂106关联的内部接口以及高速缓存104。
以下小节提供对图30所示的互斥相关过程的详细描述。
作为提议方/应答方的协商过程的低层细节封装在嵌套FSM 106中，分别为NegOfferer子状态(参见图31)和NegAnswerer子状态(参见图32)。
NegOfferer子状态包含捕捉如从提议方角度看到的处理协商过程的逻辑的嵌套FSM 106。NegAnswerer子状态包含捕捉如从应答方角度看到的处理协商过程的逻辑的嵌套FSM 106。
为了保证一致性以及避免如[ReqSpec]中所述的本地、对等体和网络资源的组合保留过程中的死锁，嵌入NegOfferer子状态以及嵌入NegAnswerer子状态中的FSM 106采用***范围的“_ResvMtx”FSM106用于针对E2ENP UA FSM 106的其它示例以互斥方式访问保留阶段。“_ResvMtx”FSM 106经由原子本地方法调用(例如经由基础操作***提供的任何特定***调用)与E2ENP UA FSM 106的各种示例交互。
以下小节提供对图31所示的互斥相关过程的详细描述。
作为提议方/应答方的重新协商过程的低层细节封装在嵌套FSM106中，分别为ReNegOfferer子状态(参见图33)和ReNegAnswerer子状态(参见图34)。
-ReNegOfferer子状态包含捕捉如从提议方角度看到的处理重新协商过程的逻辑的嵌套FSM 106。
-ReNegAnswerer子状态包含捕捉如从应答方角度看到的处理重新协商过程的逻辑的嵌套FSM 106。
为了保证一致性以及避免如[ReqSpec]中所述的本地、对等体和网络资源的组合保留过程中的死锁，嵌入ReNegOfferer子状态以及嵌入ReNegAnswerer子状态中的FSM 106采用***范围的“_ResvMtx”FSM 106用于针对E2ENP UA FSM 106的其它示例以互斥方式访问保留阶段。“_ResvMtx”FSM 106经由原子本地方法调用(例如经由基础操作***提供的任何特定***调用)与E2ENP UAFSM 106的各种示例交互。
以下小节提供对图33所示的互斥相关过程的详细描述。
这种机制通过强迫E2ENP UA服务用户的各种并发示例互斥地访问这种阶段，如[ReqSpec]中所述，来执行资源保留阶段的事务类处理。换言之，资源保留互斥允许定义本地许可控制与作为关键部分的最终网络资源保留之间的阶段。与争用解决策略结合，这种机制还保证根本没有如[ReqSpec]中所述的死锁情况可能影响E2ENP。
并发E2ENP UA服务用户示例尝试经由未决定的方法调用来占用互斥。拥有互斥的服务用户示例经由信号呼叫事件将它释放。
“_ResvMtx”与优先级队列关联，以便允许多个请求根据其优先级、以协调方式占用互斥(参见图35)。
如果互斥被解锁，则立即对任何请求提供服务，否则，该请求排队等待。具有高优先级的请求排列在具有低优先级的请求之前。具有相同优先级的请求以“先进先出”(FIFO)顺序排队等待。
获取互斥的所有请求在时间方面有限制。在这种(可配置)时间到期时，对互斥未决的给定E2ENP UA服务用户示例被恢复，同时以返回值表明失败。
这个设计选择允许检测(从而防止)对互斥挂起的并发E2ENP UA服务用户示例的饿死，这种情况在拥有互斥的服务用户示例出故障(或可能阻塞)时发生。这是最重要的，尤其是在表现不良的服务用户示例对于最终由在“_ResvMtx”上排队的服务用户示例之一占用的某个其它专用互斥、信标或锁定被挂起的情况下：在这种不利情况下，实际上会不可避免地出现死锁。
当与各阻塞的请求关联的计时器到期时，那个请求的优先级(分别在bookNegotiationReq或bookRenegotiationReq原语的参数列表中指定，参见表1)应当高于互斥被允许的请求的优先级，互斥将向与拥有互斥的服务用户示例关联的FSM 106UA的示例发出信号事件congestionInd。这个事件由E2ENP UA FSM 106根状态捕捉，并映射到发送给拥有互斥的服务用户示例的failureInd原语。
根据专用策略，这种服务用户示例可能通过回退到其活动的当前状态并开始又将强迫互斥释放的释放操作，对这种事件作出反应，如图30所示。但是，如果这种服务用户示例以不同方式动作(根据专用策略或者因为被阻塞或出故障)，则由于表明失败情况的bookNegotiationCfm(或在重新协商情况下bookRenegotiationCfm)原语(分别参见图31和图33)，其它示例仍然能够检测对于获取互斥的长期延迟(在成功调用获取方法的失败尝试的配置次数之后)。在这些情况下，被通知的E2ENP UA服务用户示例可能调用专用仲裁单元的调解。为了管理所有这些异常情况/死锁，resetReq原语可在任何时间发出，以便取消当前给定会话并在必要时释放互斥。
在使用互斥实体时通常遇到的主要问题是所谓的优先级倒置问题，这每当拥有互斥的任务Tj具有比在互斥上阻塞的其它任务Tk更低的优先级时发生，更精确地说，是当Tj被具有高于Tj但低于Tk的优先级的任务T1先占时发生。
给定实行到E2ENP UA服务用户以及到SIP UA 110的松耦合接口的设计选择，包含“_ResvMtx”实现的E2ENP UA 128无法直接实行众所周知的协议、例如优先级继承协议或优先级最高限度协议。这归根结底是作为软件组件来设计E2ENP UA 128的结果。
但是，如果E2ENP UA FSM 106设计成处理用于同时处理FSM106的多个示例的线程池，则优先级倒置问题至少在此级可被解决。关于这一点，优先级继承协议的实行允许获得处理上述问题时的良好性能。为此，在各E2ENP UA服务用户示例发出的bookNegotiationReq原语(或者在重新协商情况下bookRenegotiationReq，参见表1)的参数列表中指定的优先级被分配为正服务于该FSM 106示例的线程的优先级。因此，“_ResvMtx”把与拥有互斥的FSM 106示例关联的线程的优先级暂时提高到任何被阻塞线程的优先级，如果后者的优先级高于前者之一。
这样，E2ENP UA 128提供用于解决死锁和优先级倒置问题的工具：但是，这归利用这些工具来保证那些问题绝不出现的应用130或QoS中介器130负责。
在以下小节，将描述资源保留协调过程。
NegAnswerer(参见图32)和ReNegAnswerer(参见图34)子状态各包含相同复合状态的一个示例，WaitForCoordDone子状态(参见图36)，其嵌套FSM 106捕捉处理在应答方实际被告警并相应地通知提议方之前所需的资源保留信令的协调的逻辑。
资源保留协调过程基于[Cam1]中所述的机制，但具有以下差别：
1.[Cam1]中所述的前提可映射到[ReqSpec]中所述的E2ENP“qosdef”部分及其相应的协商过程。
2.E2ENP规定对等体之间的保留过程的同步([Cam1]中的“确认”标签)因“经济原则”而始终是强制性的：这意味着“确认”标签(或任何等效物)的端对端信令是不必要的，因而没有被任何E2ENP实现所支持。
3.在提议方没有执行网络资源保留的情况下，应答方将通过检查提议方发送的前提来确定这种情况，并在图36中相应地把状态RemoteTokenAchieved(远程令牌已获得)标记为活动的，使得应答方能够透明地处理资源保留协调。
对SIP实现的影响(例如状态响应以及“选项”方法的“被支持”首标字段的新值“前提”的引入)留待进一步研究。
一个重要方面在于，[ReqSpec]中所述的E2ENP明确要求始终需要经济原则，其中包括[Cam1]中所述的允许端对端和分段保留的概念。在后一种情况下，实行经济原则可能并非始终符合需要。实际上可能存在其中保留可预先在本地顺利进行而没有费用和/或对会话建立的重大影响的情况。例如，一些用户可能连接到内联网或无线LAN，其中的网络资源保留可能是自由的，并且其它用户的资源不足可灵活处理。因此，原始E2ENP将适应这种情况，并且依靠经济原则的适用性来允许上述情况。
应当注意，E2ENP不是意味着到保留实体的直接接口是可用的：由应用130或QoS中介器130负责访问那些实体。如果后者希望执行网络资源的“预先保留”，它可能那样做，但E2ENP信令仍然向应用130或QoS中介器130提供正确的定时，从而通知它何时所有端的保留已经根据经济原则完成，例如，哪个信号已经达到预期QoS的等级(即使在应用130或QoS中介器130分别指定时尽量发送通信可能已经预先顺利开始)。
为了简洁起见，图30至36所示的模型只是部分详细说明意外事件和错误情况的处理。表18通过指明在这类事件或错误中任一个出现的情况下预期的行为，完成对所述模型的描述。
定义一组计时器以避免E2ENP UA FSM 106陷入等待来自服务用户和/或SIP UA 110的事件的状态。用于处理通过E2ENP UA API101b的原语的计时器(T1-T22)的处理方式没有规定E2ENP UA FSM106自发采取校正动作，除少数情况(在Root.NegOfferer.WaitNegReq中丢失negotiationReq以及在Root.ReNegOfferer.WaitReNegReq中丢失renegotiationReq)之外。E2ENP UA FSM 106只经由failureInd原语通知出故障的服务用户关于所检测的问题，根据这个通知，服务用户应当整理并向E2ENP UA FSM 106发送releaseReq原语。但是，如果这种反作用例如因服务用户端的大量问题而没有成功，则E2ENP UAFSM 106将在又一个计时器到期时检测这种情况：在这种情况下，E2ENP UA FSM 106最终决定释放SIP连接和整个E2ENP会话。为了管理所有这些异常情况/死锁，resetReq原语可在任何时间发出，以取消当前给定会话并在必要时释放互斥。
但是，复合状态Root.ReNegOfferer、Root.NegAnswerer、Root.RenegOfferer、Root.ReNegAnswerer可通过各利用历史状态来检测丢失原语的稍后到达(最终通过failureInd原语的调用来触发)(参见图31、32、33和34)。通过这种解决方案，较迟的原语到达将以正确的原始状态被捕捉并被正确处理。这意味着，每当上述计时器到期时，上述复合状态将各自负责更新历史记录，以便指向计时器到期的状态。
如果SIP原语失败，则特定计时器(T101-T106)将检测在Root.ReNegOfferer、Root.NegAnswerer、Root.ReNegOfferer、Root.ReNegAnswerer复合状态的故障：在这些情况下，将实行如上所述的相同过程(根据failureInd原语)。
对于该接口，对于原语失败的可能问题的相似方法必须通过管理实体102来完成，但在此部分没有详细说明。
为了正确地实现E2ENP概念，双占用事件(对等体同时发起彼此间的协商会话)将被正确地检测和处理，以便允许保证一致性以及实行出局与入局邀请之间的任何相关。
前一个问题可通过把互斥用于基于***范围地调节对经济原则阶段的访问(以上部分所述的“_ResvMtx”)来解决。
为了实行任何相关，而要求某种附加支持。设想两种可能的方法：
a.使用推-拉模型，以便允许提议方和应答方有机会向对等体发送提议，从而避免在同一会话的两个方向同时产生两个协商的可能性；
b.把两个方向上同时处理协商的尝试作为双重占用来处理，这要求实行争用解决策略(例如在两端等待随机计时器，然后重试)。但是，这通常意味着，两个对等体应当使用会话ID的相同外部表示，以便能够检测双重占用。否则，两个UA中每一个将把出局和入局协商看作独立的会话。这与以下情况相似：对等体A邀请对等体B例如参加电视会议，同时对等体B邀请对等体A参加另一个电视会议，而电视会议实际上可能是同一个。E2ENP定义[ReqSpec]中所述的会话ID的外部表示的方式允许两个对等体仅创建不同的ID。因此，E2ENP规范本身根本不允许检测双重占用。
对这个问题的一个适当解决方案是尽量实行推-拉模型(第一方法)，以及在重新协商阶段包含允许应答方在稍后时间(即在第一协商已经完全完成之后)向提议方发送提议的可能性。
这意味着E2ENP将允许提议方和/或任何应答方与其它应答方和/或提议方协商升级或新的信息，用于建立QoS感知多媒体会话。这意味着，重新协商可细分为两类：
·如[ReqSpec]中原始描述的所计划的重新协商，
·未计划的重新协商，它们用于在会话的使用期中协商升级或新的信息。
预协商原语中的明确布尔参数表明给定原语应当用于两个类中的哪一个。当然，语义可从所传递的信息中推断，它在两种情况中是不同的，但布尔参数是在具有为提高性能已明确作出的这种区分与通过避免附加原语来保持E2ENP UA API 101b和FSM 106简单的需要之间的良好折衷。
但是，应用上述解决方案可能在一般情况下不充分，因为符合非E2ENP的SIP UA 110可能与符合E2ENP的对等体相互干扰，或者参与方之一可能尝试邀请一些其它参考方加入并行多媒体会话并使用E2ENP来完成。
通过建议争用解决策略(在[Ros1]中表示为“MAY”要求)，SIP宽松地解决双重占用问题，从而，对等体通过采用内部服务器错误响应来应答，传送设置为某个时间(在该时间之后远程对等体应当重试)的RetryAfter SIP首标字段，来中止邀请。
双重占用检测通过匹配给定的每对用户之间的所有消息、经由To-和From-SIP首标字段来完成。这意味着，如果第一用户正使用UA A并向UA B上的第二用户发送“邀请”，或者反之，则两个用户可通过利用该对(To，From)作为把两个“邀请”相关的唯一标识符来检测双重占用。
但是，这不完全是E2ENP标识会话的方式。如果用户参加两个独立的电视会议，则E2ENP实际上可通过利用[ReqSpec]中所述的会话ID来区分这类情况。在任何情况下，最大的问题是，SIP UA 110在这种情况下将怎样做，假定上述SIP要求为MAY要求，从而不一定被所有SIP实现支持。
必须假定可以实现上述策略：因而，E2ENP UA 128将不通知双重占用，除了不成功协商或重新协商阶段的指示之外。但是，如果争用解决策略没有受到基础SIP UA 110实现的支持，也可能陷入双重占用问题中。
为了解决后一种情况，高速缓存104还应当对其条目的每个存储与出局“邀请”关联的(E2ENPFromAddress，E2ENPToAddress)对，并使用这个信息把入局“邀请”与寄存在高速缓存104中的未决出局“邀请”相关，从而检测双重占用情况：这将触发争用解决策略。这意味着，在发送“邀请”之后所接收的每个入局“邀请”应当通过借助于次关键字、利用(From，To)对搜索高速缓存104来检查。虽然这是额外工作，但它只限于在已经发送“邀请”之后接收“邀请”的特定情况。
作为[Ros1]所建议的、最终由基础SIP UA 110实现的争用解决策略的备选方案，E2ENP UA 128将支持更一般的策略，它还适用于例如[ReqSpec]中所述的一对多或者多对多的复杂情况。
每当发起协商或预协商阶段时，E2ENP UA 128应当不仅包含在“邀请”内发送的提议中的[ReqSpec]中所述的会话ID，而且还包含其散列以及时标，散列考虑了E2ENP UA 128在其中为活动的计算单元的IP地址。这个散列还可被数字签名，以便改进安全性方面[ReqSpec]。散列将用作任何后续SIP消息中的会话ID的替代物。如果出现双重占用，则E2ENP将通过采用上述(From，To)对来检测它。因此，所述争用解决策略将按照如下所述来应用：
◆如果两个对等体还没有涉及多媒体会话(这意味着在高速缓存104中没有用于给定本地对等体的条目)，则每个对等体将把它所产生的散列与从对等体接收的散列进行比较。具有最大值的对等体被自动选作提议方，从而以同样方式继续进行预协商或协商阶段，而另一个对等体、即“败方”则根据以下MSC自动转到应答方模式：
  应用(130)E2ENP UA(128)negotiationReq---＞＜---------abortInd＜---negotiationIndnegotiationRsp---＞…
◆如果两个对等体已经涉及到多媒体会话(这意味着在高速缓存104中有用于给定(From，To)对的条目)，则也可应用在前一点中所述的“选优”过程。其请求被拒绝的对等体可在“选优”过程的胜方已经完成其协商之后应用未计划的重新协商。这种情况的一个实例是所涉及的对等体对QoS违反的同时检测和重新协商反应。
◆由于所产生的会话ID还包含用于标识的随机产生数(与IP、端口等信息一起)，不会预期一部分对等体将始终为“胜方”以及一部分始终为“败方”。
最后，上述争用解决过程还适用于与预协商过程或甚至租赁-更新过程冲突的协商过程以及预协商过程与租赁-更新过程的冲突的情况。
前面小节中所述的模型表示E2ENP UA FSM 106的静态定义。在运行时，E2ENP UA 128将把特定E2ENP会话与表示它的对象关联。这个对象-会话-将包含与给定E2ENP示例相关的任何信息：最值得注意的是，指向当前状态的指针以及在以上模型中定义的所有条件变量的示例。
执行的线程将动态地与这些会话对象中每一个关联：或者应请求来创建，或者-最好-从线程池中挑选(可能具有慢吞吞的初始化)。
◆E2ENP的这个版本基于[Ros1]中所述的SIP协议规范。如果在稍后时间选取另一个会话层协议或更普通的方法，则由于E2ENP UAAPI 101b抽象，FSM 106应当被修改，以便从应用130或QoS中介器130屏蔽相应的变化。这意味着，FSM 106与E2ENP UA API 101b服务用户的交互是设计不变的。
◆SIP“消息”方法的使用在图30中试验性地表示。或者，可使用SIP“选项”方法。在本发明的范围中，仅有后者被SIP UA通用API 101c暴露，因为前者用于实现以下所述的FSM 106模型的用法仍然在研究。
◆为了避免与E2ENP UA 128接口的实体(例如E2ENP UA 128服务用户、SIP UA 110和E2ENP管理实体102)在E2ENP UA 128有机会达到稳态配置之前响应E2ENP UA 128出局原语而直接调用E2ENP UA 128入局原语，设计把E2ENP UA 128始终与上述外部实体松耦合。这种设计选择的另一个原因是以下可能性：否则将存在与E2ENP UA 128接口的实体可能无限地阻塞E2ENP UA线程的非零概率。
◆这意味着，E2ENP UA 128将对于整个E2ENP UA FSM 106实行一个入局消息队列以及对于接口IF1、IF2和IF3中每个实行一个出局消息队列。后一个队列的原因是由于以下事实：作为软件组件的E2ENP UA 128无法对应用130处理UA发出的原语的方式进行任何假定。
◆这种方法对于IF4和IF5是不需要的，因为分析器112和工厂114是作为由E2ENP UA FSM 106经由同步接口访问的线程安全、可重入库来设计的。
◆E2ENP UA FSM 106的并发示例借助于线程池来处理。
E2ENP UA FSM 106依靠以下组件：
◆E2ENP UA API 101b，暴露FSM 106所实现的E2ENP功能性，
◆分析器API 101d，用于访问处理所接收SIP消息中包含的会话描述的分析的服务，
◆工厂API 101e，用于访问处理要***出局SIP消息的会话描述的创建的服务，
◆SIP UA通用API 101c，用于访问SIP服务，
◆E2ENP管理API 101a，用于访问处理整个E2ENP UA 128管理功能性的服务，以及
◆高速缓存104，用于存储和相关给定会话的标识符。
E2ENP UA FSM模型根据UML状态图在图30、31、32、34和36中描述，并且可通过采用各种众所周知的设计模式来实现。在任一种情况下，如图1所示，FSM 106在运行时与所应用的框架或设计模式的示例关联，以便实现该模型。每个示例与特定SIP阶段[ReqSpec]、即预协商、租赁更新或协商相关联。重新协商在与采用相应协商所建立的基础会话相同的示例上运行。
为了处理FSM 106示例(创建、激活、去活和消除)的寿命周期，设想FSM示例工厂106(参见图1)。这应当是在调用特定E2ENP UAAPI 101b原语(negotiationReq、prenegotiationReq、renewLeaseReq)时或者在调用特定SIP UA通用API 101c原语(connectionInd、optionsInd、messageInd)时创建FSM 106的示例的单态对象。
图37描绘简单预协商情况的MSC，其中，突出显示经由E2ENPUA FSM 106的E2ENP UA API 101b与SIP UA通用API 101c之间的相关。
图38描绘简单会话建立情况的MSC，其中，突出显示经由E2ENPUA FSM 106的E2ENP UA API 101b与SIP UA通用API 101c之间的相关。在所提供的情况中，来自提议方侧的资源保留完成的确认在应答方侧发生同样情况之前到达。同样，假定资源保留过程成功地保留了正好原始请求资源的量。
在以下小节，将简要描述E2ENP UA工厂108。
E2ENP UA工厂108是根据[Gam]中所述的“抽象工厂”设计模式建模的管理功能性，用于采用实现无关的接口来例示特定E2ENPUA 128实现。
这个实体处理前面部分中所述的、创建E2ENP UA 128的示例所需的所有类的例示。更明确地说，E2ENP UA工厂108创建以下实体：
◆E2ENP UA FSM工厂，它又创建E2ENP UA FSM静态结构，
◆FactoryFactory 120，它又创建E2ENP工厂114，
◆ParserFactory 118，它又创建E2ENP分析器112，以及
◆高速缓存104。
因此，所述E2ENP UA工厂108依靠以下组件：
◆应用130和/或中间件130，它可直接调用E2ENP UA工厂108，或者管理实体102。
◆E2ENP UA FSM 106，其工厂由给定的具体E2ENP UA工厂实现来创建。
◆工厂114和分析器112，其工厂由给定的具体E2ENP UA工厂实现来创建。
◆高速缓存104，它由给定的具体E2ENP UA工厂实现来创建。
E2ENP UA工厂108通过采用面向对象的范例来设计。因此，在此通过采用统一建模语言(UML)来描述。
下面简要总结E2ENP对象配置参数。
E2ENP UA 128及其子组件(FSM 106、分析器112、工厂114、高速缓存104)是可配置元素。初始配置应当考虑使用E2ENP UA 128的对等体的特定特征。
E2ENP UA 128应当采用以下参数来初始化：
◆E2ENP UA FSM 106以关键状态的特定超时来发起，其中应当采取关于性能的迅速判定。超时的长度取决于E2ENP UA 128的特定基础协议以及取决于相应对等体的性能特征。不同装置和网络的超时可具有某种程度的不同。实施者应当通过定义超时来考虑这些变化。
◆高速缓存104不需要任何配置参数，并且由E2ENP UA 128发起。
◆分析器112和工厂114分别采用所使用的基础协议类型及其相应的类名称来配置。它们通过E2ENP UA 128来发起。
E2ENP UA 128及其相应组件的配置或者可借助于图形用户界面(GUI)来手动执行，或者可采用从配置文件中读取的配置参数来预置。
涉及E2ENP UA FSM 106，以下参数是可配置的：
◆线程池配置参数：
*E2ENP线程池中的线程的最大数量。
*表明该池是否应当具有缓慢初始化(即线程只在需要时才被创建)的选择器。
●表明是否要求线程池优化(仅当实行缓慢初始化时)的选择器。为了优化的原因，池可能在运行时根据实际池使用率重新配置。
＝＞线程池优化计时器：在这种计时器到期时，应当应用优化过程(即未使用的线程被释放)。
◆计时器(参见表19)。
◆互斥：
*用于检测互斥的可能无限锁定的计时器，最终借助于FSM106的低优先级示例(参见表19中的TM)。
*获取所述互斥的尝试次数由最大数量(Max-Attempts)来限制。
SIP UA实现110将允许至少配置以下参数：
◆基础会话协议：这是E2ENP用于传送其元消息(SIP、RMI、套接字)的协议。在E2ENP将来的规范中，可能使用其它会话层协议(例如H323)。
◆基础传输协议：要由SIP使用的传输协议的类型。在将来的规范中，这个参数可能变成SIP UA 110本身的配置参数。
以下小节提供与分别使E2ENP UA 128和分析器112、工厂114之间的通信同步的判定有关的信息。关于这一点，E2ENP UA 128将支持E2ENP UA FSM 106的多个并发示例。为了避免OS资源的无约束使用，E2ENP UA 128将实行线程池。
E2ENP UA 128分别与分析器112、工厂114之间的通信可能也是异步的，例如由主动请求接口和被动确认接口来实现。这个选项没有用于本发明的范围，因为性能及灵活性的某些增益与E2ENP UA128的FSM 106的更为复杂的状态模型不相容。
这个判定的一个结果是，E2ENP UA 128和分析器112(以及还有工厂114)同步进行通信，因而必须共用公共地址空间，它在大部分情况下是合理的假定。这个判定的另一个结果是，ParserFactory和FactoryFactory都必须设计为线程安全、可重入的库。
由于以上论述，因此判定E2ENP UA 128与分析器112以及工厂114之间的通信是同步的。
最后，将强调本发明与现有技术水平的主要的有利差别。简言之，所提出的方法的主要好处在于
-QoS预协商与预协商信息、QoS协商和QoS重新协商的基于租赁的管理，以及
-由E2ENP UA 128提供的资源保留和/或释放协调。
此外，要协商的信息(能力、应用层QoS合同、网络层QoS合同、流层自适应路径以及流-组层自适应路径)可通过可交换格式来表达，其方式是：异构应用130和/或中间件130可易于约定参考模型，所述应用130和/或所述中间件130则可用于动态配置有限状态机106(FSM)，以便根据相应用户的偏好和简档、相应***和网络提供商的策略，在各种对等体使用的多个异构应用130和中间件130中以协调方式结合本地、对等体和网络资源。
最后，所述E2ENP UA 128可用于任何会话层协议和会话描述语言、多个应用130和不同类型的中间件130。
表A：所使用的缩写词
  缩写词   简要说明
  ABNF   扩充巴克斯-诺尔范式
  API   应用编程接口
  ASCII   美国信息交换标准码
  E2ENP   端对端协商协议
  FSM   有限状态机
  IF<X>   接口<X>
  IP   因特网协议
  IPv6   IP版本6
  LAN   局域网
  MIME   多用途因特网邮件扩充
  MSC   消息序列图(UML)
  OSI   开放式***互连
  QoS   服务质量
  RMI   远程方法调用
  RPC   远程过程调用
  SAP   服务接入点
  SDP   会话描述协议
  SDPng   会话描述协议(下一代)
  SIP   会话发起协议
  UML   统一建模语言
  XML   可扩展标记语言
表B：所描绘的特征及其相应的参考符号
  标号  技术特征
  100  框图，表示根据本发明的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构
  101a  E2ENP UA工厂108与管理实体102之间的E2ENP管理API(＝接口IF1)
  101b  E2ENP UA 128与利用所述E2ENP UA 128提供的服务的任何应用130或中间件130之间的E2ENP UA API(＝接口IF2)
  101c  E2ENP UA FSM 106与载波协议UA 110(SIP、RMI等)之间的SIP UA通用API(＝接口IF3)
  101d  E2ENP UA FSM 106与所实现的分析器112之间的分析器API(＝接口IF4)
  101e  E2ENP UA FSM 106与所实现的工厂114之间的工厂API(＝接口IF5)
  102  E2ENP体系结构100的E2ENP管理实体
  103  高速缓存104与E2ENP UA FSM 106之间的高速缓存API
  104  E2ENP体系结构100的两级高速缓存，连接到E2ENP用户代理(UA)128的有限状态机(FSM)106
  106  应用于E2ENP体系结构100的E2ENP用户代理(UA)128的有限状态机(FSM)
  108  E2ENP体系结构100的E2ENP UA生成工厂
  108a  E2ENP体系结构100的基于SIP的E2ENP UA生成工厂
  110  占位符，用于实现载波协议(SIP、RMI等)用户代理(UA)、又称作服务提供商
  110a  SIP用户代理(UA)，根据第一实现实例200，用于所应用的E2ENP体系结构100内的载波协议的UA实现110
  110b  基于Java远程方法调用(RMI)的用户代理(UA)，根据第二实现
  标号  技术特征
 实例300，用于所应用的E2ENP体系结构100内的载波协议的UA实现110
  110c  基于套接字的用户代理(UA)，根据第三实现实例400，用于所应用的E2ENP体系结构100内的载波协议的UA实现110
  112  占位符，用于应用分析器的实现
  112a  SDPng分析器，根据第一实现实例200，用于所应用的E2ENP体系结构100的分析器实现112
  112b  伪分析器，根据第二实现实例300，用于所应用的E2ENP体系结构100的分析器实现112。伪分析器与基于Java RMI的UA 110b共同使用。
  112c  伪分析器，根据第三实现实例400，用于所应用的E2ENP体系结构100的分析器实现112。伪分析器与基于套接字的UA110c共同使用。
  114  占位符，用于应用工厂的实现
  114a  SDPng工厂，根据第一实现实例200，用于所应用的E2ENP体系结构100的工厂实现114
  114b  伪工厂，根据第二实现实例300，用于所应用的E2ENP体系结构100的工厂实现114。伪工厂与基于Java RMI的UA 110b共同使用。
  114c  伪工厂，根据第三实现实例400，用于所应用的E2ENP体系结构100的工厂实现114。伪工厂与基于套接字的UA 110c共同使用。
  116  载波协议用户代理(UA)实现的生成工厂
  116a  基于Java的SIP代理110a生成工厂，根据第一实现实例200，用于SIP的载波协议用户代理110
  116b  RMI代理110b生成工厂，根据第二实现实例300，用于Java
  标号  技术特征
 RMI的载波协议用户代理110
  116c  基于套接字的代理110c生成工厂，根据第三实现实例400，用于基于套接字的连接的载波协议用户代理110
  118  应用分析器实现112的生成工厂
  118a  根据第一实现实例200的应用分析器112的SDPng分析器112a生成工厂(ParserFactory)
  118b  根据第二实现实例300的应用分析器112的伪分析器112b生成工厂(ParserFactory)
  118c  根据第三实现实例400的应用分析器112的伪分析器112c生成工厂(ParserFactory)
  120  应用工厂实现114的生成工厂
  120a  根据第一实现实例200的应用工厂114的SDPng工厂114a生成工厂(FactoryFactory)
  120b  根据第二实现实例300的应用工厂114的伪工厂114b生成工厂(FactoryFactory)
  120c  根据第三实现实例400的应用工厂114的伪工厂114c生成工厂(FactoryFactory)
  122  作为所述SIP用户代理(UA)110a的组件应用的基于Java的SIP栈(JSIP)
  124a  根据第二实现实例300的基于Java RMI的用户代理(UA)110b的远程方法调用(RMI)骨架
  124b  根据第二实现实例300的基于Java RMI的用户代理(UA)110b的远程方法调用(RMI)桩模块
  126a  根据第三实现实例400的基于套接字的用户代理(UA)110c的TX套接字，用于发送字符串或对象
  126b  根据第三实现实例400的基于套接字的用户代理(UA)110c的
  标号   技术特征
  RX套接字，用于接收字符串或对象
  126c   根据第三实现实例400的基于套接字的用户代理(UA)110c的适配器，用于利用所述套接字126a+b接收和/或发送字符串或对象
  128   组合单元，包括所述高速缓存104、所述E2ENP UA FSM 106和所述E2ENP UA工厂108，以下称作基于E2ENP的用户代理(E2ENP UA)
  130   利用E2ENP UA API 101b与E2ENP UA 128连接的多会话多媒体应用或QoS中介器(中间件)
  200   根据本发明的一个实施例、采用基于Java的SIP栈(JSIP)、SDPng分析器和工厂的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第一实现实例
  300   根据本发明的一个实施例、采用Sun的Java远程方法调用(RMI)的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第二实现实例
  400   根据本发明的一个实施例、采用基于套接字的用户数据报协议(UDP)或传输控制协议(TCP)的端对端协商协议(E2ENP)的用户代理(UA)的应用体系结构的第三实现实例
  500   UML类图，表示org∷mind∷e2enp包
  502   org∷mind∷e2enp包内的E2ENPUSerAgentListener接口
  504   org∷mind∷e2enp包中的提供商接口
  506   OffererListener接口，一般化为org∷mind∷e2enp包内的所述接口收听器502
  508   AnswererListener接口，一般化为org∷mind∷e2enp包内的所述接口收听器502
  510   ManagerProvider接口
  标号 技术特征
  512 ManagerListener接口
  514 类ConfigurationRequest
  516 类ParserFactoryConfiguration
  600 作为统一资源标识符(URI)的E2ENP地址的扩充巴克斯-诺尔范式(ABNF)
  700 第一消息序列图(MSC)，表示由端对端协商协议(E2ENP)的用户代理(UA)128启用的预协商过程
  702 类OffererServiceUser，从类E2ENPUserAgentListener中导出，实现收听器接口502
  704 类OffererServiceProvider，从类Provider中导出，它实现提供商接口504
  706 类AnswererServiceProvider，从类Provider中导出，它实现提供商接口504
  708 类AnswererServiceUser，从类E2ENPUserAgentListener中导出，实现收听器接口502
  800 第二消息序列图(MSC)，表示采用由端对端协商协议(E2ENP)的用户代理(UA)启用的QoS协商和资源保留协调的会话建立
  900 UML类图，表示org∷mind∷e2enp∷Cache子包
  902 类LevelOneCache，表示两级高速缓存104的第一级(L1)
  904 类LevelTwoCache，表示两级高速缓存104的第二级(L2)
  906 类LevelOneEntry，包含用于存储和加载至/自所述两级高速缓存104的第一级(L1)的信息的方法
  908 类LevelTwoEntry，包含用于存储和加载至/自所述两级高速缓存104的第二级(L2)的信息的方法
  1000 示意图，表示用于端对端协商协议(E2ENP)的可扩展标记语言(XML)描述的顶层视图
  标号   技术特征
  1001   SDPng desc元素的复型定义descType。说明还结合了重新定义机制进行的E2ENP特定改变。
  1002   “desc”元素的“e2enp:purpose”子元素。
  1003   “desc”元素的“sdpng:def”子元素。
  1004   “desc”元素的“sdpng:cfg”子元素。
  1005   “desc”元素的“sdpng:constraints”子元素。
  1006   “desc”元素的“sdpng:conf”子元素。
  1100   示意图，表示用于端对端协商协议(E2ENP)的XML替换组
  1101   SDPng desc元素的复型定义descType。说明还结合了重新定义机制进行的E2ENP特定改变。
  1102   “desc”元素的“e2enp:purpose”子元素。
  1103   “desc”元素的“sdpng:def”子元素。
  1104   “desc”元素的“sdpng:cfg”子元素。
  1105   “desc”元素的“sdpng:constraints”子元素。
  1106   “desc”元素的“sdpng:conf”子元素。
  1107   “sdpng:d”元素，定义“sdpng:def”部分的有效子元素的替换组的头。
  1108   “audio:codec”元素，“sdpng:d”替换组的成员。
  1109   “e2enp:qosdef”元素，“sdpng:d”替换组的成员。
  1110   “rtp:pt”元素，“sdpng:d”替换组的成员。
  1111   “rtp:transport”元素，“sdpng:d”替换组的成员。这个元素又是“rtp:transport”替换组的头。
  1112   “rtp:udp”元素，“rtp:transport”替换组的成员。
  1113   “video:codec”元素，“sdpng:d”替换组的成员。
  1200   示意图，表示用于端对端协商协议(E2ENP)的XML目的元素
  1201   “目的”元素。可用来传送与协议数据单元(PDU)之后的描述
  标号   技术特征
  有关的附加信息。
  1202   “e2enp:use”元素。“目的”部分的子，可用来表明引用会话。
  1203   “描述”元素。可用来表明描述PDU。
  1204   “调解”元素。可用来表明调解PDU。
  1205   “e2enp:session”元素
  1206   “到期”元素
  1300   示意图，表示用于端对端协商协议(E2ENP)的XML qosdef元素
  1300′   XML qosdef元素
  1301   “audio:codec”元素。描述***的音频能力。
  1302   “video:codec”元素。描述***的视频能力。
  1303   “rtp:pt”元素。可用来指定给定能力的预期净荷格式。
  1304   “e2enp:policy”元素。可用来指定要实行的资源管理策略。
  1305   “e2enp:audio”元素。可用来描述音频流的QoS合同。
  1306   “e2enp:video”元素。可用来描述视频流的QoS合同。
  1307   “e2enp:control”元素。可用来描述控制流的QoS合同。
  1308   “e2enp:data”元素。可用来描述数据流的QoS合同。
  1309   “rtp:map”元素。可用来定义应用层QoS合同与特定RTP净荷格式之间的映射。
  1310   “e2enp:contract”元素
  1311   “谓词”元素
  1312   “标准”元素
  1400′   XML qoscfg元素
  1400   示意图，表示用于端对端协商协议(E2ENP)的XML qoscfg元素
  标号   技术特征
  1401   “e2enp:context”元素。可用来定义数据流之间的关联，从而表达时间同步和/或QoS相关。简言之，这个元素定义高层QoS合同。
  1402   “e2enp:adapath”元素
  1403   “缺省”元素
  1404   “alt”元素
  1405   “事件”元素
  1406   “路径”元素
  1407   “comp”元素
  1408   “约束”元素
  1409   “par”元素
  1500   UML消息序列图(MSC)，表示根据本发明的E2ENP用户代理(UA)128与应用分析器112和高速缓存104之间的交互
  1700   UML类图，表示文档对象模型(DOM)树的一般结构
  1702   类DocumentTree，它对所述DOM树的一般结构建模，因而可解释为文档根元素
  1704   类DocumentNode聚集到所述类DocumentTree 1702，它又在0与n子之间聚集，从而递归地描述树结构
  1800   UML类图，表示利用“访问者设计模式”来遍历DOMTree 1804并产生XML对象1802的分析器实现112的结构概述
  1802   类XML对象，用于分析器实现112中
  1804   类DOMTree，它对所述DOM树的一般结构建模，因而可解释为文档根元素
  1806   类DOMNode，聚集到所述类DOMTree 1804
  1808   通用分析器访问者类pVisitor，它在1与N个DOMNode之间进行访问
  标号  技术特征
  1810a  所述类DOMNode 1806的第一专门化DOMNode
  1810n  所述类DOMNode 1806的第N个专门化DOMNode
  1812a  第一专用分析器访问者类pVisitor 1，它用于处理第一导出DOMNode
  1812n  第N专用分析器访问者类pVisitor N，它用于处理第N导出DOMNode
  1900  UML消息序列图(MSC)，表示根据本发明的E2ENP用户代理(UA)128与应用工厂114和高速缓存104之间的交互
  2000  UML类图，表示工厂实现114的结构概述
  2002  通用工厂访问者类fVisitor，它在ObjectGraphNode类的1与N个示例之间进行访问
  2004  类ObjectGraphNode，用于工厂实现114中
  2006a  第一专用工厂访问者类fVisitor 1，它用于处理类ObjectGraphNode 2004的第一导出节点2008a
  2006n  第N专用工厂访问者类fVisitor N，它用于处理类ObjectGraphNode 2004的第N导出节点2008n
  2008a  类ObjectGraphNode 2004的第一专用节点(子类)
  2008n  类ObjectGraphNode 2004的第N专用节点(子类)
  2100  UML类图，表示org∷mind∷sip∷sipApi包
  2102  org∷mind∷sip∷sipApi包的类管理
  2104  org∷mind∷sip∷sipApi包的类userAgent
  2106  org∷mind∷sip∷sipApi包的类注册员
  2107  org∷mind∷sip∷sipApi包的类时间
  2108  org∷mind∷sip∷sipApi包的接口SipListener
  2110  org∷mind∷sip∷sipApi包的接口SipProvider
  2112  org∷mind∷sip∷sipApi包的类SipExpiresHandling
  标号   技术特征
  2114   org∷mind∷sip∷sipApi包的类SipEndUser
  2200   UML类图，表示org∷mind∷sip∷sipApi∷userAgent包
  2202   org∷mind∷sip∷sipApi∷userAgent包的接口SipUserAgentListener
  2204   org∷mind∷sip∷sipApi∷userAgent包的接口SipUserAgentServerListener，从类SipUserAgentListener 2202导出
  2206   org∷mind∷sip∷sipApi∷userAgent包的接口SipUserAgentClientListener，从类SipUserAgentListener 2202导出
  2208   org∷mind∷sip∷sipApi∷userAgent包的类SipConnectionReq
  2210   org∷mind∷sip∷sipApi∷userAgent包的接口SipUserAgentType
  2212   org∷mind∷sip∷sipApi∷userAgent包的接口SipUserAgentFactory
  2214   org∷mind∷sip∷sipApi∷userAgent包的类SipUserAgent，从类SipUserAgentType 2210导出
  2214a   org∷mind∷sip∷sipApi∷userAgent包的类UAClient，从类SipUserAgent 2214导出
  2214b   org∷mind∷sip∷sipApi∷userAgent包的类UAServer，从类SipUserAgent 2214导出
  2216   org∷mind∷sip∷sipApi∷userAgent包的类SipNegotiationModel
  2218   org∷mind∷sip∷sipApi∷userAgent包的类SipRegistrationReq
  2220   org∷mind∷sip∷sipApi∷userAgent包的类SipRegistrationCfm
  2300   UML类图，表org∷mind∷sip∷sipApi∷registrar包
  2302   org∷mind∷sip∷sipApi∷registrar包的接口SipRegistrarListener
  2304   org∷mind∷sip∷sipApi∷registrar包的接口SipRegistrarType
  标号   技术特征
  2306   org∷mind∷sip∷sipApi∷registrar包的类SipRegistrar，从所述类SipRegistrarType 2304导出
  2308   org∷mind∷sip∷sipApi∷registrar包的类SipRegistrationInd
  2310   org∷mind∷sip∷sipApi∷registrar包的类SipRegistrationRsp
  2312   org∷mind∷sip∷sipApi∷registrar包的接口SipRegistrarFactory
  2400   UML类图，表示org∷mind∷sip∷sipApi∷management包
  2402   org∷mind∷sip∷sipApi∷management包的接口SipManagementListener
  2404   org∷mind∷sip∷sipApi∷management包的接口SipManager
  2406   org∷mind∷sip∷sipApi∷management包的类SipConfigurationReq
  2500   UML类图，表示org∷mind∷sip∷sipApi∷time包
  2502   org∷mind∷sip∷sipApi∷time包的接口SipExpiresType
  2504   org∷mind∷sip∷sipApi∷time包的类SipParseException
  2506   org∷mind∷sip∷sipApi∷time包的类SipExpires
  2508   org∷mind∷sip∷sipApi∷time包的接口SipExpiresFactory
  2600   UML消息序列图(MSC)，表示服务提供商的配置以及服务用户与所述服务提供商的绑定
  2700   UML消息序列图(MSC)，表示客户机的用户代理与服务器之间的连接建立
  2800   UML消息序列图(MSC)，表示用于端对端协商协议(E2ENP)的“选项”方法
  2900   UML消息序列图(MSC)，表示客户机的用户代理与服务器之间的连接释放
  3000   嵌套有限状态机(FSM)的第一状态转变图，表示在根状态中执行的互斥相关过程
  3100   嵌套有限状态机(FSM)的第二状态转变图，表示在NegOfferer
  标号 技术特征
子状态中执行的互斥相关过程
  3200 嵌套有限状态机(FSM)的第三状态转变图，表示在NegAnswerer子状态中执行的互斥相关过程
  3300 嵌套有限状态机(FSM)的第四状态转变图，表示在ReNegOfferer子状态中执行的互斥相关过程
  3400 嵌套有限状态机(FSM)的第五状态转变图，表示在ReNegAnswerer子状态中执行的互斥相关过程
  3500 _ResvMtx有限状态机(FSM)的第六状态转变图，用于允许多个请求根据其优先级以协调方式占用互斥
  3600 嵌套有限状态机(FSM)的第七状态转变图，表示在WaitForCoordDone子状态中执行的互斥相关过程
  3700 UML消息序列图(MSC)，表示E2ENP用户代理(UA)的应用编程接口(API)和SIP用户代理(UA)的通用应用编程接口(API)的相关所需的预协商过程，从而利用E2ENP用户代理(UA)的上述有限状态机(FSM)
  3702 类OffererSIPServiceUser，实现接口SipUserAgentClientListener2206
  3704 类OffererSIPServiceProvider，从类SipUserAgent 2214导出
  3706 类AnswererSIPServiceProvider，从类SipUserAgent 2214导出
  3708 类AnswererSIPServiceUser，实现接口SipUserAgentServerListener 2204
  3800 UML消息序列图(MSC)，表示采用E2ENP用户代理(UA)的应用编程接口(API)和SIP用户代理(UA)的通用应用编程接口(API)的相关所需的QoS协商过程和资源保留协调的会话建立，从而利用E2ENP用户代理(UA)的上述有限状态机(FSM)
  3900 表1：该表说明根据应用于端对端协商协议(E2ENP)的用户代
  标号  技术特征
 理(UA)的应用编程接口(API)的Java实现，由服务提供商实现的原语的列表
  4000  表2：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由服务用户实现的原语的列表
  4100  表3：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由作为提议方的服务用户实现的原语的列表
  4200  表4：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的应用编程接口(API)的Java实现，由作为应答方的服务用户实现的原语的列表
  4300  表5：该表说明第一高速缓存级的应用编程接口(API)提供的方法
  4400  表6：该表说明第二高速缓存级的应用编程接口(API)提供的方法
  4500  表7：该表说明必须由分析器的应用编程接口(API)实现的原语的列表
  4600  表8：该表说明必须为产生特定分析器示例实现的原语的列表
  4700  表9：该表说明必须由工厂的应用编程接口(API)实现的原语的列表
  4800  表10：该表说明必须为产生特定工厂示例实现的原语的列表
  4900  表11：该表说明众所周知的工厂-工厂类E2ENPContentHandlerFactory提供的方法
  5000  表12：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务提供商实现的原语的列表
  标号  技术特征
  5100  表13：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的客户机端特定原语的列表
  5200  表14：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的服务器端特定原语的列表
  5300  表15：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的客户机端和服务器端特定原语的列表
  5400  表16：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务提供商实现的原语的列表
  5500  表17：该表说明根据应用于端对端协商协议(E2ENP)的用户代理(UA)的通用应用编程接口(API)的Java实现，由服务用户实现的原语的列表
  5600  表18：状态转变表，说明应用异常事件的综述
  5700  表19：该表说明应用于根据本发明的端对端协商协议(E2ENP)的应用计时器

Claims (25)

1.一种为在参与移动电信会话的至少两个已注册终端对等体上运行的多流多媒体应用(130)和/或正连接到移动网络的中间件(130)提供应用编程接口(101b)的***，所述***(128)利用连接的E2ENP阶段的概念提供保证的端对端质量和资源能力并且适合提供
-多个备选能力和QoS合同的预协商，
-租赁预协商信息的管理，
-通过多个备选能力和/或QoS合同的协商在所述终端对等体之间的会话建立，以及
-端对端质量和能力的动态重新协商，
其中要协商的信息以可交换格式来表达，以便允许所述多流多媒体应用(130)约定协商信息的特定参考模型，它则可用于动态配置有限状态机(106)，以便根据相应用户的偏好和简档来合理安排本地、对等体和网络资源。
2.如权利要求1所述的***，其特征在于，所述***(128)被在内部分解为协调内部过程与应用编程接口(101a-e)的一组有限状态机(106)。
3.如权利要求2所述的***，其特征在于，所述多流多媒体应用(130)和/或所述中间件(130)利用所述有限状态机(106)进行动态配置。
4.如以上权利要求中的任一项所述的***，其特征在于，它被设计成支持多个并发用户。
5.一种用于建立电信网络中两个实体之间会话的***，所述单元(128)包括以下应用编程接口(API)：
-表示所述单元(128)与管理它的实体(102)之间的接口(IF1)的管理API(101a)，
-表示所述单元(128)、使用所述单元(128)所提供的服务的中间件(130)和/或应用(130)之间的接口(IF2)的API(101b)，
-表示所述单元(128)与会话层协议的用户代理(110)之间的接口(IF3)的通用会话层协议API(101c)。
6.如以上权利要求中的任一项所述的***，其特征在于，两级E2ENP高速缓存(104)，用于管理协商对象标识符，以便通过非持久地存储和检索下列项目，把特定应用(130)和/或中间件(130)的标识方案与为E2ENP指定的方案分离
-引用相应移动电信会话的E2ENP会话标识符，
-引用所述单元(128)的所述有限状态机(106)所处理的相应服务提供商(110)的E2ENP会话标识符，以及
-引用使用所述单元(128)所提供的服务的任何应用(130)和/或中间件(130)所处理的相应服务用户(130)的E2ENP会话标识符。
7.如以上权利要求中的任一项所述的***，其特征在于，所述单元(128)适合于
-在给定E2ENP预协商或协商过程的执行期间预先高速缓存信息，其中一旦给定过程已经成功完成，所述预先高速缓存的数据保持被高速缓存，以便将来在稍后的E2ENP会话期间引用，以及
-高速缓存可在新的E2ENP预协商或协商过程中用作对已经在终端对等体之间(预)协商的数据的引用的信息。
8.如以上权利要求中的任一项所述的***，其特征在于，E2ENP会话层协议API(101a-e)独立于实际使用的会话层协议和会话描述协议实现。
9.如以上权利要求中的任一项所述的***，其特征在于，表示所述单元(128)与用于对E2ENP会话描述编码的工厂示例(114)之间的接口(IF5)的工厂API(101e)。
10.如以上权利要求中的任一项所述的***，其特征在于，表示所述单元(128)与对E2ENP会话描述解码所需的分析器示例(112)之间的接口(IF4)的分析器API(101d)。
11.如权利要求9和10中的任一项所述的***，其特征在于，所述分析器示例(112)和所述工厂示例(114)可通过采用相同的协议来独立地配置。
12.如以上权利要求中的任一项所述的***，基于会话发起协议(SIP)分别与会话描述协议(SDP)或会话描述协议-下一代(SDPng)的扩充相结合的新颖使用。
13.如权利要求12所述的***，其特征在于，会话层协议和会话描述协议(SDP)或会话描述协议-下一代(SDPng)分别是可独立配置的。
14.一种协商方法，为在参与移动电信会话的至少两个已注册终端对等体上运行的多流多媒体应用(130)和/或正连接到移动网络的中间件(130)提供保证的端对端质量和资源能力，以便动态适应传输质量的变化，它基于端对端协商协议(E2ENP)的扩充，所述方法提供
-多个备选能力和QoS合同的预协商，
-租赁预协商信息的管理，
-通过多个备选能力和/或QoS合同的协商以及终端和网络资源保留的协调在所述终端对等体之间的会话建立，以及
-端对端质量和能力的快速动态重新协商
利用连接的E2ENP阶段的概念，
其特征在于以下步骤
以可交换格式表达要协商的信息，以便允许所述多流多媒体应用(130)约定协商信息的特定参考模型，它则可用于动态配置有限状态机(106)，以便根据相应用户的偏好和简档来合理安排本地、对等体和网络资源。
15.如权利要求14所述的协商方法，其特征在于，所述资源保留协调过程是基于多阶段呼叫建立机制，它使网络QoS和安全性建立成为由会话层协议发起并由会话描述协议实现描述的会话的前提，其中网络资源保留机制在会话开始前被部署，
其中，由单元(218)调用到中间件(130)的已注册客户机端、以便分别指明特定消息交换的到达或确认给定消息交换的结束的指示(Ind)和确认(Cfm)原语是E2ENP的组成部分，并被映射到E2ENP“qosdef”部分(1300)，它或者指定对等体的能力，或者定义已经由利用所述单元(128)及其相应协商过程的实体验证的已确认QoS合同。
16.如权利要求14和15中的任一项所述的协商方法，其特征在于，根据“经济原则”在不同对等体之间的保留过程的强制同步。
17.如权利要求14至16中的任一项所述的协商方法，其特征在于，若提议方端的终端对等体没有执行网络资源保留，则作为应答方的另一个终端对等体的单元(128)通过检查所述提议方给出的前提来确定这种情况，并相应地使所述应答方能够透明地处理资源保留协调。
18.如权利要求14至17中的任一项所述的协商方法，其特征在于以下步骤：
允许端对端的和分段的保留，其中网络资源保留预先在本地进行，而没有成本和/或对会话建立的重大影响。
19.如权利要求14至18中的任一项所述的协商方法，其特征在于，若多流多媒体应用(130)或中间件(130)希望执行网络资源的“预先保留”，则E2ENP信令分别向所述应用(130)或中间件(130)提供正确定时，从而通知它何时在所有端的资源保留都已经完成。
20.如权利要求14至19中的任一项所述的协商方法，其特征在于，新的E2ENP语法，它允许标识不同E2ENP用户的E2ENP地址(600)与所述会话层协议和/或下面由单元(128)使用的相应传输协议无关，所述E2ENP地址(600)通过所应用的预协商和协商原语传递并被映射到用于搭载E2ENP信息的基础会话层协议所用的特定语法。
21.一种用于如权利要求14至20中任一项所述的协商方法的争用解决方法，它适用于两个对等体同时发起E2ENP阶段的情况，
其中E2ENP UA(128)不仅包含提议方发送的会话标识符，而且包含其散列以及时标，所述散列作为在任何后续会话层协议消息中的所述会话标识符的替代物，它考虑了E2ENP UA(128)在其中为活动的计算单元的IP地址，这在每当发起协商或预协商阶段时被应用。
22.如权利要求21所述的争用解决方法，其特征在于，若两个对等体还没有涉及多媒体会话，则每个对等体把它已经产生的散列与从所述对等体接收的散列进行比较，以及具有最高值的对等体被自动选作提议方，从而以同样方式继续进行预协商或协商阶段，而另一个对等体自动转到应答方模式。
23.如权利要求21所述的争用解决方法，其特征在于，若两个对等体已经涉及到多媒体会话，则其请求已经被拒绝的对等体在其请求已经被接受的对等体已经完成其协商过程之后应用非计划的重新协商过程。
24.一种电信网络，其特征在于，所述电信网络包括如权利要求1至13中任一项所述的***(128)。
25.一种计算机软件程序产品，其特征在于，所述计算机软件程序产品在无线网络环境中的移动终端上运行时，实现如权利要求1至13中任一项所述的***(128)。
CN2003801070463A 2002-10-23 2003-10-15 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构 Expired - Fee Related CN1729672B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP02023836.6 2002-10-23
EP02023836 2002-10-23
EP20020027408 EP1414211A1 (en) 2002-10-23 2002-12-09 Software architecture for capability and quality-of-service negotiations and session establishment for distributed multimedia applications
EP02027408.0 2002-12-09
PCT/EP2003/011439 WO2004039031A2 (en) 2002-10-23 2003-10-15 Software architecture for capability and quality-of-service negotiations and session establishment for distributed multimedia applications

Publications (2)

Publication Number Publication Date
CN1729672A true CN1729672A (zh) 2006-02-01
CN1729672B CN1729672B (zh) 2012-05-16

Family

ID=32071082

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2003801070463A Expired - Fee Related CN1729672B (zh) 2002-10-23 2003-10-15 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构

Country Status (5)

Country Link
US (3) US8549143B2 (zh)
EP (1) EP1414211A1 (zh)
JP (1) JP2006504363A (zh)
CN (1) CN1729672B (zh)
WO (1) WO2004039031A2 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109542644A (zh) * 2018-11-19 2019-03-29 北京小米移动软件有限公司 应用程序编程接口调用方法及装置
CN110096583A (zh) * 2019-05-09 2019-08-06 苏州思必驰信息科技有限公司 多领域对话管理***及其构建方法
CN110971576A (zh) * 2018-09-30 2020-04-07 北京国双科技有限公司 一种安全认证的方法和相关装置

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1213895B1 (en) * 2000-12-08 2007-09-05 Sony Deutschland GmbH High-level interface for QoS-based mobile multimedia applications
US20080313282A1 (en) 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
EP1414211A1 (en) * 2002-10-23 2004-04-28 Sony International (Europe) GmbH Software architecture for capability and quality-of-service negotiations and session establishment for distributed multimedia applications
US8037170B2 (en) * 2004-01-27 2011-10-11 Hitachi, Ltd. Integrated application management system, apparatus and program, and integrated session management server, system, program and server chassis, and communication system, session management server and integration application server
US20050268308A1 (en) * 2004-05-28 2005-12-01 Nokia Corporation System and method for implementing a general application program interface
US8250230B2 (en) 2004-09-30 2012-08-21 Microsoft Corporation Optimizing communication using scalable peer groups
US7613703B2 (en) 2004-09-30 2009-11-03 Microsoft Corporation Organizing resources into collections to facilitate more efficient and reliable resource access
SE0402396D0 (sv) * 2004-10-05 2004-10-05 Ericsson Telefon Ab L M Refresh of cached terminal capabilities data
US7565395B2 (en) * 2005-02-01 2009-07-21 Microsoft Corporation Mechanism for preserving session state when using an access-limited buffer
CN100388714C (zh) * 2005-06-22 2008-05-14 中兴通讯股份有限公司 采用混合路径的端到端服务质量的域间协商方法及***
US8442031B2 (en) * 2005-06-24 2013-05-14 Alcatel Lucent Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints
CN1889565B (zh) * 2005-08-16 2010-05-05 华为技术有限公司 会话建立方法
CN1925430A (zh) 2005-08-31 2007-03-07 华为技术有限公司 IPv6网络应用层协议的检测方法
US7788698B2 (en) 2005-08-31 2010-08-31 Microsoft Corporation Pre-negotiation and pre-caching media policy
US8041800B2 (en) * 2005-11-08 2011-10-18 International Business Machines Corporation Automatic orchestration of dynamic multiple party, multiple media communications
CN1968258B (zh) * 2005-11-15 2010-12-01 华为技术有限公司 一种媒体协商不同类型能力的方法
US8156469B2 (en) * 2005-12-29 2012-04-10 Sap Ag Single composition of pattern modules
US7881316B2 (en) 2006-09-29 2011-02-01 Microsoft Corporation Multiple peer groups for efficient scalable computing
ES2328765B1 (es) * 2006-10-03 2010-08-30 Vodafone España S.A. Sistema gestor de contenidos a compartir entre terminales de usuario dotados de un habilitador de servicios ip y basados en señalizacion sip.
US7971132B2 (en) * 2007-01-05 2011-06-28 Dialogic Corporation Universal multimedia engine and method for producing the same
US8028048B2 (en) * 2007-02-27 2011-09-27 International Business Machines Corporation Method and apparatus for policy-based provisioning in a virtualized service delivery environment
US20080235262A1 (en) * 2007-03-21 2008-09-25 Holm Aaron H Digital file management system with file mapping for high resolution and other images
US20090023476A1 (en) * 2007-07-16 2009-01-22 Nokia Corporation Apparatuses and methods for facilitating communication of devices
US7974204B2 (en) * 2007-11-07 2011-07-05 The Boeing Company Quality of service management for message flows across multiple middleware environments
KR101528853B1 (ko) * 2007-12-14 2015-07-01 삼성전자주식회사 Ａｐｉ 서비스 방법과 ａｐｉ 매쉬업 생성 방법, 장치 및기록매체
US7877453B2 (en) * 2008-01-02 2011-01-25 International Business Machines Corporation System and method for optimizing data traffic in signaling stream of IP multimedia subsystem service
AU2008355488B2 (en) 2008-04-28 2013-12-19 Fujitsu Limited Method for processing connection in wireless communication system, wireless base station, and wireless terminal
US20090285376A1 (en) * 2008-05-13 2009-11-19 Ibm Method and tooling for the development of telecom services
KR101528389B1 (ko) * 2009-03-27 2015-06-11 텔레폰악티에볼라겟엘엠에릭슨(펍) 적절한 서비스 레벨을 제공하는 방법 및 장치
CN101583160B (zh) * 2009-06-19 2011-08-24 中兴通讯股份有限公司 一种实现分层服务质量业务的装置及方法
US8599834B2 (en) * 2009-09-29 2013-12-03 Ipc Systems, Inc. Systems, methods, and computer program products for providing a manual ring-down communication line using session initiation protocol
US8578020B2 (en) * 2009-12-24 2013-11-05 Empire Technology Development Llc Dynamic mobile application quality-of-service monitoring and reporting
KR101684404B1 (ko) * 2010-01-18 2016-12-08 삼성전자주식회사 서로 다른 두 개의 운영체제를 사용하는 휴대용 단말기에서 서비스품질의 데이터 서비스를 지원하기 위한 방법 및 장치
US20110238498A1 (en) * 2010-03-29 2011-09-29 Microsoft Corporation Service stage for subscription management
US8984048B1 (en) 2010-04-18 2015-03-17 Viasat, Inc. Selective prefetch scanning
TW201215214A (en) * 2010-07-06 2012-04-01 Interdigital Patent Holdings IP multimedia subsystem (IMS)-based pre-negotiation of video codec for video single radio video call continuity
US9129035B2 (en) * 2010-10-05 2015-09-08 Hewlett-Packard Development Company, L.P. Systems, methods, and apparatus for accessing object representations of data sets
US9300551B2 (en) 2010-11-29 2016-03-29 Nec Corporation Service quality management system and method
US9542203B2 (en) 2010-12-06 2017-01-10 Microsoft Technology Licensing, Llc Universal dock for context sensitive computing device
US8923770B2 (en) 2010-12-09 2014-12-30 Microsoft Corporation Cognitive use of multiple regulatory domains
US8792429B2 (en) 2010-12-14 2014-07-29 Microsoft Corporation Direct connection with side channel control
US8948382B2 (en) 2010-12-16 2015-02-03 Microsoft Corporation Secure protocol for peer-to-peer network
US9294545B2 (en) 2010-12-16 2016-03-22 Microsoft Technology Licensing, Llc Fast join of peer to peer group with power saving mode
US8971841B2 (en) 2010-12-17 2015-03-03 Microsoft Corporation Operating system supporting cost aware applications
US9912718B1 (en) * 2011-04-11 2018-03-06 Viasat, Inc. Progressive prefetching
US11983233B2 (en) 2011-04-11 2024-05-14 Viasat, Inc. Browser based feedback for optimized web browsing
DE102012013336B4 (de) * 2011-07-08 2015-04-09 Avaya Inc. Aushandeln einer kontinuierlichen multi-stream-präsenz
US8812005B2 (en) * 2012-02-03 2014-08-19 Apple Inc. System and method for scheduling packet transmission on a client device using traffic classes and opportunistic behavior
CN102781119B (zh) * 2012-06-13 2016-04-13 哈尔滨工业大学深圳研究生院 无线泛在网络应用终端***及软件组件应用进程管理方法
KR20140070740A (ko) * 2012-11-26 2014-06-11 한국전자통신연구원 사물간 연계 및 협업을 제공하기 위한 통합 프레임워크 시스템, 통합 프레임워크 제공 방법
US9524261B2 (en) * 2012-12-21 2016-12-20 Apple Inc. Credit lookahead mechanism
US11222001B2 (en) * 2013-03-15 2022-01-11 Sap Se Augmenting middleware communication services
FR3011412A1 (fr) * 2013-09-27 2015-04-03 Orange Procede et dispositif de communication entre au moins un premier terminal et un deuxieme terminal
CN104948465A (zh) * 2014-03-26 2015-09-30 北京北方微电子基地设备工艺研究中心有限责任公司 共享干泵的处理方法及***
US10855797B2 (en) 2014-06-03 2020-12-01 Viasat, Inc. Server-machine-driven hint generation for improved web page loading using client-machine-driven feedback
EP3219067B1 (en) * 2014-11-12 2019-05-22 Telefonaktiebolaget LM Ericsson (publ) Methods and devices for negotiating session descriptor parameters
US10037301B2 (en) * 2015-03-04 2018-07-31 Xilinx, Inc. Circuits and methods for inter-processor communication
US10387343B2 (en) * 2015-04-07 2019-08-20 International Business Machines Corporation Processing of events for accelerators utilized for parallel processing
US10394743B2 (en) * 2015-05-28 2019-08-27 Dell Products, L.P. Interchangeable I/O modules with individual and shared personalities
CA3002517C (en) 2015-10-20 2022-06-21 Viasat, Inc. Hint model updating using automated browsing clusters
US10110444B2 (en) * 2016-01-06 2018-10-23 Centurylink Intellectual Property Llc Model driven service state machine linkage methodology and system
US11108833B2 (en) * 2016-06-06 2021-08-31 Blackberry Limited Crossed-invite call handling
US20180204159A1 (en) 2017-01-19 2018-07-19 Bank Of America Corporation Resource and experience factor value generation system
CN110865798B (zh) * 2018-08-28 2023-07-21 ***通信集团浙江有限公司 一种线程池优化方法及***
US10749900B2 (en) * 2018-09-28 2020-08-18 The Mitre Corporation Deploying session initiation protocol application network security
CN111198770B (zh) * 2018-11-19 2023-06-20 北京图森智途科技有限公司 Ros1消息的通信方法、装置和***、转换方法和装置
KR102042495B1 (ko) * 2018-11-30 2019-11-08 아주대학교산학협력단 멀티 코어 시스템의 저전력 운영을 위한 데이터 흐름 최적화 장치 및 방법
US11169862B2 (en) * 2019-08-09 2021-11-09 Ciena Corporation Normalizing messaging flows in a microservice architecture
CN113098985B (zh) * 2021-06-02 2021-09-28 武汉中科通达高新技术股份有限公司 一种会话管理方法及调度服务器
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58166850A (ja) * 1982-03-27 1983-10-03 Iryo Joho Syst Kaihatsu Center セツシヨン設定衝突の制御方式
CA2286534A1 (en) * 1999-10-18 2001-04-18 American Gem Corporation Method for secure user access to multiple network accessible secure files
US6934752B1 (en) * 2000-03-23 2005-08-23 Sharewave, Inc. Quality of service extensions for multimedia applications in wireless computer networks
US7020611B2 (en) * 2001-02-21 2006-03-28 Ameritrade Ip Company, Inc. User interface selectable real time information delivery system and method
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US7414981B2 (en) * 2001-04-25 2008-08-19 Qwest Communications International, Inc. Method and system for event and message registration by an association controller
US7020707B2 (en) * 2001-05-30 2006-03-28 Tekelec Scalable, reliable session initiation protocol (SIP) signaling routing node
US8086665B1 (en) * 2001-08-21 2011-12-27 Rockstar Bidco, LP Technique for enabling a plurality of software components to communicate in a software component matrix environment
US20040037264A1 (en) * 2002-08-23 2004-02-26 Charbel Khawand Pre-negotiated quality of service
US7453906B2 (en) * 2002-09-19 2008-11-18 Microsoft Corporation Systems and methods for providing automatic network optimization with application variables
US7149510B2 (en) * 2002-09-23 2006-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Security access manager in middleware
EP1414211A1 (en) * 2002-10-23 2004-04-28 Sony International (Europe) GmbH Software architecture for capability and quality-of-service negotiations and session establishment for distributed multimedia applications

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110971576A (zh) * 2018-09-30 2020-04-07 北京国双科技有限公司 一种安全认证的方法和相关装置
CN109542644A (zh) * 2018-11-19 2019-03-29 北京小米移动软件有限公司 应用程序编程接口调用方法及装置
CN109542644B (zh) * 2018-11-19 2022-12-09 北京小米移动软件有限公司 应用程序编程接口调用方法及装置
CN110096583A (zh) * 2019-05-09 2019-08-06 苏州思必驰信息科技有限公司 多领域对话管理***及其构建方法

Also Published As

Publication number Publication date
US20060294112A1 (en) 2006-12-28
US20170006071A1 (en) 2017-01-05
EP1414211A1 (en) 2004-04-28
WO2004039031A3 (en) 2004-06-17
JP2006504363A (ja) 2006-02-02
CN1729672B (zh) 2012-05-16
US20140040485A1 (en) 2014-02-06
US8549143B2 (en) 2013-10-01
WO2004039031A2 (en) 2004-05-06

Similar Documents

Publication Publication Date Title
CN1729672A (zh) 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构
CN1172505C (zh) 在互联网的服务器与具芯片卡的终端间传送数据的方法
CN1623308A (zh) 用于强制实施旨在为多流和多媒体应用提供QoS支持的端到端协商协议的不同阶段的模型
CN1309223C (zh) 用于移动多媒体应用的通用服务质量适应构架
CN1599376A (zh) 网络媒体话机终端的应用和通信方法
CN1222896C (zh) 用户简档数据的管理
CN1154298C (zh) 分布式网络计算***及该***用的信息交换装置和方法
CN1565105A (zh) 手持无线会议技术
CN101060464A (zh) 地址变换装置、消息处理方法及网络***
CN1227862C (zh) 多媒体信息通信***
CN1677979A (zh) 通过网络在计算机之间共享对象的***和方法
CN1816053A (zh) 基于会话初始化协议的流媒体直播p2p网络方法
CN1511406A (zh) 用于实现分布式多媒体应用端到端服务质量协商的方法
CN1606737A (zh) 即时传信用户和客户机身份的分离
CN1801810A (zh) 一种会话初始化协议消息体内容处理方法及网络
CN1647455A (zh) 在多群集网络中进行通信的方法、连接设备及网桥
CN1437812A (zh) 对设置参数层进行组织及组合以生成与通讯网络相关的实体的整体文件
CN1360782A (zh) 在不同网络的匿名用户之间智能建立会话的分布式***
CN1394426A (zh) 因特网电话网络***、网络访问方法及通话装置适配器
CN1346564A (zh) 提供虚拟桌面***体系结构的方法和装置
CN1526246A (zh) 移动即时消息收发和存在服务
CN1296585A (zh) 用于通用数据交换网关的方法和装置
CN1859393A (zh) 一种协商设备信息的***及方法
CN1751473A (zh) 用于实现基于策略的网络业务管理的方法和***
CN1823332A (zh) 用户通知的***和方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20080919

Address of the applicant after: Berlin, Germany

Applicant after: Sony International (Europe) GmbH

Co-applicant after: Munich, Germany

Applicant after: Nokia Siemens Networks limited liability company

Address of the applicant before: Berlin, Germany

Applicant before: Sony International (Europe) GmbH

Co-applicant before: Munich, Germany

Applicant before: SIEMENS Corporation

C14 Grant of patent or utility model
GR01 Patent grant
C56 Change in the name or address of the patentee

Owner name: SONY INT EUROP GMBH

Free format text: FORMER NAME: SONY INTERNATIONAL (EUROPE) G.M.B.H.

CP01 Change in the name or title of a patent holder

Address after: Berlin

Co-patentee after: Nokia Siemens Networks GmbH

Patentee after: Sony Int Europ GmbH

Address before: Berlin

Co-patentee before: Nokia Siemens Networks GmbH

Patentee before: Sony International (Europe) GmbH

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120516

Termination date: 20171015