用于强制实施旨在为多流和多媒体应用提供QOS支持的端到端协商协议的不同阶段的模型.pdf

用于强制实施旨在为多流和多媒体应用提供 QoS支持的端到端协商协议的不同阶段的模型
发明领域和背景
本基础发明通常涉及分布式多媒体应用和技术的无线移动网络环境中的移动计算技术领域。更明确地，它是针对在动态无线互联网协议(IP)网络中在支持不同接入技术的移动设备上所运行的自适应实时服务的服务质量(QoS)管理领域，从而包括与多媒体媒件与资源预留机制特别相关的研究与发展问题。关于这点，本发明建议了一种按照这样一种方式来定义用户配置文件和终端能力信息的模型，使得分层QoS合同规范(例如通过相关媒体流的不同QoS合同组的强制相关)可以被实施并用于导出可协商信息。
作为此概念的一个参考实施，本发明建议了一种新颖应用，它基于可扩展标识语言(XML)由互联网工程任务组(IETF)与下一代会话描述协议(SDPng)规范协同来把会话启动协议(SIP)标准化，以便实现端对端QoS协商协议(E2ENP)概念。根据本基础发明所建议的解决方案的概念是基于一个提议，此提议及其具体参考结构最初在”Concepts forService Adaptation，Scalability and QoS Handling onMobility-Enabled Networks”(移运性启用的网络上的服务适配、可量测性和QoS处理的概念)(IST-1999-10050 BRAIN Deliverable1.2，03/31/2001，http：//www istbrain.org/)(在下面被称为[BRAIN])中已经被认识。关于这点，将导出一组基础要求。从而，将展开一次关于此要求组和关于所述需求的最佳方案选择的讨论。
互联网已经证明是一种用于递送广大电子服务组(尤其包括电话、电子信息以及音频/视频服务)的成功结构，不仅对于固定用户如此，而且对于漫游用户也是如此。微和宏IP移运性以及无线IP技术实际上为互联网与第二代以及第三代移动电话系统的完整集合铺设了道路。为了达到这个目的，下一代IP网络和应用将不得不处理逐渐变得重要的无线接入、移动性管理、服务质量(QoS)提供以及多媒体服务的挑战。
移动用户在这种环境中将最可能面对的一个极重要的问题是：如何对付在端系统处以及网络中的有限资源量以及不稳定环境的情形。由于像无线链路质量降低、水平和/或垂直切换、有限的移动终端资源量之类的各种原因，移动用户实际上被预期更经常遭受在使移动用户的QoS合同不再由网络下部构造来支持的不幸情况上。在此文献的剩余部分中，这些不幸的情况将被称为”QoS妨碍”。通过假设在干线中适当的资源过供应，可以预期QoS妨碍将最可能来源于接入网中，特别是来源于它的无线部分中。
此外，处理与多个对等体同时交换的多媒体流信息的移动多媒体应用将需要一种处理QoS要求的实际且有效的方法，特别是在前述不稳定环境情形前。
对付不稳定环境情形的一种可能方法是：通过提前计划反作用，能使移动用户应用有效且及时地对QoS妨碍作出反应。对等体实际上能够在不同抽象层上离线协商各个备选QoS合同，以使在连接建立时刻以及QoS妨碍发生的任何时候，能够在对等体之中及时地商定如何最有效地适应变化的情形。
此外，通过在所有被包括的对等体处的本地资源已被确定并因此已经做出它们的预留之前避免请求任何网络资源预留，则对等体可以接着进行一个用于有效强制实施预先协商的QoS合同的具体程序。此程序还被称为”经济原理”。
合并上述两个计划机制的总体解决方案现在将被称作”端对端协商协议”(E2ENP)。
特别的，应当指出：能力(例如编解码器)的协商因此被认为是一个独立的问题，是对用户QoS首选项和配置文件信息协商的补充。智能的，自适应应用和/或媒件因此能够实现由对等体端对端协商的任何这些信息的实际使用，以便对如[BRAIN]中所述的一个给定QoS妨碍做出反应而选择最好的适配策略。
发明内容
根据现有技术，各种关于移动环境中的QoS管理问题的方法和技术当前可用，它们与本基础发明课题密切相关。为了理解本发明的来龙去脉，需要简单解释所述技术包括的主要特性。
在欧洲专利申请EP 01 122 366.6中，已经引入并详细描述了E2ENP协议。所述发明提供一个用于为分布式多媒体应用实现动态端对端QoS协商和控制协调的框架。该框架基于用户首选项建立于适配路径和(备选)QoS合同的动态能力协商和规范。特别的，在与网络资源预留(例如RSVP)、本地终端资源预留(例如CPU，存储器，功率，辅助设备)以及适配机制的协调中，基于类似SIP、RTSP和/或SDP那样的基于IP的协议地扩展，提出了一个提供备选QoS、能力、首选项和/或配置的端对端协商协议。就此而言，并且相对于两个或更多对等体，将识别六个阶段，通过这些阶段，能使对等体建立多方、多流和/或多媒体通信。详细地，这些阶段是协议发现、预先协商、多流时间同步与QoS相关性、快速协商(遵从经济原理)、再协商(遵从经济原理)以及资源预留和/或释放。所有这六个阶段可以在不同时间被连接或执行。
在”Concepts for Service Adaptation，Scalability and QoSHandling on Mobility-Enabled Networks”(移动性启用的网络上的服务适应、可量测性以及QoS处理的概念)[BRAIN]中，提出了E2ENP概念基础。
在C.Perkins等人的”RTP Payload for Redundant Audio Data”(冗余音频数据的RTP有效载荷)(RFC2198，网络工作组，1997年9月)(在下面称为[RFC2198])和H.Schulzrinne等人的”RTP Profilefor Audio and Video Conferences with Minimal Control”(哥伦比亚大学，未完工程<draft-ietf-avt-profile-new-09.txt>)(在下面称为[RTP-Profile])中，叙述了经由带内信令的快速再协商的可能性。可是，当应该提供QoS时，这种信令只涉及编解码器的变化以及不同编码媒体的冗余支持，而没有考虑各自的效果。
在W.Marshall等人的”Integration of Resource Managementand SIP-SIP Extensions for Resource Management”(资源管理以及资源管理的SIP-SIP扩展的集成)(IETF SIP工作组，未完工程，<draft-ietf-sip-manyfolks-resource-01.txt>)(在下面称为[SI-PRES01])中以及W.Marshall等人的”SIP Extensions forResource Management”(资源管理的SIP扩展)(IETF草案，2000年11月，<draft-ietf-sip-many-folks-resource-00>)(在下面称为[MarshO0])中，作者提出了一种多阶段呼叫建立机制，它使网络QoS和安全性建立成为由会话启动协议(SIP)启动并由会话描述协议(SDP)描述的会话的一个前提。在使用现有网络资源预留机制(像RSVP)来开始会话之前，网络资源被预留。资源管理协议在呼叫信令的两个阶段之间被交错，并且在网络中资源可用之后邀请参与者。对前提的确认被明确地发出信号。只对于这些网络资源实行资源管理。对SDP的一种扩展被引入，以便确定是否符合所述前提。可是，[SIPRES01]和[Marsh00]没有考虑QoS的预先协商以及本地和对等体资源管理的集成。
在G.Camarillo的”Confirmation of SDP Preconditions”(SDP前提的确认)(IETF互联网草案，未完工程，<draft-camarillo-manyfolks-con-firm-02.txt>)(在下面称为[Cama00])中，引入一个附加的方向属性来指示哪一方发送所述前提确认。最后，当使用SDP前提时，[Cama00]提供了一种在SIP中执行第三方呼叫控制的机制。可是，[Cama00]没有考虑QoS的预先协商以及本地和对等体资源管理的集成。
在G.Klyne的”A Syntax for Describing Media Feature Sets”(一种描述媒体特征组的语法)(RFC2533，5GM/内容技术，1999年3月)(在下面称为[RFC2533])中，作者提供了一种表达媒体特征组的格式，所述媒体特征组表示媒体处理能力。另外，提供一种与特征组匹配的算法。它可用来确定发送者和接收者的能力是否兼容。在G.Klyne等人的”A revised media feature set matching algorithm”(一种修订的媒体特征组匹配算法)(IETF媒体特征注册WG，未完工程，<draft-klyne-conneg-feature-match-02.txt>)(在下面称为[Conneg00])中改善了这种匹配算法。另外，在G.Klyne等人的”Identifying Composite Media Features”(识别合成媒体特征)(IETF Conneg工作组，未完工程，<draft-ietf-conneg-feature-hash-05.txt>(在下面称为[Conneg00a])中，描述了合成媒体特征组的一种简略格式，其使用一种特征表示散列方法来描述所述合成。这可用于提供一个用于参考随机特征组表达式的简略形式，与解参考的任何特定机制无关。[RFC2533]和[CONNEG00]以及[CONNEG00a]或者F.Andreasen的”SDP Simple Capability NegotiationRequirements”(SDP简单的能力协商需求)(IETF MMUSIC工作组，未完工程，<draft-andeasen-mmusic-sdp-simcap-reqts-00.txt>)(在下面称为[SDPCN01])，既未集成现有的Internet协议，也没有包括预先协商备选QoS合同的概念，也没有集成本地、网络和对等体的资源预留机制。
在F.Andreasen的”SDP Simple capability negotiation”(SDP简单的能力协商)(IETF MMUSIC工作组，未完工程，<draft-andreasen-mmusic-sdp-simcap-00.txt>(在下面称为[SDPCN00])中，作者陈述了这样一个需求：即，虑及到能力组的简单参考，一个能力组应该包括一个处理(handle)(类似于上面提及的散列)。
在G.Klyne的”Protocol-Independent Content NegotiationFramework”(协议独立的内容协商框架)(RFC2703，5GM/内容技术，1999年9月)(在下面称为[RFC2703])中，作者为它与之相互作用的资源呈现了一种协议独立的内容协商的抽象框架。可是，它不提供内容协商过程。它识别用于表达发送者能力以及要被发射的数据资源、接收者能力的需要，以及交换这些能力的协议的需要。由一系列协商元数据交换来实现协商。当要被发射的一个特定数据文件已经被发现之时，就停止协商。如果发送者确定该文件，则发送者传送该数据，否则，接收者通知发送者。因此，此提议涉及内容协商而不是处理配置QoS合同和能力的预先协商。在[RFC2703]中建议的解决方案也未集成本地、对等体以及网络的资源预留。
在J.Rosenberg和H.Schulzrinne的”An Offer/Answer Modelwith SDP”(SDP的一种提供/应答模型)(IETF互联网草案，未完工程，<draft-rosenberg-mmusic-sdp-offer-answer00.txt>)(在下面称为[SDPOA00])中，描述了一种与SDP一对一能力协商的完整模型。可是，由于SDP的平坦分层结构，相互涉及的信息以及有关对媒体流进行编组的信息的定义，这个模型有一些问题。另外，这个模型只涉及能力协商而没有QoS支持。
在D.Kutscher等人的”Requirements for Session Descriptionand Capability Negotiation”(会话描述和能力协商的要求)(IETF互联网草案，未完工程，<draft-kutscher-mmusic-sdpng-req-01.txt>)(在下面称为[SDPNG01])，在多方多媒体会议方案中处理会话描述和端点能力协商的框架要求被识别。从而，所述文献提供了在多方多媒体会议方案中会话描述和端点能力协商的框架相关的一组要求。取决于用户首选项，系统能力或其他限制，可以为会议选择不同配置。在对等体之中的协商需求被识别，但是未被描述，以便确定公共可能配置组并且选择公共配置之一用于信息交换。这个能力协商被用来获取与可能参与者的端系统能力以及用户首选项兼容的有效会话描述。不同的协商策略可用来反映不同的会议类型。它们还识别对与会话建立联系的网络资源预留的需要。最后，一种提议被起草，用于描述能力并提供协商语言，但是所述协商语言不是一种协议。可是，在[SDPNG01]中建议的解决方案既不考虑用于确定一个公共QoS配置组的协商协议也没有集成本地、对等体以及网络的资源预留。另外，它既不集成处理(handle)的参考配置的过程，也没有在QoS合同概念上建立。而且，所述解决方案只处理编解码器协商，而没有考虑终端能力以及网络资源预留机制。
此IETF草案的最新版本，D.Kutscher等人的”SessionDescription and Capability Negotiation ”(会话描述和能力协商)(IETF互联网草案，未完工程，<draft-ietf-mmusic-sdpng-03.txt>)(在下面称为[SDPNG03])，提供了音频编解码器以及RTP配置文件的详细XML图解说明及原型。与此IETF提议的最新的更完整的版本相比，E2ENP特征为(作为那个提议的扩展)：
-E2ENP阶段的概念，
-根据与各个E2ENP阶段相关的PDU格式，新的SDPng部分及其各种配置，
-在新的<purpose>部分中，外在的<session>单元的使用，代替<conf>部分中的<owner>单元(它仍然保留，但是用于其它目的)，
-从<session>中导出(例如，经由散列方法)的会话标识符的协商和使用，以便限制E2ENP PDU的尺寸，其中，<session>(用计算出的散列)被使用在任何给定的E2ENP阶段的第一PDU或者它的级联中。
-协商信息的租赁(leasing)，
-协商信息的级联，
-现在由新的<qosdef>部分代替的原始<def>，
-在<cfg>部分中任何类型的网络和/或协议版本的提供，
-对音频编解码器和RTP配置文件的扩展，
-对于给定终端设备的本地强制实施或者用于将此委托给第三方组件(例如会议桥路)，在任何抽象层对模型QoS相关性和时间同步限制的可能性，
-第三方协助协商方案的处理，以及
-视频编解码器信息的处理。
D.Yon的两篇文献”Connection-Oriented Media Transport inSDP”(SDP中连接导向的媒体传输)(IETF MMUSIC工作组，未完工程，<draft-ietf-mmusic-sdp-comedia-01.txt>)(在下面称为[SDPC001])以及[SDPNG03]识别如下定义的必要性，所述定义是用来定义通信各方的哪一个——相对于连接模式——是发送者、接收者或发送者-接收者。另外，[SDPC001]识别表示的必要性，即，单个端口可以被用于同一内容的不同编码的媒体的发送或接收。由于协议的平坦结构，SDP的这种分别的定义是有问题的，另一方面，[SDPNG03]中所述的具有XML图解的SDPng对于分别的描述可以执行交叉参考。由于QoS协商的需要，发送者和/或接收者每一方的标识通过选择最适当的协商模式(推、拉或者推拉)，可以用于协商的加速。
[SDPCN00]的作者建议了一组SDP扩展，其提供最小的并且向后兼容的能力协商机制。[SDPCN00]只增加了能力协商的SDP扩展。
在B.Beser的”Codec capabilities Attribute for SDP”(SDP的编解码器能力属性)(IETF互联网草案，未完工程，<draft-beser-mmusic-capabilities00.txt>)(在下面称为[Beser00])中，作者扩展了SDP，以使端点知道编解码器选择并且能够商定一个公共组。通信伙伴因此能够获得始发者能力和首选项。可是，在[Beser00]中建议的解决方案只提供端点到协商编解码器的SDP扩展需要。
在J.Ott等人的”capability Description for GroupCooperation”(组协作的能力描述)(IETF互联网草案，未完工程，<draft-ott-mmusic-cap00.txt>)(在下面称为[Ott99])中，给出了一种在多方合作会话中用于描述端系统的可能且特定配置的表达式。这能使机制来定义端系统能力，计算一组公共能力并表示使用在会话描述中的选定媒体描述。它们不提供能力交换的协议。可是，在[Ott99]中建议的解决方案只提供一种用于结构描述的表达式。
在C.Bormann等人的”Simple Conference Control Protocol”(简单协商控制协议)(IETF互联网草案，未完工程，<draft-ietf-mmusic-sccp-01.txt>)(在下面称为[Bor00])中，作者为简洁联系的会议定义了简单会议控制协议(SCCP)的服务。分布式应用资源的会员管理、应用/会话管理以及访问控制规则被定义。可以使用SIP来建立会议状态，在持续期间使用SCCP来管理会议状态。这包括查找适当的配置、对配置协商以及改变配置。可是，却无意与本地以及网络的资源管理相互作用。SCCP还没有覆盖QoS合同的处理以及如何预先协商它的配置。
K.Nahrstedt和J.M.Smith的文献”The QoS Broker”(QoS代理)(IEEE多媒体杂志，1995年春，(2)1，第53-67)页)(在下面称为[Nahr95])，提供了一种基于QoS代理的端点结构模型，它是一种在端点改编(orchestrate)资源并协调通过各层的资源管理的功能实体。为了适当地配置系统，代理使用允许控制和协商。在对等实体之间的协商导致一种有效配置，它包括通信系统所有必要的组件。可是，在[Nahr95]中描述的模型既未集成现有的Internet协议也没有考虑像电池电源或无线子网络可用性之类的其它资源。
在O.Levin的”SIP Requirements for Support of Multimediaand Video”(支持多媒体和视频的SIP要求)(IETF互联网草案，未完工程，<draft-levin-sip-for-video-00.txt>)(在下面称为[Levin01])中，提供了在IP上支持实时多媒体的呼叫控制协议的一组要求。能力必须被表达，能力必须被发出信号以便识别必需的资源量，并且需要一个呼叫控制机制来打开/关闭/修改由能力和预留资源提出的边界内的媒体流。它们也建议在会话期间通知新的容量(如果可用)。另外，对等体不得不商定使用公共编解码器组。按要求放置一个开始/停止媒体流的会话控制机制。
可是，[Levin01]没有考虑把本地、远程以及网络资源管理集成到一个连贯的框架中；而[Levin01]只是提供了要求。强制实施该要求的协议和机制都没被建议。
在如下文献中：
-“Concepts for Service Adaptation，Scalability and QoSHandling on Mobility-Enabled Networks”(移动性启用的网络上的服务适配、可量测性以及QoS处理的概念)[BRAIN]，
-T.Robles、A.Kadelka、H.Velayos、A.Lappetelainen、A.Kassler、H.Li、D.Mandato、J.Ojala以及B.Wegmann的”QoSSupport for an All-IP System Beyond 3G”(超过3G的所有IP系统的QoS支持)(IEEE通信杂志，2001年8月，第39卷，No.8)，在下面称为[Roble01]，
-A.Kassler等人的”BRENTA-Supporting Mobility and Qualityof Service for Adaptable Multimedia Communication”(BRENTA-为自适应多媒体通信提供移动性和服务质量)IST移动通信最高级文集2000，Galway，爱尔兰，2000年10月，第403-408页)(在下面称为[Kass100])，以及
-A.Kassler等人的”An Open Endsystem Architecture forAdaptable Multimedia Services with QoS Support”(为自适应多媒体服务提供QoS的开放型端系统结构)(BRAIN研究组文集，伦敦，2000年)(在下面称为[Kass100a])，
已经提出了一种端系统结构，它把本地、对等体和网络资源预留集成到一个端对端QoS管理框架中，其中，用户首选项和适配路径和QoS状态一起被使用来协商应用层的QoS。与本地资源管理的相互作用被引入。分层结构为不同类型的应用提供支持。
三篇文献
-D.Mandato、A.Kassler、T.Robles、G.Neureiter的”Conceptsfor Service Adaptation，Scalability and QoS Handling onMobility-Enabled Networks”(移动性启用的网络上的服务适配、可量测性以及QoS处理的概念)(IST全球最高级会议2001，巴赛罗那，2001年9月，第285-293页)(在下面称为[Manda00])，
-D.Mandato、A.Kassler、T.Robles和G.Neureiter的”HandlingEnd-to-End QoS in Mobile Heterogeneous NetworkingEnvironments”(处理移动异构联网环境中的端对端QoS)(PIMRC2001，圣地亚哥，30/9/2001到3/10/2001，第C-49-C-54页)(在下面称为[Manda00a])，以及
-G.Camarillo等人的”Grouping of Media Lines in SDP”(SDP中的媒体线路分组)(IETF互联网草案，未完工程，<draft-ietf-mmusic-fid-04.txt>)(在下面称为[Cama01])，
讨论了不考虑编组准则而对媒体流进行编组的可能性，递归组建立(许多归组的一组)的可能性、以及也可能被编组的实时、伪实时以及非实时信息媒体流的处理。此外，[Manda00]和[Manda00a]定义了协商步骤，其可以一次(at one shot)但不是独立阶段地运行或不运行，并且在协商阶段期间以及在协商之后对协商的QoS信息的一致性没有要求。因此，在[Manda00]中，E2ENP的核心概念被披露。抵触”经济原理”应用的处理也未被考虑。此外，[Manda00]和[Manda00a]描述了为QoS适配设置并管理适配路径的可能性，它由第三方组件(QoS代理)来控制。端方执行并控制有关它们自己的协商的可能性未被考虑。
在L.Bos等人的”A Framework for End-to-End user PerceivedQuality of Service negotiation”(端对端用户感知的服务质量协商框架)(IETF互联网草案，未完工程，<draft-bos-mmusic-sdpqos-framework-00.txt>)(在下面称为[Bos01])中，描述了一种端对端用户感知的QoS协商，假定一些中间组件和服务可以坚固地被包含在关于协商的端对等体QoS信息的端决定中。所述决定可以被一些标准”合同类型”接替。虽然提到信令和数据路径可以走不同的路线通过网络，但是有人认为在协商路径路线上的一些中间组件可能影响协商，虽然常规时候却与数据路径毫不相关。由于此协议模型，网络不是透明的。根据[Bos01]的协商过程被一次(at one shot)执行，也与一些非QoS信息(例如安全性，网络许可进入等等)交织，有关QoS的协议模块化以及信息一致性未被考虑。利用[Bos01]的模型，只可能使用协商的推(push)模式，对于一些应用和业务，它可能是受限制的。适配路径只是恶化的(″恶化路径”)并且是固定的。(没有可能在商定的QoS合同之间执行不同的转移。)[Bos01]的模型只建议了在媒体流层上QoS协商，而没有考虑一些媒体流相关性，比如组以及媒体流分层结构之类的。
在A.Bergsten、K.Nemeth、I.Cselenyi和G.Feher的”Fundamental Questions Regarding End-to-End QoS”(关于端对端QoS的基础问题)(未完工程，<draft-bergsten-e2eqos-questions-00.txt>)(在下面称为[Berg01])中，建议了一个关键问题列表(实际上，实际的要求)。更明确地，”1)与QoS相关的信息的交换；以及2)与QoS相关的决定的强制实施”被表示为”所需要的增强，以便提供可预测的端对端QoS”。E2ENP符合这两个要求，在此范围，它
-定义了一个处理第一个要求的应用层协议，并且
-按照经济原理来强制实施资源管理。
更明确地，关于第二个要求，E2ENP假定存在[BRAIN]和[Roble01]中描述的扩展套接字接口(ESI)，其中，向各种应用隐藏网络资源管理的细节。这意味着ESI提供一种抽象层，在其上可以建造感知QoS的媒件和应用。可是，ESI应该不可用，E2ENP假定应用和/或媒件将能够从高级QoS合同中导出网络层别的QoS合同，而且使用低级别的监视信息用于触发应用和/或媒件QoS适配机制。
更明确地，在[Berg01]中，提及了如下五点：
1.”接入网：拥塞概率是接入网中的最高值，因此，或许在这里需要提供QoS信息的某种机制。”这就是在[BRAIN]、[Roble01]中做出的假设(E2ENP的原始概念从中起源)，其中，ESI抽象允许应用和/或媒件(平衡E2ENP)不但常规使用任何种类的可用网络系统结构，而且(更特别地)关于接入网做出一个类似的假设。
2.”在应用之间的端对端信令：将假定在一些情况下，QoS会话启动首先必须是一个高级信息交换。”
这就是E2ENP目标要求之一。另外，E2ENP处理备选QoS合同以及更高级QoS合同的前摄的预先协商。E2ENP更进一步另外提供用于处理再协商的全吹(full-blown)程序组。
3.”域间通信，特别是在对等链路上的域间通信：需要一个自动服务通知，像是BGP那样的，但是具有QoS增强。另外，考虑要有一个机制，它实际上提供这些资源的域间供应。”E2ENP是一个纯端对端应用层协议，其中，只有对等体(以及最终一些中间组件，就像会议桥路或者变码器)被直接包括。由于ESI或者等价的抽象，处理域内和/或域间网络资源管理和路由的较低级功能对E2ENP来说被隐藏了起来。这意味着E2ENP是一种纯应用层协议，其对等体可以使用来通过任何网络体系结构来通信。
4.”在网络拥塞的情况下，识别哪一用户恶化：当一个中断拥塞发生并且合同不得不被违反时，应该受控制于网络。”E2ENP与此要求兼容，因为E2ENP假定QoS妨碍的检测由基础网络体系结构来执行。
5.”为用户提供需求信息：用户能够通知服务提供者有关当前的以及有意的网络利用，规定例如期望的目的地以及业务量。运营商能因此使用此消息来更好地规划它的网络，并且还使用此消息来计算从附近运营商中购买的服务数量。”这就是在[BRAIN]和[Roble01]中做出的假设，E2ENP的原始概念从中起源。更明确地，用户不但能够就与网络提供者预先协商的应用层QoS合同方面提供″当前的以及有意的网络利用，规定例如期望的目的地和业务量”(在如下所述的过程期间)，而且能够与备选QoS合同的对等体组(AP)并且以不同的抽象层来进行交换，以考虑媒体流间的关系(AP也同样)。
最后，在[Berg01]中，描述了在任何会话建立之前，使对等体关于服务质量类型以及价格信息而与它们的网络提供者相符的需要。这类似于如上所述的过程，在此，用户规定应用层QoS信息，其依靠与网络提供者的预先配置或者经由与后者的直接通信而最终映射到确认的网络层QoS合同。这些低级过程如何在E2ENP范围中完成，这幸亏ESI抽象(或者类似的功能)。
三篇文献
-H.Khartabil的”Conferencing Using SIP”(使用SIP的会议)(IETF互联网草案，未完工程，<draft-khartabil-sip-conferencing-00.txt>)(在下面称为[Khart01])，
-J.Rosenberg和H.Schulzrinne的”Models for Multi-partyConferencing in SIP”(SIP中多方会议的模型)(IETF SIPPING工作组，未完工程，<draft-rosenberg-sip-conferencing-models-01.txt>)(在下面称为[Rosen01])，和
-J.Rosenberg和H.Schulzrinne的”Models for Multi-partyConferencing in SIP”(SIP中多方会议的模型)(IETF SIPPING工作组，未完工程，<draft-ietf-sipping-conferencing-models-00.txt>)(在下面称为[Rosen00a])，
介绍了多方会议模型，其考虑了类似一对多以及多对多连接那样的方案。所述模型利用了使用会议服务器的集中体系结构的优势。在这种情况下，在端对等体之间没有直接端对端通信并且E2ENP应用可以以好几个不同的方式被执行。
-在端对等体之间的直接信令，通过会议服务器上的数据路径；
-通过会议服务器在端对等体之间的间接信令，在端对等体之间的直接数据连接；和
-通过会议服务器以及通过会议服务器的数据路径在端对等体之间的间接信令。
E2ENP的这些应用对于每一不同的方案可能需要不同的消息序列以及E2ENP结构。[Khart01]、[Rosen01]以及[Rosen00a]的模型主要涉及使用集中组件的会议方案的消息序列的描述。如果E2ENP也被应用到这些方案的话，由于必需的能力和/或QoS协商以及分别的预留，则这些序列可能会受到改变。在具有某些集中组件的方案中，E2ENP应用的优点是：通信模型可以减少到一对多的方案。
在下面将给出本发明的权利要求书和说明书的定义所需要的若干术语。
-适配路径：表示用户特定的首选项和希望的有序QoS合同组，其可以被用来允许应用和/或媒件按照预先计划的方式获得适配策略。通常，最重要的QoS合同(即，默认时系统将努力强制实施的那个)是在路径中指示的第一个。另外，AP可以包括规则规范，其定义系统将强制实施给定合同组之外的另一个QoS合同的情况。
-关联：与一个给定对等体相关的一组媒体流。由于媒体流编组的子情况，一个关联把发源于和/或终止在给定用户终端设备上的所有媒体流编组，并连接到给定会话内的一个给定对等体。因此，关联的规范将包括对等体的一个标识符(例如一个URL，一个电话号码，或者一对IP地址和端口号)
-应答者：应答者是SIP会话的一个参与者，它向提议者(参见下面)建议的多媒体会话描述产生一个响应。响应包含可以提供提议者所建议的会话描述的情形描述。[SDPOA00]
-关联或组适配路径：作为适配路径而被模拟的，备选关联或组配置，以及它们的QoS环境以及流级别(stream-level)QoS合同，可以被用于允许应用和/或媒件以预先计划的方式来产生适配策略。
-能力：与终端设备的硬件和/或软件配置文件相关，能力描述了此设备执行某些任务和/或处理某些信息类型的能力。单个能力可以与某些的数量硬件和/或软件资源(每一个处理一种给定的信息类型)相关。与给定单个类型的信息相关的能力可用于以一个或多个QoS级别来呈现此信息。另一方面，一个给定QoS级别能够与不同的能力组相关(例如不同的编解码器可以产生完全一样QoS级别，就象从该应用中看到的一样)。
-连接模式：连接模式是指对等体交换的实际数据媒体流。此信息是端用户可直接知觉的媒体(音频，视频等等)。连接模式陈述了媒体流各方谁是发送者以及谁是接收者。
-数据路径：媒体数据(音频、视频、文本等等)所采用的网络路径。
-经济原理：经济原理指示资源预留顺序。由于网络资源被共享并且因此比终端资源更昂贵，因此最好首先预留有关所有终端的资源然后继续进行网络资源预留。
-端对端QoS预先协商：是在一个会话实际开始之前，端对等体能够与会话本身无关地执行的一个过程，用于以一种非强迫的方式交换从它们的QoS配置文件中推断出的有关QoS规范配置的信息。这些配置包括适配路径，因此端对等体能够预先积极地商定这种方式以便以一种有效且有效率的方式对可能的QoS变化或QoS妨碍作出反应。预先协商消息交换具有端对等体的信息字符，并且不但被用来在前面彼此通知关于适用于给定对等体组的能力和执行可能性，而且被用来对重新定义那些配置中的一些达成一致意见。用这种方式，对等体因此能够建立一个公共词汇，任何特定业务的一个先验。此过程的结果在时间上被划定范围，并且在它们的有效间隔内能被使用多次。
-端对端QoS简洁协商：在一个会话实际开始之前或者实际开始时，端对等体能够执行的一种过程，以便基于预先应用的端对端QoS预先协商过程的结果，对于给定的会话和媒体流商定一个要被强制实施的给定QoS级别(假定那些结果的有效性在此过程运行期间仍然适用)。此过程与端对端QoS完全协商的情况相比快相当多，因为在对等体之中实际上只交换预先协商的信息首选项。在端对端QoS简洁协商过程完成时，端对等体已经商定它们通信将使用的QoS配置文件。
-端对端QoS完全协商：在一个会话实际开始之前或者实际开始时，端对等体能够执行的一个过程，以便通过重新定义QoS规范最初建议的配置中的一些，来最终对于给定的会话和媒体流商定要强制实施的一个给定QoS级别。在端对端QoS完全协商过程完成时，端对等体已经商定它们通信将使用的QoS配置文件。
-端对端QoS简洁再协商：在检测到QoS变化或者QoS妨碍之后，端对等体能够启动的一个过程，以便基于预先应用的端对端QoS预先协商过程的结果，对于给定的会话和媒体流商定一个要被强制实施的给定QoS级别(假定那些结果的有效度在此过程运行期间仍然适用)。此过程与端对端QoS完全再协商的情况相比快相当多，因为在对等体之中实际上只交换预先协商的信息的参考。在端对端QoS简洁再协商过程完成时，端对等体已经商定它们通信将使用的新的QoS配置文件。
-端对端QoS完全再协商：在检测到一个QoS变化或者QoS妨碍之后，端对等体能够启动的一个过程，以便通过重新定义QoS规范最初建议的配置中的一些，来最终对于给定的会话和媒体流商定要强制实施的一个给定QoS级别。在端对端QoS完全再协商过程完成时，端对等体已经商定它们通信将使用的新的QoS配置文件。
-流：一个流是在某些时间间隔期间通过网络中的一个观测点的一组分组。属于一个特定流的所有分组在观测点处具有从包含在分组中的数据中以及从分组处理中导出的一组公共性质，如J.Quittek等人的”Requirements for IP Flow Information Export”(IP流信息出口的要求)(参见<draft-ietf-ipfix-reqs-00.txt>)(在下面称为[Quit00])中所述。作为一个示例，一个给定流的所有分组将具有相同的5元组(协议ID，源网络地址，目的地网络地址，源端口号，目的地端口号)。简单的媒体流(即没有多路复用层的那些)以及层获得对传输层上的流的映射，在那儿，它们被用于预留。一个流能够携带一个给定媒体流的一层，或者整个一个给定的简单媒体流。
-媒体流组：为了强制实施一些限制，基于各种准则对媒体流进行逻辑编组，例如编组所有的音频媒体流用于强制实施转换，编组在多用户终端上被一个给定用户开放的所有媒体流以便强制实施配额。一个组也可以只包括一个媒体流。各个组主要用于表示媒体流束，在一个给定的环境条件组中的多个等价束之中，当协调质量与资源可用性时，感知QoS的应用能够作为整体处理之。每个组与一个QoS环境相关。
-中间组件：中间组件是位于两个端设备(终端)之间的信令和/或数据路径上的任何网络元件，其能够了解端设备至少在网络层上使用的通行(through-coming)协议。中间组件可以是路由器，代理，独立的服务，代理的一部分等等。中间组件构造端对等体之间的网络。
-层：媒体流能够被编码到多个层中，在此，每一层递增地增强与给定基础信息(由所谓的”基础层”携带的)相对的细节级别。这意味着增加的层可以进一步增加基础信息的细节的级别。每一层能够被映射到一个给定流。
-协商模式：协商模式是指由对等体使用来用于交换有关管理和数据媒体流控制的信息的信号路径和协商信息。协商模式陈述了协商各方谁是提议者以及谁是应答者。
-仲裁者：仲裁者是一个功能，对等体用此种促进功能根据各个对等体的用户和/或服务提供者的一些配置文件的预先设定，来把呼入呼叫重新定向到一个或多个对等体。
-提议者：提议者是SIP会话的参与者，它生成提议者希望通过进行多媒体会话而使用的多媒体会话描述。此描述被传送给应答者(参见上面)。
-[SDPOA00]对等体：与终端用户相关的服务或端设备。
-服务质量(QoS)：服务执行的集体效果，它按照来自ITU-T(前身CCITT)建议E.800中的定义来确定用户对服务的满意程度。从而，对于每个服务，可以用表征该服务的一组参数来描述QoS。作为一个示例，对于一个电视会议服务，QoS可以被定义为端用户观测到的整个端对端QoS，它可以通过类似帧速率、视觉质量以及延迟那样的参数来测量。
-QoS变化：由服务用户发出的QoS合同变化。
-QoS环境：一个QoS环境识别在一个给定媒体流组各处应该实施的QoS参数布置。一个QoS环境是一个逻辑实体，它被模拟成为QoS合同概念的专门化。
-QoS合同：在用户和给定服务提供者之间的协议，规定QoS要求和限制，以及在所述服务的所有阶段期间跟踪QoS所需的策略。QoS合同归纳了媒体流层QoS合同以及更高级合同的概念，所谓的QoS环境。这意味着能够在一个分级结构中组织QoS合同。
-QoS合同类型：通过识别单独的QoS合同如何规定在一个给定QoS参数类型组上的QoS性质，捕获QoS合同的类别构造，在S.Frolund和J.Koistinien的”QML：A Language for Quality ofService Specification”(QML：服务质量规范的语言)(惠普实验室技术报告，HPL-98-10，980210)(在下面称为[Frolu98])中也称为尺度。每个参数类型由一个名称和一个数值域组成。QoS规范可以只不过是用作所述域上的一组限制，每一参数类型一个。
-QoS级别：数据的多维QoS空间，其特征在于：业务能够被划分成为多个离散子空间。一个给定的子空间被表示为QoS级别并且将可被服务用户与另一QoS级别相区别。一个QoS合同描述了一种特定的QoS级别并且在再协商发生的情况下被用来实施这种级别。换言之，用户把QoS级别理解为把某些QoS合同应用到给定服务的结果。可是，这里可能有QoS空间的一些正常的、特定应用的或者特定业务的预定义分区，其中：用户能因此把他们自己的QoS合同的QoS级别(属于给定分区)映射到各种范围(一对一、相交、不同粒度等等)。
-QoS参数：QoS参数是一个给定服务的单个特性的功能性表示(作为一个示例，整个端对端延迟)。
-遵循在”Information Technology-Quality of Service：Framework”(信息技术-服务质量：框架)(ITU-T建议X.641，12/97，ISO/IEC 13236：1998)(在下面称为[ISOX641])中提出的定义，QoS参数(在国际标准术语中为QoS特性)识别与可测量QoS相关的数量，并且可以进一步被区分为普通、专门，并且衍生如下：
◆普通的QoS参数努力捕获一个公共基础QoS参数，其能够被应用到任何特定的环境，因此与它所应用到什么上无关。
◆专门的QoS参数是普通QoS特性的具体情况(最后，普通的QoS特性可以是充分具体而被使用，但是在大部分情况中，为了捕获系统或者网络特定的特性，而要求专门化)。例如，一个普通的时延QoS特性可以被进一步专门化，以使得反映系统实施特定的问题。通过以适当的抽象层来映射QoS特性，专门化方法很适合于处理复杂的分布式系统。
◆导出的QoS参数基于数学关系来捕获QoS特性之间的相关性。一些导出的QoS特性甚至可以是实际上统计的值(例如最大值，最小值，范围，平均值，方差以及标准偏差，n百分比，统计瞬时等等)。甚至导出的QoS参数能够被专门化为更类似普通的。因此，专门化以及推导可以被认为是QoS特性的正交变换。可是，应当指出：推导可以包括一个普通/导出/专门化的QoS特性(例如有效性是可靠性和可维护性的函数)。
-QoS配置文件：关于一个给定业务的使用，就QoS方面规定终端用户首选项的数据集合。QoS配置文件可以被储存在用户的终端设备上，或者被储存在特定的数据库中。
-QoS规范：用于识别由用户为给定业务规定的QoS参数和限制设置的常规术语。
-QoS妨碍：由服务提供者引起的QoS妨碍。
-会话：在两个或更多对等体(用户端设备或者服务器)之间的一组持久连接，通常包括对等体之中”相关信息”(会话信息涉及某一个话题)的许多分组的交换。按照M.Handley和V.Jacobson的”SDP：SessionDescription Protocol”(SDP：会话描述协议)(IETF Request forComments：2327，1998年4月)(在下面称为[Hand198])，多媒体会话是”一组多媒体发送者和接收者以及从发送者流到接收者的数据媒体流。多媒体会议是多媒体会话的示例”。在这里，相对于它们的环境来认识两种类型的会话：
◆媒体会话-媒体会话具有在对等体之间传送用户可感知数据的环境。
◆信令会话-信令会话具有通常端用户不可见的媒体会话设定和固定的协商环境。SIP、SCCP等等可用于执行一个信令会话。信令会话对于应用可见，并且只有当应用需要一些用户涉及或者用户事件产生(例如弹出一个GUI窗口，要求按下一个或多个虚拟按键)时，可以变成对于用户可见。
应当指出：一些协议(例如实时转送协议，RTP)既能够携带媒体数据又能够携带媒体描述，因此并行执行媒体转移和信令。
-信令路径：SIP消息所采用的网络路径。
-媒体流：在应用层，在两个对等体之间信息的连续单向交换。不同类型的媒体流可以存在：音频、视频、数据、文本或者它们的任何组合。一个给定方可以担当一个纯媒体流信源(这专门发送信息)，担当一个纯媒体流信宿(这收集来自对方(例如视频点播业务)的媒体流信息)，或者担当媒体流信源和媒体流信宿(这是诸如电视会议服务之类的传统模式的典型)。一个媒体流能够被映射到一个或多个流。
在如下部分中，将描述不同的可能通信方案，它们可以发生在多媒体环境中，并且将受益于端对端QoS协商协议(E2ENP)的使用。
该部分首先介绍每一方的关键定义以及通信所考虑的组件，以及它们构造来形成通信体系结构的那些结构。
所述体系结构与某些特定的服务相关。考虑不同的通信模式，参与者使用所述不同的通信模式用于协商QoS。为了定义使用情况，考虑如下各个方面：
·通信方是谁，
·连接的始发者是谁，
·在一个特定的通信方案中多少通信方参与，
·所述通信方建立哪一种结构，以及
·哪一种连接模式(单播或多播)被应用。
最后提供一些示例来示出那些方案的工作思想。
端系统通信方-提议者和应答者-是任何端对端协商的工作组件。
按照上面提出的定义，提议者和应答者是对等体：提议者是启动连接协商过程的一方。应答者是提议者联系的那些方，提议者希望与之建立连接。各方可以在实际通信中扮演一个主动角色——发送者(即发送或发送/接收媒体流)，或者扮演一个被动角色——接收者(即，接收媒体流)。
另一类型的通信方是中间组件。这些组件就各种程度的复杂性方面可以不同，并且能够被使用在不同级别的网络连接上。中间组件可以是网络内的所有设备(代理，路由器等等)和服务(例如命名，分配，存在等等)。中间组件在这种情况下只是被动的操作器，只支持在端对等体之间的连接建立，而不妨碍它们之间的协商过程。E2ENP的假设是：没有中间组件参与到协商过程，而是，它们可能在协商已经发生之前或者之后影响一些协商的信息。那就是为什么必须关于它们对协商信息的功能和影响而考虑中间组件。
通过建立一个连接，重要的是陈述：
1.协商模式描述了交换能力和QoS合同信息的序列，以及哪一方首先发送它的合同。就此而言，下列模式被区分：
a.当提议者向应答者发出一个关于应该如何做出连接设定的提议并且在前面声明它的能力和QoS希望时，使用推(push)模式。可以利用一对一的电话--像IP上的语音(VoIP)通信来使用推模式。
b.当提议者呼叫应答者而没有声明有关连接设定的希望时使用拉(pull)模式。提议者重现来自应答者的这个信息并在接收到的配置文件上适配它的希望。当中央对等体(“VoD服务器”或演讲者)预定义配置文件被使用时，这个模式能被用于不同的服务，类似”视频点播”或者”虚拟演讲”。
c.在一些情况中，每当提议者不但向应答者做出了关于连接设定的提议，而且同时重现了应答者的设定时，可能需要使用推拉(push-pull)模式。
2.连接模式：是有关如下内容的消息：即，通过开始一个协商，哪一对等体是发送者、哪一对等体是来建立服务的接收者，哪一协商模式(推/拉)更适合使用。
3.连接工作(特别在一个以上参与者的情况下)
a.对一组接收者的多播，
b.对每一接收方的单播。
4.通信方数量是用于确定哪一协商模式(推/拉)更适合使用以及协商子过程将以什么序列发生所需要的信息。通信方可以形成如下连接结构：
a.一对一：这可以是双方之间的通话情况。典型服务示例在这里是VoIP(参见下面的示例)。
b.一对多：这是VoD服务或在线演讲的情况(参见下面的示例)。
c.多对多：一个典型示例在这里是虚拟会议(参见下面的示例)。
在如下部分中，一些通信方案示例将被描述以便更好地认识协商协议的需求。因为非常简单的对等(一对一)通信在文献[SDPOA00]中早已被彻底讨论过，所以如下方案考虑更复杂的通信模型。那些方案描述了动态通信以及多方连接可能发生的一些典型情形。关于移动网的设备和人的移动性的影响被示出。可能的信息相关性的一些思想以及描述此的方式被介绍。那些示例示出了多方通信的一些方面，其中，使用作为被动通信方的中间组件可以被包括。
图1中描述的示例示出了在一对一通信方案100的电信会话102的交换情形中的一个呼叫再分配108，所述一对一通信方案100呈现了能够安排未来类似电话通信的思想。包含在所述方案中的两个用户104a+b将被称为Mary和Kate。
Mary在她互联网启用的手表106a1上接收来自她朋友Kate的一个呼叫，Kate想要告诉关于她新男朋友的信息。该呼叫携带一则表示”who is calling”(谁在呼叫)(呼叫者的标识)以及”what the callis all about”(该呼叫关于什么)(主题信息)的消息。Mary的手表106a1不能够显示接收到的高分辨率图片112，因为它的显示器相当小而且是单色的，因此它自动开始搜索能执行那操作的设备106a2。它连接到家庭中央服务器并察出Mary的配置文件表示她被授权使用她房间中的一个灵巧终端设备106a2。手表106a1联系”room”设备106a2(房间设备106a2)用于再分配会话103并通知Mary在她的”room”设备106a2中有一则呼叫110在等她。由于这个原因，Mary移到她的房间接电话110。同时，Kate知道Mary已经接受她的呼叫110但是需要一段时间再分配108程序108。此信息然后被一个适当的协议转发。她也已知Mary将能够在一个视频启用的终端设备106a2上接受呼叫110，因此她们将能够交换图片。
一旦在她的房间内，Mary就能够使用她的灵巧终端设备106a2来与她的朋友谈话。
Mary：”Hi，Kate！Well，you have a new boyfriend？”(嗨，Kate！你有新男朋友了？)
Kate：”Hi，I have also some great pictures of him.″(嗨，我还有他的一些不错的图片呢。)
(最后，Kate会发送一些数字化高分辨率图片112给Mary，甚至她喜欢的摇滚乐团的一些视频短片。)
此方案涉及个人区域网604(PAN)的情况，其中，第三方协助的能力和QoS的协商806需要在端对端基础上被实现。这意味着Mary的手表106a1应当能够代表最新发现的智能设备106a2协商(代理机制)。
可替代地，可以由Mary的”room”设备106a2直接执行与Kate的终端设备106b的协商806过程：在这种情况下，再分配机制108将把完整的连接建立处理完全切换到新的设备106a2(重新定向机制)。
作为此方案100的子情况，当然也可能根本不需要再布置108，其中，由Mary的手表106a1直接执行与Kate的终端设备106b的协商806过程。这种子情况对应于如[SDPOA00]中所述的非常简单的一对一通信。这种情况与信令协议的协商阶段一起如图8所示。
图2中描述的示例示出了在一对多通信方案情形中的一则虚拟演讲，其中，一个演讲者202(T.Martin教授)和三个学生204a-c(A，B和C)被包括。从而，假定教授T.Martin正在出席在罗马的一个会议，并同时他还应该安排他在柏林大学的正常演讲。他已经向他的学生A、B和C安排他将通过利用会议时间表中的空闲时间来在线演讲，并且因此已经宣布会话102将在下午2:00开始。就此而言，教授T.Martin已经把他旅馆房间的计算机配置为支持与他学生的设备相应的多个不同的发送配置文件。在下午1:00，他的PDA通知他，第一个学生已经启动一个协商806(或809)，用于打开与他的旅馆房间中他的计算机的一则连接会话102。教授T.Martin回到他的房间，并且在下午1:55，他在最后开始演讲会话之前巡视参与者A、B和C的表检查。演讲连接携带学院重要的识别信息，那就是为什么不收费或者费用被记入一个大学帐户上。
这个示例描述了一对多通信方案200的情况。此类通信也等价于”视频点播”(VoD)服务的情况，主要区别是：在上面描述的示例中，传输是实况播送的而不是象VoD情况中那样是预先记录的。因此，在目前示例中的每个接收者A、B和C将只能够(名义上地)在同一时间接收相同的信息。
图3中描述的如下示例可以作为多对多通信方案300中的电视会议1204a/b的一种简单形式来对待，其中，四个用户302a-d(Caroline，Martha，Miranda和秘书)被包括。
假定Caroline和Martha是洛杉矶的一个时尚设计公司的员工。他们在与他们的法国同事Miranda进行关于一个新的征集的联合计划工作。每一周，女士们302a-c在征集进展的当前状态上进行电视会议1204a/b。Caroline和Martha把他们的设计发送给Miranda，用于检查和批准。因为Miranda经常出差，没有足够时间为她的老板写很好的报告，因此她已经授权她的秘书安排她的模型复查以便为老板准备一个展示。当会议最终发生时，Miranda、Caroline和Martha可以开始交换音频与视频内容以及图像和文本信息。同时，秘书302d在线收听并对会议以及Miranda的谈论作纪录。
这个方案300处理发源于不同信源中的信息情况。这是一组相关信息媒体流206的情况，其中，用户可能需要交换的媒体流206中的相关性804(例如在秘书端点)。
图4中描述的如下示例和多对多通信方案400有关，它示出了一个复杂的电视会议1204a/b方案，其中包括四个用户402a-d(Susanne Jones，两个主考者以及Jones先生)。
因此，将假定Susanne Jones正在进行一个公共开放的PhD预测验，并且通过给她爸爸一个会话连接密钥用于作为接收者404d加入检查会话102，她已经邀请她爸爸被动地参与她的在线考试会话102。她正在进行一个在线陈述，其被多播到她的管理者404b+c以及一组听众。在Susanne的终端404a和管理者终端404b+c之间做出会话102的初始配置，因为管理者402b+c在线交换有关该陈述的笔记以便能够为她的实际测验而引导Susanne并且指出这个陈述的正面和负面。评论被直接写在该陈述页面上或者写在一个公共白板上。笔记与进行的陈述结合并且初始配置定义此对应(相关性804)。
当初始配置符合时，测验开始。接收者402d和其它听众可以在稍后的瞬时加入，因为他们作为主动参与者不妨碍运行的测验。加入会话102的任何听众可以获得有关该陈述的当前级的信息。Susanne爸爸的终端404d加入会话102，标记为获得她的PhD管理者402b+c给出的陈述本身以及等级。终端404d按照与Susanne爸爸的希望相应的预置配置文件来与Susanne的终端404a以及管理者402b+c的终端404b+c进行相应的配置，因此他加入该陈述多播并获得象单播一样的等级。
对于所述方案400的一个适当的进程，需要有这样一个概念：如何对单个媒体流206进行编组并且运行的媒体流206的感兴趣各方是谁。在这种方案中，重要的是：定义一个会话102中的参与者的组以及媒体流206的组。也可形成通信的分层编组结构。
这个方案400也说明了有时不但实时业务应该作为高优先级业务来对待，而且非实时业务也应该作为高优先级业务来对待：例如，为外国参与者带有该测验实况翻译字幕的媒体流206不得不被认为是伪实时的，在此范围，好像它不与内容同步--或者根本未获得递送--，则它将毫无用处。在这种情况下，非实时业务(字幕)与实时业务(实况视频)的给定等级相关。
所述方案400还可以被应用到网络604游戏以及与一些工作组的在线会议。考虑到这种方案400的复杂性，可能需要或者不需要确定多方连接的预先配置以及规划。
图5中描述的示例展现了多方通信的另外一些方面以及协商806(或者809)的开始，其中所述多方通信还考虑了提供通信各方和服务的发现的一些服务的使用。从而，两个移动用户508a+b(R.Harris医生和他的助手A.Frank先生)被包含在所述方案中。
在这个示例中，将假定Harris医生从法兰克福旅行到巴黎，并必须参与他的法国同仁关于巴黎一个病人的脑部手术操作的一个电视会议1204a/b。他的同仁将向他在线发送病人的当前监控信息。他们还讨论关于手术操作以便能够在Harris医生到达巴黎的医院后就开始。当Harris医生进入火车502时，他把他的终端无线地插入火车局域网中。火车服务器现在通知，Harris医生出现在火车局域网内。Frank先生在斯特拉斯堡上火车502。进入火车502，他也把他的终端无线插入火车局域网上并因此发现他的老板已经在所述火车502的另一车厢里。(假定火车已经被完全售票完毕，因此Frank先生没机会预定Harris医生旁边的坐位。)Frank先生也发出一个呼叫以便加入这次运行的会议。从而，Harris医生和Frank先生的终端构造一个“特设”(”ad-hoc”)网络604并使用Harris医生的终端作为对”外部世界”的连接，重新发射会议媒体流206给Frank先生的终端。
这个方案500是通过使用火车服务器作为发现服务的虚拟存在示例。但是也可用其它的中间服务或设备，类似命名和/或分配服务等等，或者类似代理或注册器之类的。在这种情况下，中间组件只支持端对等体之间的连接建立而不积极参与端对等体执行的协商808和809。
在如下部分中，将讨论关于如何处理多媒体应用中的QoS问题，所述多媒体应用处理多种类型和数目的并行媒体流206。根据下面发明所建议的解决方案的密钥方面，详细地介绍应用层QoS的预先协商802和分布式资源管理的调整，其中应用了所谓的”经济原理”。在本节中识别的需求被集中在一个需求列表中，它还包含关于所识别的需求中的相关性的信息。
移动用户在下一代IP网络604的环境和应用中将最可能面对的首要问题是：如何对付在端系统处以及网络604中有限的资源量以及不稳定的环境情形。因此，可以假定如下要求：

要求1：移动和/或固定终端的开发者和用户应当能够处理不稳定的环境情形，特别当强制实施QoS时。
多媒体会话102可以包含一些基础类型的媒体流206(即音频，视频和数据)。作为一个示例，对于一个给定用户的观点，一个会话102可以由从不同对等体中(甚至从四周方案中的一个对等体中)产生的两个视频媒体流206和四个音频媒体流206组成。给定用户然后将希望为每一单个媒体流206规定他想要获得的QoS，并且另外规定可以确定媒体流206间状态的任何参数。通常，视频会议1204a/b应用处理语音和视频媒体流206，它必须在最终终端处同步。非同步电视会议1204a/bs在某些方案中可能不是满意的。
另外，在时间和/或QoS基础上，在一些或者所有的前述媒体流206之间可能需要某些级别的相关性804。此相关性804构成时间同步805问题的推广。例如，电子游戏应用和/或媒体富有(media-rich)交互式应用可能表征为音频与视频媒体流206的束，这与被呈现给用户的对象相关。例如，一个移动和/或转动立方体可以把来自视频媒体流206中的图像组成它的各个表面显示在显示器上，而每一个都与一个立方体表面相关的不同音频媒体流206，每当相应表面被导向到某一个方向时就能够被播放。
就此而言，应用将能够不但确保在给定的临时关系内播放相关的媒体流206(绝对的时间同步)，而且确保给定媒体流束206的合并的QoS放置在某些给定限制内(QoS相关性804)。例如，就继续游戏应用示例，可能以黑白视频显示立方体的某些方面没什么感觉，并且其他方面以更高的帧速率作为高质量颜色视频，即使从一个绝对临时的观察来看图像完全同步。宁可更有意义地显示所有侧面，以最高可用帧速率显示黑白电影，因此避免资源无意义的消耗来获得彩色图像损害帧速率，所述帧速率是将显示所述图像的帧速率。
当然，在一组媒体流206之中在QoS级别应该强制实施什么级别相关性804的决定被留给开发者甚至留给用户考虑。
因此，多流应用可能除了需要媒体流206的组之间的定时关系规范之外，还需要QoS相关性804的规范。实际上，此区别不完全标识两个正交方面，因为时间同步可以被认为是QoS相关性804的一种特殊情况。在一个给定媒体流206构成若干相异的传输层流(例如由多层编解码器生成)的情况下，这些问题更加明显。要求2：处理多个媒体流206的多媒体应用的开发者和用户可以通过包括QoS相关性804和时间同步方面来加强他们的QoS规范。
应该注意：媒体流206的束不但与应用或者与用户相关，而且它还可以按照一个分层方案而被构造。
例如，在电视会议1204a/b应用中，能够有意义来区分不同组的(并因此相异地对待)媒体流206，使得识别电视会议1204a/b的多个同时发生的情况，以及在每个电视会议1204a/b会话102内给定用户与多个对等体的各种关联(每个关联是一束相关的媒体流206)。
此提议因此把多流时间同步805和QoS相关性804限制模拟为高级QoS合同1108，与受影响的媒体流206列表相关。此外，它允许把此类高级QoS合同1108在它们本身之中递归地成束，从而导致一种分层的QoS规范方案，即，与一棵树形等效。每个这样的叶片表示一个媒体流206并且有一个相关的QoS合同1108。起源节点与高级QoS合同1108相关，就多流方面为它们的子QoS级别规定时间同步805和QoS相关性804限制。
此外，用户可以向各种(多媒体)应用把不同资源量区分优先次序并许可。这对于具有有限资源(像[BRAIN]中所述的存储器、电池电源)的手持设备来说是特别重要的。此方法导致甚至更高级时间同步805和QoS相关性804限制，它们将被终端设备本地地强制实施。相应的高级QoS合同1108在根部扩展树形数据模型。可是，这种附加的高级QoS合同1108不意指与对等体协商。而是每个对等体可以独立地强制实施高级QoS合同1108。可替代地，一旦已经选定一个协调者，则能够遍及一个给定的闭合对等体组中整体地强制实施高级QoS合同1108。要求3：处理多个媒体流206的多媒体应用的开发者和用户应该以一种分层的方式构造他们的QoS规范。
一种对付QoS妨碍和QoS变化的可能方法是启用移动用户应用以便通过提前计划反作用来有效且及时地对那些事件作出反应。
按照这种方式，每当QoS妨碍出现时，有关如何最有效地适应变化情形的协定能够在对等体之中及时到达。
合并了这两个计划机制的整个解决方案因此被称为端对端协商协议908(E2ENP)(E2ENP 908)。要求4：E2ENP 908将包括用于提前计划适当反作用的机制和装置，另外应付由于QoS妨碍(例如切换)或QoS变化(例如当漫游时用户改变配置文件信息)引起的难以预料的事件。
分层QoS规范能够被增强，用于帮助应用决定它们在过载情形期间如何作出反应以便与用户希望相适应。
单个QoS级别的对等协商806实际上只在运行时间有意义，因为只有在运行时间，网络提供者可以被包含在第三方协助的协商806中(其中，根据[ISOX641]，行动者是始发者、提供者以及一个或多个响应者)。为了与使用于IETF共同体中的当前术语相合，在本发明范围中将使用如下命名规则：提议者914代替始发者，应答者911代替响应者。如果为了提供坚固的QoS保证而必须明确地预留网络资源时，则这是需要的。
可是，从QoS观点看，已经识别到需要加速移动多媒体业务的最关键阶段(不但包括会话和会议服务，而且包括信息检索，即，连接建立和切换)。这么，因为基础业务通常是延迟敏感的，并且异构和移动网604的使用可能暗示有限的带宽和网络604容量以及频繁的切换。因此所建议的该解决方案要适当地在前计划一组QoS级别以便应付当前的和未来的资源数量。
此外，通过把组中的每个元件与唯一标识符关联，每个组在QoS(重新)协商时间可以被快速并且唯一地参考。
此外，端应用和服务的特殊特征可能需要交换消息的不同协商806模式和不同顺序。
最后，应当指出：任何QoS信息从可用资源消息中导出。由于任何给定用户可知觉的质量可以通过使用不同的资源(例如编解码器)来达到，所以需要收集有关资源的信息以便能够相应地产生QoS合同(组)1108。此外，关于资源的信息也用于执行资源预留。要求5：E2ENP 908将包括用于快速并有效地执行QoS协商806和QoS再协商808的机制和装置。要求6：E2ENP 908将包括用于定义信息交换模式(推，拉，推拉)的机制和装置，因为对于不同的应用和服务，可能需要不同的协商806方案。要求7：E2ENP 908将处理从关于可用资源(例如编解码器)的消息中导出的QoS信息。要求8：E2ENP 908将包括用于规定并预先协商多个备选QoS级别的机制和装置。要求9：每个QoS级别将被一个特定的QoS合同1108描述。要求10：E2ENP 908将包括用于在QoS协商806和QoS再协商808期间唯一地参考每个预先可协商的QoS级别以便保持信令最小的机制和装置。
移动用户需要把他们移动终端点对网络604的附加进行改变同时保持旧的网络604地址并且保持任何主动的电信会话102的能力，三种可能的事件类型可能出现(切换)。
假定给定用户通常与一个特定网络提供者有业务关系(例如与ISP的预订或者与电信运营商的预付费卡)，三种可能的切换类型可能发生：
-水平切换：切换发生在网络提供者的给定管理区域内，并且在同一类型接入网604内。
-垂直切换：该切换发生在两种不同类型的接入网604之间和/或通过了两个网络供应者之间的管理边界。
当处理切换时，用户必须准备面对网络资源可用性的改变，不但取决于所接入的接入网604类型，而且取决于用户可以与接入的各个网络604运营商具有的业务关系的类型。在极端情况中，用户实际上可能尝试接入由网络604运营商拥有的网络604，用户与之根本没有业务关系，或者它可能限制用户的接入或限制预分配给所述用户的资源数量。价格方面也扮演一个关键角色。
所有这些意味着每当切换发生时用户必须准备体验严重的QoS妨碍，而且每当在用户接入具有更多资源和/或更少限制的网络604时的此类切换期间，有利地平衡任何可能的改善。要求11：E2ENP 908将假定，对比他们优选的网络提供者实际上能够提供的QoS级别，用户将已经预防性地确认他们优选的备选QoS级别。
接着前一段落中提出的基本原理，对等体能够管理来不但商定一个给定QoS合同1108，而且商定备选的一个，每当网络604和/或终端资源可用性随时间变化时，其能够被有利使用。
按照这样一种方式，每个对等体将精确地知道哪一备选QoS合同1108(和在什么情形之下)将被强制实施以便应付关于当前启用的QoS合同1108的一个关键的QoS变化或者应付任何QoS妨碍。
适配路径的概念规定了除了标准的一个之外的备选QoS合同1108的规范，以及表示在哪一环境上将强制实施哪一备选QoS合同1108的一组规则。备选QoS合同1108通常描述与标准的QoS合同1108规定的相比更低级别的QoS。更明确地，对应于由整个媒件监视的定义明确的QoS改变和/或妨碍组，适配策略将识别标准QoS合同1108对一组候选被降级的QoS规范(即较低级别的QoS)的定义明确的适配，正如J.P.Loyall等人的”QoS Aspect Languages and theirRuntime Integration”(QoS方面语言及其运行时间集成)(注：计算机科学演讲笔记，第1511卷，Springer-Verlag)(在下面称为[Loyal])中所述。
在本基础发明的范围中，在[BRAIN]中表示的术语被应用，其中使用适配路径(AP)来代替恶化路径以便突出实际上也能够使用适配来提高一个给定的质量，在稍后时刻(例如在切换的情况下)更多资源将变得可用。要求12：E2ENP 908将允许用户预先定义适配路径。要求13：一条适配路径的每个元件将是一个QoS合同1108。要求14：在每个给定会话102中的每一单个媒体流206将与一个给定的QoS合同1108相关。要求15：每个QoS合同1108将与一个唯一标识符相关。要求16：E2ENP 908将强制实施规定和预先协商在任何给定适配路径之外的一个选定QoS合同1108，作为开始媒体流时应用(组)将使用的缺省QoS合同1108。要求17：另外，适配路径能够包括规则规范，其定义应用和/或媒件将强制实施它的给定组之外的另一个QoS合同的情况。要求18：E2ENP 908将包括用于在媒体流206级别上规定AP的机制和装置。
通过在前述分层的QoS规范的任何级别处应用AP，通过包括时间同步和QoS相关性804规范，能够进一步改善适配过程。
在此模型中，每个备选时间同步和QoS相关性804规范与一个特定的QoS合同1108相关。
以一种分层的格式来构造使得捕获各个相关性804方面的备选QoS合同1108的使用，实际上允许对等体先验地商定(在预先协商802时刻)一个公共的、构成的”QoS词汇”，而不需要在预先协商802过程期间网络提供者的干预。
就此而言，每当参与端对端预先协商802过程时，对等体可以有利地使用在预订时间与网络提供者预先协商的配置文件信息。在漫游的情况下，网络提供者能够(经由服务级别协议)预作安排，当用户访问新的网络区域时，用户配置文件信息仍然(完全地或者部分地)保存。
基于各种准则，QoS相关性804和/或时间同步805限制的强制实施暗示媒体流206的逻辑编组。例如：
·编组所有的音频媒体流206，用于强制实施同步翻译；
·在多用户终端上把一个给定用户打开的所有的媒体流206进行编组以便强制实施配额。
一组媒体流206最终能够只包含一个媒体流206：在这种情况下，基础媒体流206 QoS合同1108将简单地随更高级别(例如特定的应用)QoS限制而增加。
各个组主要用于表示媒体流206束，在一个给定的环境条件组中的多个等价束之中，当协调质量与资源可用性时，感知QoS的应用能够作为整体处理之。
就此而言，对等体能够预先积极地不但商定每个单独媒体流206的AP，而且商定给定整体束的备选合成，以及每个结果配置的特定QoS相关性804和/或时间同步805限制。因此，基于预定义规则，应用(和/或媒件)将能够适应给定的QoS变化和/或妨碍，指令哪一媒体流206应该被适应(包括类似停止或重启一个流的动作)，以及在新的情形中应该强制实施哪一新的QoS相关性804和/或时间同步805限制。要求19：E2ENP 908将包括用于规定媒体流组206的适配路径以及任何相应QoS相关性804和时间同步805限制的机制和装置。
定义一个零流QoS合同1108也是合理的，用于在适配过程期间考虑在临界情形中可能不再提供一组媒体流206的一些。用这种方式，人们能够防止完全再协商808媒体流206整个组的QoS设定，从而，留下在组运行内的那些媒体流206，对于它们，边界条件仍然有效。
零流之后的想法是，允许端对等体由于一个检测到的QoS妨碍/变化而隐含地触发一个”暂停流”命令。通过在暂停发生之前保存关于协商QoS级别的信息，人们能够使用这些信息用于在一个稍后的时刻正确并快速地再协商QoS，QoS妨碍/变化情形将不再存在。例如，让我们假定Mary正在她的移动设备106a1上观看视频片，并且她已经在她的用户配置文件中指示连接质量将降低，她将宁愿暂停视频信息流使得保存资源用于收听音乐。在一个切换期间，QoS妨碍发生并且设备因此向VoD服务器发信号以便暂停视频流。VoD服务器暂停视频流并保存预先协商的QoS信息以便在切换一完成就能够按照预先协商的QoS(包括有关音频流的时间同步问题)恢复所述流。Mary的设备106a1也不得不记住视频流的存在以便在恢复它的时候避免为它而重新来完全再协商QoS。
边界条件的定义是应用特定的，并且取决于会话102的环境。一般来说，组内的零流应用将不会影响会话102的环境。这意味着会话102内一个流组的仍然运行的媒体流206对于各个端方应该足够有意义，以保持流组竖直并且不取消它，再再协商它。因此，零流的应用仅仅是用于避免完全再协商808的一个工具，并且服务于一个流组的有意义的适配。
例如，让我们考虑一组媒体流206包含音频和视频媒体流206的情况。相应的组AP然后可以包括一个选项，其中，视频媒体流206与零流QoS合同1108相关以便解释边缘情形的出现，类似带宽降落到一个给定门限值之下之类的。在这种情况下，视频媒体流206将被停止但是音频将继续被媒体流。要求20：E2ENP 908将包括用于规定组适配路径中的零流QoS合同1108的机制和装置。要求21：零流应用将不会影响运行会话102的环境。
关联是一个特定类型的媒体流206编组，关联给定用户和一个给定对等体之间的所有媒体流206。这类编组是最直觉的一个，并且经常期望被使用。要求22：E2ENP 908将包括用于规定媒体流206关联的AP以及任何相应QoS相关性804和时间同步805限制的机制和装置。
一个QoS环境识别在媒体流206的一个给定组各处应该强制实施的QoS参数布置。一个QoS环境是一个逻辑实体，它被模拟成为QoS合同概念的专门化。
这意味着单独媒体流206的的QoS规范无论会是什么，则QoS环境都迫使一组QoS限制被应用到属于给定组的所有媒体流206。
QoS环境还可以捕获从属于与给定QoS环境[ISOX641]相关的组中的单独媒体流206的QoS合同1108中导出的那些QoS参数。示例为由媒体流206的给定组使用的存储器总量或者平均带宽。
总而言之，QoS环境处理媒体流206编组、QoS相关性804和时间同步问题，更明确地集中在如下的规范上：
·一组媒体流206的公共QoS级别；
·导出的QoS参数；
·间接影响成束媒体流206的QoS规范的QoS参数。
当然，关于在一组媒体流206之中应该强制实施什么级别的QoS相关性804和/或时间同步805的决定不但可以由开发者产生而且可以由用户产生。要求23：E2ENP 908将包括用于规定并预先协商与给定组的媒体流206相关的QoS环境的机制和装置。要求24：每个QoS环境将与一个唯一标识符相关。要求25：E2ENP 908将强制实施规定和预先协商在任何给定组适配路径之外的一个选定QoS环境，作为当开始媒体流时应用(组)将使用的缺省QoS环境。
按照前述的分层模型，可以定义QoS环境的基于树形的分层结构。那么任何这种树形数据结构的树叶将由与属于媒体流206的一个给定组的单独媒体流206相关的QoS合同1108来表述。
任何这种树形数据结构的任何内部节点将改为由一个QoS环境来表示，它然后将间接地影响所有媒体流206的QoS规范，它们的QoS合同1108被包含在根源于给定内部节点中的子树形中。这意味着QoS环境能够因此处理间接影响所有基础媒体流206的特定QoS参数(例如系统级的可靠性问题)。
此外，在任何这种树形数据结构的较高层处，QoS环境能够被递归定义在其它较低层之外。
用这种方式，基于QoS相关性804和时间同步准则，任何这种树形数据结构可以被用于不但集合单独媒体流206，而且集合媒体流206的多个已经定义的组。要求26：E2ENP 908将包括用于规定并预先协商与媒体流206的给定组集合相关的QoS环境的基于树形的分层结构的机制和装置。
每个QoS环境可以被分配一个优先级，此感知QoS的应用能够使用来确定同属QoS环境的相对重要性。要求27：E2ENP 908将包括用于规定并协商QoS环境中的优先级的机制和装置，所述QoS环境恰好同属于QoS环境的给定的基于树形的分层结构中。
通过平衡QoS环境和分层QoS规范的概念，对等体可以强制实施前述的组AP(GAP)概念。
当然，只有当包含在协商806过程中的对等体先验地商定一个给定业务(哪一应用来使用，谁来联系，哪些其它会话102要开放等等)时，QoS相关性804和时间同步限制的强制实施才是可能的。
事实上，在大多数情况下，用户本地地强制实施这些限制并且不向他们的对等体公开此信息。可以在一个给定对等体组各处强制实施这些限制的唯一情况是：只有在第三方控制单元(类似一个会议控制单元)被提供时。要求28：作为备选选项，E2ENP 908将包括用于规定和预先协商就QoS环境方面表示的组适配路径(GAP)的机制和装置。要求29：在一个给定GAP内的每个QoS环境将表示与QoS相关性804和/或时间同步805限制相关的一组媒体流206。要求30：E2ENP 908将允许在一个QoS环境内环绕任何给定的GAP，从而允许通过所述GAP的所有组成元件来协商QoS相关性804和/或时间同步805限制。要求31：E2ENP 908将允许要求28和29的递归应用。
再协商过程808通常包括一个提议者914和一个或多个应答者106a2，并且可以在一个发射中或者在迭代基础[Loyal]上被执行。
提议者914向应答者106a2提出一个提议(bid)，应答者106a2检查它并返回一个反提议(counteroffer)给提议者914。后者收集所述反提议并确定满足所有被包括一方要求的一个(如果有的话)。一旦已经挑选出这样的最佳反提议，则提议者914把它作为一个新的提议(bid)发送给每个应答者911。
在一个迭代方案中，该过程可以在此时重启，应答者911之一将仍然不接受新的提议。可是，必须用一个迭代上限限制迭代手段，并且它在任何情况下都是相当复杂并且无效率的。
应该通过在单个基础上的可能性，类似通过一对一再协商808，来进行多方连接方案的再协商808，由于单个通信方发生变化可能不影响所包括的其它方的连接，即如果一个对等体发现它的连接问题，则这并非意谓着其他的对等体它们的连接也有问题。因此，通过多方连接，在单个基础上再协商独立的媒体流206更好。以便将必要的信令减到最少。在再协商808不影响所述组环境的情况下，一组媒体流206(从属媒体流206)还可以在单个基础上被再协商。要求32：E2ENP 908将强制实施基础的、非迭代预先协商802，协商806，以及再协商808方案。要求33：通过只使用第三方控制器(例如会议控制单元)，E2ENP908可以允许更复杂的协商806方案。要求34：一般来说，E2ENP 908应该被用于只在包含在会话103中的端对等体之间执行预先协商802，协商806，以及再协商808。由于服务特定的原因，这个要求将不适用，要求31将优先采用。要求35：通过复杂的协商806方案(例如类似会议)，使用在E2ENP 908过程中的端对等体可以在一些注册服务中公布已经预先协商的QoS合同1108和用户配置文件信息从而为稍后加入的每一方允许一个短协商806过程。要求36：如果这与所述组的环境不矛盾的话，则再协商一组的单个媒体流206应该是可能的，以便将再协商808的信令减到最少。要求37：在媒体流206与其它媒体流206相关联的情况下，相关方的职责应该是与所有受影响的各方执行再协商808。
因此所建议的协商806的基本原理是允许接收者规定它们想要接收什么样的QoS级别。
这个提议和当前趋势(例如SDP/SDPng 912)之间的差别在于：后者基本不集中在QoS协商806上，而是集中在能力协商806上。例如，SDP和SDPng 912二者都允许发送者向接收者(组)给出关于格式的信息以及发送者打算用于发送的传送信息。
尝试把E2ENP 908与此熟知的方法匹配，前述的基本原理可以缓和如下：发送者和接收者二者可以规定它们在媒体流206级别上想要发送/接收什么样的QoS级别，但是只允许接收者规定它们想要强制实施用于接收什么样的AP/高级QoS级别。这是因为接收者更可能在多个接收媒体流206之中转交QoS相关性804和时间同步805限制，而这通常不是发送者的关联性。要求38：E2ENP 908将允许发送者、接收者、以及发送者/接收者规定它们在媒体流206级别上想要发送/接收什么样的QoS级别。要求39：E2ENP 908将只允许接收者和发送者/接收者规定它们想要接收什么样的AP/高级QoS级别(即QoS相关性804和时间同步805限制)。
可是，此提议的扩展留给将来研究，其扩展以允许发送者规定它们发送的媒体流206中的QoS相关性804和时间同步805限制。
对等体可以遵循一个特定程序，用于不但在连接建立时刻而且在QoS妨碍发生的任何时候都有效地强制实施协商的QoS规范。
就此而言，[BRAIN]建议协调本地资源以及网络资源的实际预留以避免等待网络资源预留直到在所有端点的资源被预留。更明确地，术语“经济原理：被使用于本文件中来描述在K.Nahrstedt和J.M.Smith的”The QoS Broker”(QoS代理)(IEEE多媒体杂志，1995年(2)1，春，第53-67)页)(在下面称为[Nahr95])中所述的预留顺序。
因此，前述的QoS预先协商802、QoS协商806以及QoS再协商808过程的综合被建议，经济原理用来在最后一个步骤中预留更昂贵的资源。由于网络资源在一些客户之中被共享并且通常人们不得不为之支付，所以首先预留所有端系统上的资源然后作为最后一个步骤预留网络资源。
然后动作顺序看上去如下：
1.首先，本地资源被预留。
2.然后，与对等体实体的协商806导致一个配置，其能够被映射到该对等体上的资源要求，然后预留之。
3.最后，在最后一个步骤中执行网络资源的预留，因为网络资源昂贵并且在多个用户之中被共享。要求40：E2ENP 908将提供用于强制实施分布式资源管理的调整的机制和装置。要求41：根据”经济原理”，只有在本地资源已经被成功预留之后，在对等体处的远程资源才应该被预留。要求42：根据”经济原理”，只有在所有对等体处已经成功预留本地资源之后，网络资源才应该被预留。
为了按照前述的”经济原理”在两个以上对等体之间适当地协调本地、对等体以及网络的资源预留，必须特别小心同时规定相应的协议以便提供一致性(这也导致更好的资源利用)并避免僵局。一致性也将导致更好的资源利用。
本节的剩余部分提供两个示例方案，激发这些要求。首先给出应用到示例方案中的常规必要条件的描述。这些必要条件说明了问题区域。可是，它们不限制该方案的适用范围。
在下面，三个等价终端设备将被假定，其每一个都装备有相同的视频编解码器。终端设备的处理能力如此以使它们每一个都能够每秒管理25个帧用于发送或者接收。
也就是说，CPU功率在发射模式(捕获，压缩，打包和发送)中或者在接收模式(接收分组，重新组合，解压缩并还原)中允许处理25Fr/s。可是，终端没有足够资源来同时发送和接收25Fr/s。而且，应该假定资源消耗与每秒的帧数量成线性关系。作为一个示例，终端设备可以同时以10Fr/s发送媒体流206并且以15Fr/s接收另一个媒体流206使得总共处理25Fr/s。
图6中所描述的三个对等体602a-c(A，B和C)的协商806方案的相互作用图示出了为什么需要提供一致性。从而，将假定在时刻t₀，对等体A发起与对等体B的一个协商806，用于管理对等体A以15Fr/s的帧速率发送一个媒体流206给对等体B。
对等体A成功地预留本地资源用于处理15Fr/s，发送协商806请求给对等体B，对等体B早已与另一个对等体进行了一个消耗20Fr/s的正在进行的类似会话102。从而，对等体B预留5Fr/s用于处理呼入媒体流206，因为那个是它所能够提供的全部了。此信息被传播回到对等体A，它释放先前预留的资源用于维持5Fr/s的协商帧速率值，然后在时刻t₁开始预留等于5Fr/s的网络资源。
让我们假定网络604不是限制因素并且最终对等体A、对等体B和网络604能够为给定的会话102保持5Fr/s。如果假定在t₀和t₁之间的任何处对等体C想要与对等体A创建一个会话102，对等体A将只能够允许对等体C本地地容许10Fr/s(＝25Fr/s-15Fr/s)。
然而，如果对等体A在t₁之后的任意时间点接收来自对等体C的请求时，对等体A对于与对等体C的新会话102，将能够容许至少20Fr/s(＝25Fr/s-5Fr/s)，因为由于在对等体C控制之外强加于对等体B上的限制，第一会话102的资源要求已经下降。
从这个方案，能够导出要求：即，管理两个对等体之间的本地、远程以及网络资源的任何这种协议将不会服务于来自另一对等体的资源要求的请求，直到该协议已经成功建立一个持续的电信会话102为止。此要求将被称为一致性。要求43：E2ENP 908将在多个对等体之中强制实施”经济原理”的一致应用。
如图7中描述的两个对等体602a+b(A和B)的协商806方案的相互作用图示出了为什么需要避免僵局，即为什么E2ENP 908必须保证没有″保持并等待″的情形，或者只有一个有限期间内可能出现这样一个情形。让我们假定对等体A想要以25Fr/s发送一个视频媒体流206给对等体B，反之亦然。
在时刻t₀，对等体A预留本地资源，并把协商806请求发送给对等体B，对等体B在时刻t₂接收此请求。同时，对等体B在时刻t₁预留资源用于发送一个媒体流206给对等体A。对等体A在时刻t₃接收此请求。
因此，对等体A从时刻t₀开始等待来自对等体B的响应，而对等体B从t₁开始等待来自对等体A的响应。结果，当两个对等体在时刻t₂(对等体B)和时刻t₃(对等体A)努力预留它们的本地资源用于服务远程请求时，它们两者都将失败。
从这个方案，能够导出这样的要求：即，管理两个对等体之间的本地、远程和网络资源的任何协议将避免僵局情形或者至少允许它们只能在一个有限的期间内发生，在此之后协议应当能够在任何情况下恢复。要求44：E2ENP 908将确保：在任何给定时刻，“经济原理”的应用不导致僵局情形。要求45：E2ENP 908将确保：恢复机制被实施以便应付可能的“经济原理”抵触应用。
端对等体一般通过也包括中间组件的一个或多个互连网络604连接。要求46：E2ENP 908将基于基础网络604的抽象而操作。
中间组件提供服务，不但可能影响对等体经由E2ENP 908在稍后时刻最终协商的信息，而且可能强制实施E2ENP 908过程的结果。
应该向中间组件通知有关由端对等体产生的决定。通知中间组件的方式可以是：在开始E2ENP 908之前通过向它们提供一些标准配置文件信息和/或通过在某些注册服务上公布商定的QoS合同1108。要求47：E2ENP 908应当能够与中间组件联合(但是从中独立地)使用，这可能导致在准备和/或确保端对等体商定的QoS合同1108中有效。要求48：信息(例如配置文件，安全，验证，提供者策略等等)的交换应该在E2ENP 908开始前面被执行，所述信息不直接影响E2ENP过程，而是影响将要被协商的信息。要求49：E2ENP 908开始之前执行的任何协商806应该以一种模块化的并且受控制的方式来执行，使得确保一致性并避免僵局。
一般来说，携带E2ENP 908消息的流(信令路径)以及携带实际媒体流206的流(数据路径)可以被不同地路由，这不但取决于网络相关的问题，还取决于应用/服务特定的原因。要求50：在任何两个给定端对等体之间的E2ENP信令路径和对应的数据路径一般应该被认为是不同的。
每当信令路径和/或数据路径被建立时，这里可能有沿着路径定位的一些中间组件(路由器，代理等等)，它的使用是应用特定的，并且它可能部分地”了解”由端对等体使用的协议。这些实体将处在可以还与E2ENP 908”干扰”的位置(例如SIP 910可以允许这样)，因此中断E2ENP 908的完全”端对端”性质。
为了避免这个威胁，如下要求迫使中间组件相对于E2ENP 908总是被动的：要求51：相对于E2ENP 908，中间组件将只基于对等体直接或间接提供的信息来操作以便执行应用特定的任务。
例如，通过把一个外在的备注放在E2ENP 908消息中指示中间组件在E2ENP 908过程期间将决不改变E2ENP 908内容，可以得到这一点。或者通过在注册服务中提前发布一些E2ENP相关信息，中间组件然后可以为计划动作询问之。
当根据编解码器的标准有效载荷类型定义，自定义音频质量将被应用到一个编解码器时，如H.Schulzrinne等人的”RTP Profile forAudio and Video Conferences with Minimal Control”(最小控制的音频与视频会议的RTP配置文件)(哥伦比亚大学，未完工程，<draft-ietf-avt-profile-new-09.txt>)中所述，则一个特定的质量可以被映射到表示此质量的那个有效载荷类型。
在音频质量和能力(有效载荷类型)之间有唯一的一一映射。
另一方面，单个视频编解码器能够产生多个质量。被压缩的视频质量表示通过编码器(编解码器)的质量。它表示单帧的整体视觉质量。这意味着通过把一些自定义质量应用到视频上，可把这个质量定义为视频编解码器能力的一个压缩百分比。另外，如G.Fankhauser、M.Dasen、N.Weiler、B.Plattner和B.Stiller的”WaveVideo-AnIntegrated Approach to Adaptive Wireless Video”(微波视频--自适应无线视频的集成方法)(注：ACM Monet，自适应移动网和计算特刊，1998)(在下面称为[WAVI])中所述，一些编解码器可规定单帧的色度平面的整体视觉质量，从而在整个辉度质量和彩色质量之间分开。彩色质量还可以被表示成百分比。不同的视频编解码器有不同压缩级别量。当用户在视觉上规定可知觉的质量时，这个质量应该被唯一地映射到一个表示视频编解码器压缩级别的数量上。
如果用户把他可知觉的质量规定为一个数或者一个数值范围，则此设置将有足够分辨率以便唯一地映射到编解码器的某一个压缩级别。因此，可以定义关于视频质量设置的两个要求：要求52：用户可知觉的质量规范的数值范围(如果彩色质量可应用，则为整体视觉质量和彩色质量)应该可以被应用和E2ENP 908唯一地理解，以便能够把质量唯一地映射到一个给定编解码器。要求53：用户可知觉的质量规范的数值范围(如果彩色质量可应用，则为整体视觉质量和彩色质量)将有足够分辨率以便唯一地映射到一个给定编解码器的压缩级别。
对等体将预先协商一个资源管理策略以便每当处理QoS再协商808时的执行时刻避免不稳定性。
否则，结合到所述电视会议的两个或多个对等体1204a/b，应该检测违反一些所有权资源管理策略的资源使用，每个对等体独立产生的判定会按照这样一种方式来影响剩余的对等体，该方式可能与那些其他对等体可能同时在努力产生的决定矛盾。这将导致资源配置空间中的”摆动”，这将影响总体系统能力以及用户知觉到的QoS。
同样的原因，应由发送者来决定触发再协商808过程。可是，如果接收者同时检测到资源可用性的恶化，它能够触发一个再协商808，并且将通过只允许发送者有权继续这一过程，从而来解决与其它对等体(包括发送者)的任何最后的冲突。
就此而言，一组定义明确的资源管理策略的定义被建议，对等体能够通过协商而商定在其上。用这种方式，对等体在运行时间仍然能够独立地管理它们自己的资源，但是是以一种协调的方式来管理。
此类策略将覆盖至少如下方面的任何逻辑组合：·
·存储资源最优化，
·处理能力最优化，
·网络资源能力最优化，以及
·功耗最优化。
更明确地，功耗最优化与所有其它类型的资源管理相关连：例如，一个存储器交换消耗功率。
如果一种策略不明确地规定功耗最优化，该策略因此将使其他类型的资源使用最优化，而不必过于在意功率(这例如对于永久地插入干线的台式PC机来说可能有意义，它将有很多功率来使除了功率之外的任何类型的资源最优化)。
如果一种策略明确规定功耗的最优化，这个策略准则将影响所有其他最优化准则。
只要满足协商的QoS合同1108和资源管理策略所强加的情形，则策略的使用允许应用和/或媒件灵活地产生它们自己的适配决定。因此，不需要QoS合同1108的优先级的定义和协商。此外，也不需要编解码器/能力的优先级的定义和协商806。这样一个优先化的原因实际上是由于类似编解码器之类的能力彼此不同地消耗资源的这一事实。此外，在被使用于特定配置中时，通常比其他较少执行的编解码器可能更合宜地将资源使用优化。要求54：E2ENP 908将提供用于规定并预先协商资源管理策略的机制和装置。要求55：资源管理策略将包括(但是不限制为)如下准则的任何逻辑组合：存储资源最优化，处理能力最优化，网络资源能力最优化，以及功耗最优化。要求56：基于预先协商的资源管理策略和当前资源可用性，利用E2ENP 908的应用和/或媒件可以自动把编解码器/能力列表区分优先级。
动态的通信环境不但需要数据连接的建立和管理的适应性，而且需要通过执行协商808和809的适应性。图1示出了一对一通信方案100的协商808和809的特殊情况，其中：对等数据连接正在被”第三方协助”协商。此类协商806可以利用使用注册、分配、存在等等服务的优势，从而允许更彻底的满足用户对于QoS的要求并且可发现并利用用户附近地区内的多个设备。
通过开始一个协商806，被叫设备可以发现它不可能处理该呼叫。因为设备不能适应，所以该呼叫简直不可能发生。不改变对等体的能力就能够被应用在这种情况下的一种适配将根据用户的配置文件定义把该呼叫委派给另一对等体。这种功能在这里被称为仲裁者106a1，并且描述了对等体代表其它对等体并按照预置的用户配置文件定义来协商的能力。这类协商809被称作”第三方协助协商”。仲裁者106a1积极地参与两个对等体之间的协商809但是不参与数据连接。如果仲裁者106a1将积极地参与到一个数据连接正时，将另外需要桥接功能，在一些情况中，桥接功能可能会导致必需的代码转换，因此运行成为多方连接并且需要它们的协商809。位于数据路径上的仲裁者106a1的另外一个问题可能是设备引起一个瓶颈，因此消极地影响了提供所需QoS的可能性。考虑到这些问题，此类适应性可以只是被预先形成，如果所有对等体(包含仲裁者106a1)交换有关它们能力配置文件的信息(例如设备比特率吞吐量)，这意味着多方连接应该被协商，这将稍后讨论。因此，对于协商809的情况，按照这样一种方式考虑仲裁，以使仲裁者106a1不参与数据媒体流。
当一个提议者106b发出一个设备不能处理的呼叫时，仲裁者106a1的促进功能被触发。在这种情况下，仲裁者106a1搜索一个适当的应答者106a2并且也通过通知用户并要求接受委派状态来委派所述呼叫。因此，提议者106b和应答者106a2通过仲裁者106a1接收有关彼此的配置文件信息，从而加速在稍后时刻在提议者106b和应答者106a2之间的发现和直接协商806过程。
仲裁者106a1功能需要能够使用支持它的促进能力的附加服务。此类服务的特定应用在此文献的范围之外，在这里只是承认它们的使用优势以及E2ENP 908从中如何受到影响。
仲裁者106a1需注意不要涉及正在实行仲裁的一方(提议者106b)或另一方(未来的应答者106a2)未知的会话信息112。当通过呼叫仲裁者106a1只涉及有关多个会话103但是不明确包含在消息中的信息时，通过最后重建出自一个对等体中的会话信息112，应该允许仲裁者106a1执行所述促进。从而，仲裁者106a1通过正在实行促进的每一方来看管完成有关会话102的信息组112。仲裁者106a1不改变会话信息112的内容但是最后把完整的描述部分加到它的呼叫中以便聚拢其他协商方106b和106a2的信息组。要求57：通过第三方协助协商806，一个纯仲裁者106a1只应该促进连接的委托而不积极地参与之。要求58：仲裁者106a1可以利用使用注册、分配、出现等等服务的优势，其信息可以只被使用于E2ENP一致消息的构成，但是不影响E2ENP 908的构造和能力。要求59：仲裁者106a1应当能够在旧的描述之外产生新的会话描述112，涉及各方，但是不改变信息内容而只是为了促进需要重建之。仲裁者106a1应该考虑发送完整的会话描述112而没有未知的参考。
现有技术的缺陷和缺点
在欧洲专利申请EP 01 122 366.6中，整个E2ENP概念、它的要求及其可能的实施被公开，可是，没有详述相对于当前技术的任何实施。任何预先协商的信息未及时实现。
虽然SDPng[SDPNG03]的当前形式以模块化的方式构造，但是它没有考虑E2ENP方面并且不能通过不同的SIP(或其它协议)消息以模块化的方式被使用。SDPng基于SDP发出/应答模型，其中诸如E2ENP范围中所建议的一个之类的复杂多阶段协商过程未被明确考虑。
能够考虑用户配置文件信息作为整个QoS协商过程输入的一种过程既未在欧洲专利申请EP 01 122 366.6中被处理也未在SDPng中被处理。
本基础发明目的
鉴于上面提及的解释，本基础发明的目的是，建议一种为运行在连接到无线网络移动终端上的自适应实时业务和多媒体应用，提供QoS管理和资源预留机制，以便动态地适应基础移动无线信道随时间变化的链路特性的方法。从而，基于本地、对等体和网络资源管理的集成和协调的概念将被实现，其允许对等体在实际通信发生之前预先协商能力、质量和适配机制的一个公共组，以便为所述终端提供一个可确保的端对端质量。
依靠独立权利要求的特征来达到此目的。在从属权利要求中定义了有利的特征。本发明进一步的目的和优势在如下详细说明中是显而易见的。
发明内容
本基础发明主要专用于一种按照这样一种方式来定义用户配置文件和终端能力信息的模型，使得分层QoS合同规范(例如通过相关媒体流的不同QoS合同组的强制相关)可以被强制实施并被用于导出可协商信息。作为此概念的一个参考实施，本发明描述了一种新颖应用，它基于可扩展标识语言(XML)由互联网工程任务组(IETF)与下一代会话描述协议(SDPng)规范协同来标准化会话启动协议(SIP)以便实现端对端QoS协商协议(E2ENP)概念。
更明确地，因此所建议的模型通过允许如下来扩展SDPng协商：
-通过补充协商阶段，SDPng的部分携带在E2ENP不同阶段发射的补充信息的各个片段，允许完全协商图象的构成，其中每一阶段在SDPng描述中被明确地提及；
-用于预先协商阶段的所述部分中一些的时帧执行，因此避免废弃的信息稍后被错误地强制实施。
权利要求的简短描述
独立权利要求1和从属权利要求2到12涉及一种下一代会话描述协议(SDPng，912)的扩展，用于实现在端对端协商协议(E2ENP)范围中所需的概念，其为电信会话提供一种可确保的端对端质量，其中运行在连接到无线网络的移动终端上的多媒体应用被包括来动态地适应基础移动无线信道随时间变化的的链路特性。关于这点，所述概念基于本地、对等体和网络资源管理的集成和协调，其允许对等体在实际通信发生之前预先协商能力、质量和适配机制的公共设置。从而，所述下一代会话描述协议(SDPng)被用于定义一个应用层协议。
接下来，从属权利要求13到49是针对一种用于实现在端对端协商协议(E2ENP)范围中所需要的概念，其为电信会话提供可确保的端对端质量。从而，所述SDPng能够被应用来定义用户配置文件信息，用户配置文件信息被用于导出E2ENP输入。
此外，独立权利要求50和一种端对端协商协议(E2ENP)有关，其中，通过在端对端基础上预先协商备选QoS方面和能力来建立一个QoS启用的电信会话，以便预先建立一个公共级的备选QoS和能力，电信会话的所有对等体可以商定其使用。
此外，从属权利要求51涉及一种为电信会话提供可确保端对端质量的端对端协商的代理。从而，所述代理能够从执行预先协商阶段中并且作为选择从根据权利要求35的多流时间同步阶段和QoS相关性阶段中解除网络的对等体。
接下来，从属权利要求52涉及一个软件分程序，当它被计算设备执行时实现根据权利要求13到49任一个的方法。
而且，从属权利要求53到61是针对一种对等体，它被配置用于实现根据权利要求13到49任一个的方法，它包括一个协调单元，协调分布式资源管理过程的的协商过程的不同阶段。
最后，从属权利要求62和一种协议有关，所述协议为通过在端对端基础上预先协商备选QoS方面和能力所建立的电信会话提供一个可确保的端对端质量，以便预先建立一个公共级的备选QoS和能力，电信会话的对等体可以商定其使用。而且，能力的协商和再协商包括选定的编解码器及其结构的信令。
附图说明
本基础发明的进一步优势和可能的应用由从属权利要求中以及由所述发明的一个实施例的如下描述中产生，所述内容在如下附图中被描述：
图1中描述了一种一对一”第三方协助”通信方案100，其示出了电信会话的交换情形中的呼叫再分配，其呈现了能够安排未来类似电话的通信的思想，
图2展现了示出一个虚拟演讲的一对多通信方案200，
图3概述了示出一个简单形式电视会议的多对多通信方案，
图4概述了示出一个复杂形式电视会议的多对多通信方案，
图5呈现了示出多方通信的一些附加方面的一个示例，考虑了支持通信各方和业务的发现的一些服务的使用，以及协商的开始，
图6概述了示出为什么需要提供一致性的方案；
图7概述了为什么需要避免僵局，即为什么E2ENP必须保证没有″保持并等待″的情形，或者只有一个有限期间内可能出现这样一个情形，
图8通过一个用于建立一个简单一对一通信的简单一对一协商方案，描述了表示E2ENP阶段和操作的相互作用图，
图9示出了使用SDPng和SIP的E2ENP功能，
图10描述了示出所谓的<e2enp：alternative-service>(e2enp：备选服务)部分的使用的示例，
图11示出了一个方案，其中从用户配置文件和系统配置信息中导出的合同被核实，
图12示出了同时加入两个不同电视会议会话的用户示例，和
图13示出了被称作”转移到特设”的多对多通信方案的示例。
具体实施方式
在下面，将详细地解释在图1到13中描述的本基础发明的优选实施例。可以从表3中采用图1到13中的参考符号所指示的符号含意。
1.SDPng 912的扩展，用于实现E2ENP 908和因此所建议的它的扩展，特别地：
-SDPng(912)内容能够从用户配置文件信息中导出，它然后被使用作为E2ENP(908)的输入，
-SDPng(912)内容能够从终端能力信息中导出，它然后被使用作为E2ENP(908)的输入，
-为单个媒体流206或它们的群组引入详述QoS方面的两个新SDPng部分；
-各个部分的模块化使用：不同SDPng(正如在实际SDPng 912草案和新草案中所建议的)的部分可以在E2ENP 908协议的各个阶段中被交换，
-增加一个标记，其明确地识别E2ENP 908每个阶段中的每个SDPng内容，其中，SDpng内容实际上变成E2ENP 908的一个协议数据单元，通过910或类似的协议(例如SCCP)被搭载，
-E2ENP 908利用一个租赁预先协商SDPng信息以便及时地限制这个信息的有效性，和
-除了IPv4的对等提供，SDPng 912的扩展提供用于规定不同类型的网络604地址。
2.E2ENP 908的扩展：
-SDPng 912的使用，用于定义被使用作为E2ENP 908输入的用户配置文件信息，
-SDPng 912的使用，用于定义被使用作为E2ENP 908输入的终端能力信息，
-E2ENP 908经由搭载通过SIP 910协议的详细映射，并且为了符合在早先章节中提出的要求，建议了一种被称为端对端QoS协商协议(E2ENP 908)的新协议。
在进行E2ENP 908概念的描述之前，据此提出一些关键假设，完成上述操作和方案的通用描述。
简单的一对一通信方案800
通信模式(推、拉和推拉)的使用可能是关于发送者和接收者依存的情形和应用。在这儿描述那些模式的一些标准使用：
·如果提议者810对于应答者811的配置文件看上去如何没有概念，则提议者810可以使用”拉”模式来首先重现应答者811的设定并最后适应提议者810自己的设定。
·如果提议者810没有可能适应(或者无论什么其它原因)，则提议者810可以把他/她的设定”推”给应答者811，因此最后强迫他/她适应并使用”推”模式。
·如果可能需要在两侧的适配时，则可使用”推拉”模式来启用提议者810的提议的三种方式交换。这个模式能被用于商定双向通信。
通过假设”接收者”将调整到给定的”发送者”，″接收者”应该是适配的那些。如果”发送者”将匹配给定的”接收者”，则由”发送者”发生适配。
对于简单的一对一通信方案800的情况，考虑到哪一方是提议者810以及哪一方是应答者811，哪一方是发送者或接收者，以及双方是否可以发送和接收，有三种方案：
·发送者(提议者810)-接收者(应答者811)
一般来说，根据发送者和/或接收者的适配可能性和规则，″推”和”拉”模式两者都能被使用于此方案。如果提议者810是应该适应的那一个，则提议者810应该使用”拉”模式，否则应该使用”推”模式。也可以应用”推拉”模式的使用，但是通过预期的单向数据媒体流206，这将只会使信令协议复杂并且与E2ENP的简明性要求相悖。
·接收者(提议者810)-发送者(应答者811)
同样，在这种情况下，根据发送者和/或接收者的适配可能性和规则，″推”和”拉”模式两者都能被使用于此方案。如果提议者106b是应该适应的那一个，则提议者106b应该使用”拉”模式，否则应该使用”推”模式。在这里，由于与上述方案相同的原因，″推拉”的使用也不推荐。
·发送者接收者(提议者810)或者发送者接收者(应答者811)
当所有对等体计划既发送又接收媒体流206时，在提议者810向给定的应答者811发出邀请之前，提议者810集中关于应答者811的接收能力和QoS要求的信息。
用这种方式，到邀请时刻，提议者810可以向应答者811发送一个提议，包括：
-关于提议者810用于发送和接收媒体流206的能力的信息；
-在应答者811的首选项上定制的提议者810自己期望的用于接收媒体流206的QoS规范；和
-在应答者811的首选项上定制的用于发送媒体流206的QoS提议。
应答者811然后用提议者810的请求子集来应答提议者810。
此方案最可能使用”推拉”模式，因为应该建立双向通信。
一对多通信方案200
通过一对多通信方案200，不是所有的连接模式和协商806模式组合是可能且合理的。例如，″单个接收者和多个发送者”方案会引起接收者一端的过载，并且这就是为什么这种情况应该通过迫使接收者在每个发送者独立的基础上执行多个协商808和809而被对待的原因，类似在”发送者(提议者810)-接收者(应答者811)″方案中那样。
与一对多通信方案相应的一些熟知连接方案是：
-纯多播：基于预先传播的信息(例如经由SAP)，通过选择一个给定多播组，接收者”调整”到给定的发送者中。在这种情况下，发送者担当一种提议者810。
-此方案将像”接收者(提议者810)-发送者(应答者811)″方案那样工作。这允许加入和离开会话102的灵活性。应答者811能因此为每一参与者在单个基础上适应会话102，但是也考虑被已经存在的会话102所使用的资源。发送者已经取代了提议者810的角色，一些接收者可能不能够应付此类要求。
在两种情况中，提议者810(或者发送者或者接收者)能够有利地离线使用预先协商的信息用于加速在运行时间的通信建立。最后，这能够通过如  FIPA公开的文件(智能物理代理基础(http：//www.fipa.org/)(在下面称为[FIPA]))中所述的用户代理或者通过一个代理(但是这些情况超出此文件范围)来执行。单方是一个接收者的所有方案应该被认为是一对一协商806，因为对于每一呼入媒体流206可能需要一些独立的资源管理。
多对多通信方案300、400或500
如果对等体在开始的时候，商定会议领导者，即领导管理用于加入/离开会话102的协商809并且管理它的运行，则此情况可以像多个协商809的叠加那样来对待。对等体还可以在它们协商实际连接之前，进行有关如何配置通信环境的某些先验配置。运行在协商对等体之间的并行和/或连续的协商806是应用相关的，并且其在根据本基础发明所建议的发明解决方案的范围之外。
E2ENP 908包括四个关键阶段，即：
1.端对端QoS预先协商阶段802；
2.多流QoS相关性804和时间同步805执行阶段；
3.端对端QoS简洁协商(经济原理)阶段，或者更简明，″快速协商”806和
4.端对端QoS简洁再协商(经济原理)阶段，或者更简明，″快速再协商”808。
所有这四个阶段可以被连接在一个给定媒体会话102的使用期内。可替代地，开头两个阶段可以与后两个无关地并且在不同的时刻被执行，但是严格地遵循给定的顺序。结果，假定各个E2ENP 908阶段的结果在一个有限时间内有效，则各个阶段，相应的有效性时间量程可能彼此不同。
更明确地，可以先验地执行端对端QoS预先协商阶段802，并且结果能因此在稍后的时间被应用到多个连续的电信会话102的剩余阶段。这个阶段其特征在于，在实际开始一个媒体会话102之前，并且与会话102本身无关地，端对等体能够执行的一个过程。此阶段的目的是，以一种非强制的方式启动从它们的QoS配置文件中推断出的、对等体间的信息交换，涉及能力和QoS合同1108的配置。
这些配置包括适配路径，因此端对等体能够预先积极地商定这种方式以便以一种有效且有效率的方式对可能的QoS改变或QoS妨碍作出反应。作为选择，这个阶段允许每一对对等体在关联级协商组适配路径，即，通过在给定的对等体对之间建立的所有媒体流206来强制实施QoS相关性804和时间同步805。
这个消息交换具有所包括的对等体的信息字符，并且不但被用来在前面彼此通知关于适用于给定对等体组的容量和能力可能性，而且被用来对重新定义那些结构中的一些达成一致意见。用这种方式，对等体因此能够建立一个公共词汇，任何特定业务的一个先验。
多流QoS相关性804和时间同步805强制执行阶段是可选的，在此范围内，只有当对等体被计划来建立需要被相关和同步的多个媒体流206时才需要它。单独的对等体独自应用这样一个阶段。作为例外，一个分开的实体(例如类似会议呼叫桥梁的一个中间组件)还可以使用这个阶段，各个对等体应该委托它执行它们中的复杂协商806。中间组件的情况是在此文件的范围之外，并且只是为了完整的缘故才提及它。从图8中描述的相互作用图中可以采用E2ENP 908的阶段和操作。
第三阶段其特征在于一种过程，基于预先应用的端对端QoS预先协商802过程的结果，在实际开始一个媒体会话102之前或者就在那时，端对等体能够执行所述过程以便商定为给定会话102和媒体流206要强制实施的给定QoS级别。此过程与端对端QoS完全协商806的情况相比快相当多，因为在对等体之中实际上只交换预先协商的信息首选项。端对端QoS完全协商806是这样一个过程，在一个会话实际开始之前或者实际开始时，端对等体能够执行所述过程，以便通过重新定义QoS规范最初建议的配置中的一些，来最终对于给定的会话和媒体流商定要强制实施的一个给定QoS级别。在端对端QoS简洁协商过程完成时，端对等体已经商定它们通信将使用的QoS配置文件。在端对端QoS简洁协商806过程完成时，端对等体已经商定它们通信将使用的QoS配置文件。
第四阶段其特征在于一种过程，基于预先应用的端对端QoS预先协商802过程的结果，在检测或者QoS变化或者QoS妨碍后，端对等体能够启动所述过程，以便商定为给定会话102要强制实施的给定QoS级别。
此过程与端对端QoS完全再协商808的情况相比快相当多，因为在对等体之中实际上只交换预先协商的信息首选项。端对端QoS预先协商802是这样一个过程，在检测或者QoS变化或者QoS妨碍后，端对等体能够启动所述过程，以便通过重新定义QoS规范最初建议的配置中的一些，来最终对于给定的会话和流商定要强制实施的一个给定QoS级别。在端对端QoS简洁再协商过程完成时，端对等体已经商定它们通信将使用的新的QoS配置文件。
在端对端QoS简洁再协商808过程完成时，端对等体已经商定它们通信将使用的新的QoS配置文件。
在任何给定媒体会话102使用期期间，端对端QoS简洁再协商阶段808能够被应用几次。
基于在上面提出的要求，对等体可以预先积极地预先协商一个公共资源管理策略，以便每当符合导致再协商808的情形时避免不稳定性。
就此而言，对等体能够在两个不同的级别上执行再协商808：
·一个快速的带内信令过程，(例如通过在运行时间在RTP分组标题中改变RTP有效载荷类型，而没有影响当前强制实施的应用层QoS合同1108)，和
·一个更结构化的过程，基于端对端QoS再协商阶段808(每当前一个过程不足以应付一个给定QoS妨碍/变化时)。
更明确地，对等体能够动态地选择使用一个给定用户级别QoS合同1108可应用的任何有效载荷类型，如下所述。此选择在通常RTP带内信令的实例中将反映为极快的再协商808形式。然而，QoS妨碍或QoS变化应该发生，需要强制实施一个新用户级别QoS合同1108，端对端QoS再协商阶段808将发生。
包含在RTP报头中的RTP有效载荷类型字段可以被发送者使用来用于把使用另一(协商的)编解码器的决定带内指令给它们的接收者。这是再协商808的一种形式，它本身对E2ENP 908来说将是透明的。可是，使用此带内信令的对等体仍然可以有利地使用E2ENP 908用于对QoS妨碍/变化有效并且有效率地作出反应。在这个环境内，通过迫使对等体把新建议的编解码器与任何预先协商的信息(不但就能力方面而且就QoS合同1108方面)进行核实，则能够容易协调带内RTP信令的使用。
这意味着相对于预先协商的信息，发送者将首先核实(以及相应地事先登记(pre-book)资源)新的能力，以及一个新的QoS合同1108(使那个能力的使用最优化)。另一方面，每个接收者将靠预先协商的信息来核实发送者带内指示的新能力。
可能有这样的情况，其中，接收者检测到没有足够资源可用于激活给定的编解码器，而发送者已经切换编解码器并发送用它编码的分组。接收者因此不能解码那些分组，或者以一个较低的QoS级别(例如以低速/帧速率)解码它们。为了解决此问题，可以假定接收者选择后一个选项(以较低的QoS级别解码)，但是向发送者明确地发信号以便选择一个较低的QoS级别(经由E2ENP 908简洁再协商808)，例如中间的一个(假设预先协商的信息可用)。就此而言，需要提及：在发送者和接收者之间的QoS交换的时间内，丢失或者不翻译单个视频分组不那么关键，因为从人类用户的观点来看，丢失的单个图像帧不容易注意到。因此，用户感觉的视频QoS不应该认为严重受到这种次要视频干扰的影响。另一方面，丢失或者不翻译单个音频分组导致能听得见的噪音，从用户观点来看，这应该被认为是一个妨碍。这个问题的一种可能解决方案可以是在同一音频分组中用相同的或者不同的质量发送冗余音频数据，如C.Perkins等人的”RTP Payload forRedundant Audio Data”(冗余音频数据的RTP有效载荷)(RFC2198，网络604工作组，1997年9月)(在下面称为[RFC2198])中所述。那些分组因此携带音频数据两次并且如果单个音频分组丢失，则随后的一个冗长地代替丢失的数据。为了提供用户感觉的音频QoS，相对于对等体之间商定的能力和QoS合同1108，这种复制的信息应该被递送，因此允许发送者并行地递送不同编码的音频数据。从用户的观点看，用较低质量接收单个音频分组将不会被认为是一个妨碍，因为如果在设备的所有音频箱上同时播放单声道信号，人类很少能感觉例如单声道和立体之间的异常切换之类的那种变化。在一般时期，音频与视频异常干扰的累积应该被认为是一个妨碍并且应该只有在运行再协商808的时间内被允许。出现的媒体异常的处理是实现资源管理、容限和控制机制等等的一个问题；并且可能是应用和渐进依存的。
用于实现上述机制的关键问题是：
1.带内信令不足以允许对等体商定强制实施的QoS合同1108：实际上可通过使用更结构化的手段(类似E2ENP 908)来完成完全再协商808机制。可是，作为使用E2ENP 908的一个备选，接收者最后通过平衡RTCP显示器，可以监视当前QoS级别，并因此识别发送者当前正在强制实施哪一预先协商的QoS合同1108。
2.网络资源预留不应该被委托直到两个对等体已经商定什么编解码器以及强制实施什么QoS合同1108。由于”经济原理”，E2ENP 908确保这点。
基于用于应付切换方案所需的要求，用户优选的网络提供者不提供的所有那些QoS合同1108可以被有利地认为是备用的。这些合同1108将不得不被协商，在此范围，提议者810和应答者811可以有利地先验地商定类似的合同1108，使得考虑在其他对等体和它们当前利用的网络提供者之间的商定。
当一个垂直切换发生时，任一对等体可以努力核实包括备用的在内她/他的所有合同1108，其最后可能相对于新的网络提供者和/或新类型的接入网络604而变成可应用的。这意味着：检测QoS妨碍或变化的对等体在发现一些备用合同1108现在被核实之后，发起一个端对端QoS简洁再协商阶段808，不但用于指示强制实施的新QoS合同1108，而且”开启”(unblock)所述预先协商的备用合同1108。
此外，应该注意：在一个垂直切换之后，某些预先有效的合同1108可能不再可应用。这意味着，此类合同1108的”阻塞”(block)在端对端QoS简洁再协商阶段808期间也应该被考虑。
在所有四个阶段期间，E2ENP 908与本地资源管理功能相互作用。更明确地，E2ENP 908在端对端QoS简洁协商阶段806和端对端QoS简洁再协商阶段808两个期间，根据”经济原理”并基于在端对端QoS预先协商802期间预先协商的资源管理策略，来与本地和网络资源管理功能相互作用。
给出由这些要求所规定的QoS规范的分级结构，可以预想很好地满足那些要求的一个模型是基于分层有限态机器(FSM)概念的一个模型，分层有限态机器如G.Booch、J.Rumbaugh和I.Jacobson的”TheUnified Modeling Language user Guide”(统一模拟语言用户指南)(Addison Wesley Longman，1999)(在下面称为[Booch99])中所述。在这样一个模型中，每个QoS合同1108对应于分层FSM的一个状态。在这个分级结构的最低层，状态映射到单独媒体流206的QoS合同1108。标准的QoS合同1108(即，用户用默认值希望启动的那个)对应于与给定适配路径相关的FSM的初始状态。每一适配路径对应于一个基本的FSM，其中，状态互斥。状态和/或完整的基本FSM可以被嵌套在更高级别状态之内，其接着与QoS合同1108相关，如上所述：这表示QoS环境的概念。在一个给定的较高级别状态内，同时发生的嵌套FSM可以共同存在。这表示一组适配路径通过给定的QoS环境相互相关。
这种分层FSM的每个转移描述了反应于一个给定事件(例如QoS妨碍)的QoS合同1108的特殊变化。每当特定的判定估计为真时，触发所述转移：在我们的模型中，这个转换来把特定的监视QoS参数值与给定QoS合同1108中规定的相应值比较。
转移最后与高级别动作(例如丢弃存在的媒体流206或者开始一个新的媒体流206)相关。这些动作最后会向用户引起指示临时业务中止情形事件的产生，例如由于一个切换出现。
与如[Loyal]中所述的QoS描述语言(QDL)不同，QoS合同1108(并且，到一个有限的程度，QoS环境的)的以及分层FSM的规范彼此去联系。这把模块化以及灵活性引入该设计：人们可以用不同的适配策略组合一个给定QoS合同1108，并且可以用不同的分层FSM配置适配策略。
E2ENP 908使用的协商806过程基本上由在连接建立时刻运行一个非迭代协商806过程来组成，其中，相对于表示一个给定的预先协商适配路径的分层FSM，对等体只须在本身之中交换一组状态标识符。
提议者810将建议一个提议，并且每个应答者将靠它自己的适配策略核实该提议，并相应地用一个反提议响应。这个模型把反提议的范围限制为原始提议的子集定义(以便限制问题的复杂性)。这个在应答者层如下转换：
·相对于预先协商的QoS合同类型和QoS合同1108，根据[Frolu98]，转换成为应用到提议中的每一项的一个QoS合同一致性核实；合同1108应该以一个XML文档的形式被表示，例如通过强制实施一个预先定义的特定XML文档类型定义(DTD)，可以实现一致性核实。
·转换成为一个可选的修剪(pruning)操作组，被应用到原始预先协商的分层FSM的结构上。
应该注意：每当一个新的对等体加入一组已经通信的对等体中时，该新的对等体可以担当新的E2ENP过程(最后从端对端QoS简洁协商阶段开始，新的对等体早已含有与通信对等体的预先协商信息)的提议者810，随后是如上所述的相同机制。此外，在那之后已经成功完成协商809过程(并且还未被考虑为协商适配路径内的一个QoS变化)，则QoS环境和/或媒体流206的任何特设的创建、修改或消除将启动协商过程808和809的一个新情况。更明确地，人们应该注意：用户可能故意地对一个已经运行的多媒体应用引起一个QoS变化，例如为了增减QoS的总级别，或者只是增减它的某些部分。这个协商808和809将反映在与适配路径相关的QoS合同1108中的一个变化中，但是还可以反映在适配路径本身的结构上。因为协商过程808和809相当昂贵，E2ENP 908或其部分的任何连续递增的重新应用都会引起无效。就此而言，应当指出：
·在一个视频点播方案中，双方只需为一个预确定媒体流206组先验地商定一个适配路径以便应付QoS妨碍或者QoS变化。前述的特设变化的变化性因此不应用到这个情况。
·提议者810最后已经可以考虑类似在它提议的适配路径内的QoS环境和/或媒体流206的创建、修改或消除那样的事件。
·在初始协商809之后，与初始协商809的情况相比，所有对等体能更快速地收敛到协商806协议上，因为它们大多数都使用一个已经协商的分层FSM。
可是，用于处理这些情形的规则极大地取决于应用到给定电信会话102上的管理类型。例如，在会议业务的情况下，这转换成选择特定的会议控制策略和协议。因此，绝对的E2ENP 908功能以这样一种方式被设计，以使它把这些高级会话102管理任务委托给外部机制和协议，它们因此在本基础发明的范围之外。
通过扩展E2ENP 908阶段手段，随着微阶段的引入，可以预想到精致。这意味着对等体可以递增地更新预先协商的信息，例如用于在垂直切换的情况下调整预先协商的信息，其中，与预先协商的相比，新的接入网604技术/容量和/或新的网络提供者可以提供不同的QoS级别。就此而言，需要可协商项目的模块化描述，因此不受变化影响的那些被保持有效。这意味着对于这些项目，由于相对于QoS变化/妨碍处理就能力方面的明显好处，那么将不需要完全再协商808。留下此概念用于进一步研究。更明确地，必须详细地考虑像对预先存在的状态机器的影响那样的描述预先协商AP的方面。
在如下部分中，通过平衡类似SIP 910和SDPng 912那样存在的协议，将提出实现所建议解决方案的可能方式。
就此而言，SIP 910将以新颖的模式而被使用，但是将保持基本不变；然而SDPng规范的扩展和一些变化因此被建议，使得符合上面提出的要求。在图9中描述了使用SDPng 912和SIP 910的E2ENP 908的功能。
这种思想是用最小的和模块化的变化来扩展SIP 910的使用并增强SDPng规范(它当前正被计划在IETF MMUSIC工作组内)以包括E2ENP要求。这仍然不是一个健全的规范，而只是因此建议的思想的一个详细解释，目的是提高技术共同体内的兴趣并激起讨论。
在进行任何进一步处理之前，应该处理应用层QoS规范的问题。
用户通常对定义它们想要与对等体以什么质量交换什么信息感兴趣(特别是如果他们将必须不但为内容支付而且还为QoS支付时更是如此)，而与他们的请求实际上将如何被他们的终端设备和网络604执行无关。因此，可以料想用户将通过详述内容描述和QoS合同1108来表示他们的希望。这类QoS规范被称作用户层QoS规范。
此外，应该假定用户可能想要定义与一组多个不同内容和/或服务相关的一组QoS合同1108。就此而言，可以料想用户将愿意匆忙地规定这些QoS合同1108，或者更有利地，预定义它们并把它们存储在所谓的用户配置文件信息数据库中。
应用或媒件将把用户级QoS规范转换成为应用层QoS规范，它因此被认为是E2ENP 908的输入。
在本基础发明的范围中，我们实际上对用户感觉它那样地规定QoS感兴趣，如L.Bos等人的”A Framework for End-to-End User-Perceived Quality of Service negotiation 806”(端对端用户感觉服务质量协商806的框架)(IETF互联网草案，)未完工程，<draft-bos-mmusic-sdpqos-framework-00.txt>)(在下面称为[Bos01])中所述。可是，我们不关心用户如何表达这一点。
清楚地，这里需要的是从用户希望和首选项对一组QoS参数的映射，所述QoS参数定义端对端传输过程的质量。这组参数被称作应用层QoS。这种映射是应用特定的并且在范围之外。
下列XML文档是可以如何规定应用层QoS合同1108的一个示例：在这个示例中，只有音频与视频媒体流206的QoS合同1108被指出，但是扩展到包括其它类型的媒体流206(像数据或者控制媒体流206)是很简单的。对于每一类型的媒体流206，就标准值、标准组或操作范围方面规定一组应用层QoS参数。
对于音频媒体流206在QoS合同1108中指示的参数反映在[RTP-Profile]中指示的音频编解码器参数，有一点差别在于：用户配置文件信息将描述范围而不是那些参数的固定配置。另一方面，对于音频媒体流206，在QoS合同1108中指示的参数不反映[RTP-Profile]规定；而是使用在[BRAIN]中建议的QoS参数。
<profile name＝“my-preferred-stream-level-QoS-contracts”>
<contract name＝“my-audio-contract-1”type＝“audio”sampling-rate-set＝“4000，8000”channel-set＝“1”/>
<contract name＝“my-audio-contract-2”type＝“audio”sampling-rate-range＝“8000，12000”channel-set＝“1，2”/>
<contract name＝“my-audio-contract-3”type＝“audio”sampling-rate-range＝“12000，16000”channel-set＝“1”/>
<contract name＝“my-audio-contract-4”type＝“audio”sampling-rate-range＝“16000，44100”channel-set＝“1”/>
<contract name＝“my-video-contract-1”type＝“video”frame-rate-range＝“10，15”frame-size-set＝“CIF”color-quality-range＝“9100，9700”overall-quality-range＝“9500，9800”/>
<contract name＝“my-video-contract-2”type＝“video”frame-rate-range＝“15，20”frame-size-set＝“QCIF，CIF”color-quality-range＝“9700，9850”overall-quality-range＝“9800，9900”/>
<contractname＝“my-video-contract-3”type＝“video”frame-rate-range＝“20，25”frame-size-set＝“QCIF”color-quality-range＝“9850，9900”overall-quality-range＝“9900，9960”/>
<contract name＝“my-video-contract-4”type＝“video”frame-rate-range＝“25，30”frame-size-set＝“CIF”color-quality-range＝“9900，9970”overall-quality-range＝“9960，9990”/>
</profile>
XML示例1
在用户配置文件中，用户可以规定具有不同粒度级别的QoS：特定的目标值或者操作范围，或者作为离散组或者作为连续的间隔。帧尺寸设置(frame-size-set)指示所表示的帧的尺寸。它既可以规定为一种标准帧尺寸(CIF，QCIF，SIF等等)又可以规定为以像素为单位的一个宽高分辨率(例如352×288)。
帧速率设置(frame-rate-set)表示用于规定对等体目标帧速率的一个间隔。例如，如果帧速率被设置为20Fr/s，则发送者每秒应当能够压缩、打包并发送20帧。接收者应当能够解码和还原20Fr/s。有关相对于帧尺寸映射的视频编解码器的附加信息可以在”IP/TVCODECs，File Transfer and Storage Requirement Considerations”(IP/TV编解码器，文件传输和存储要求考虑)(白皮书，2000年7月，http：//www.cisco.com/warp/public/cc/pd/mxsv/iptv3400/tech/ipcod wp.htm)(在下面称为[WP-CISCO])中找到。
颜色质量范围(color-quality-range)和整体质量范围(overall-quality-range)表示一个给定编解码器可用的单个帧的可能的压缩级别范围。视频数据所产生的压缩越高，则质量越低。在[Hand198]中，建议用0(最低质量)和10(最高质量)之间的数字表示质量，指示这应该是单帧的质量。可是，这种解决方案极少考虑存在的编解码器和将来即将开发的编解码器可能有10以上的压缩级别。如[Hand198]中所述的如此定义不满足上面定义的要求，因此提议了在0和10000之间的一个更宽的质量范围，在此0是最低质量而10000是最高质量。此范围应该被应用到颜色质量范围和整体质量范围。因为对于每一编解码器，单个帧的色度平面质量不相关，所以颜色质量范围应该被认为是可选的。
如下部分描述了一种考虑上面提出的要求的SDPng扩展提议，(为了简洁和清楚起见，在这篇文献中，我们遵循表示像代替转义版本(即对于”&”，为”& amp；″)由XML标准要求的”&”那样的字符的习惯)。关于这点，目的是定义对SDPng 912的模块化扩展。这可以通过在新的域名空间”e2enp”内引入一组新的部分来实现。所述新的部分可以被定义为一个新版本SDPng 912的一部分，或者定义在一个单独的SDPng912配置文件(称为E2ENP 908)中，包含如”XML Schema：Primer”、”XMLSchema：Structures”和”XML Schema：Datatypes”(W3C，2001)(在下面称为[XMLSC])中所述的相应的XML图解。这样一个新的E2ENP908配置文件因此将特写如下的一个报头：<xml：schematargetNamespace＝“http：//www.iana.org/sdpng/e2enp”xmlns：e2enp＝“http：//www.iana.org/sdpng/e2enp”       xmlns：sdpng：”http：//www.iana.org/sdpng”       xmlns：xsd＝“http：//www.w3.org/2001/XMLSchema”       elementFormDefault＝“qualified”       attributeFormDefault＝“unqualified”><xsd：import namespace＝“http：www.iana.org/sdpng”schema-location＝“sdpng.sd”/>
XML示例2
在任何情况下，因此建议对当前SDPng提议的一些改变(包括音频编解码器和RTP配置文件)，其被定义在D.Kutscher等人的”Session Description and Capability Negotiation”(会话描述和能力协商)(IETF互联网草案，未完工程，<draft-ietf-mmusic-sdpng-03.txt>)(在下面称为[SDPNG03])中。如果被接受，这些变化因此将影响原始SDPng 912(以及音频编解码器和RTP配置文件)XML图解。
关于是移到一个新版本SDPng 912还是定义它的扩展的判断被留下来讨论。
新的名称空间”e2enp”将在SDPng文献的根单元(即<desc>单元)中被指示。
首先，这个提议引入了一个新的SDPng部分<e2enp：purpose>的使用，根据上面提出的要求，按顺序唯一地识别与特定E2ENP 908阶段相关的SDPng内容。因为SDPng信息想要经由SIP 910标准方法搭载，所以，通过定义一个E2ENP 908基于SDPng的元协议，而不改变SIP 910的语义和语法，此方法允许扩展SIP 910的使用可能性。
此外，为了强制实施E2ENP 908特征，此提议：(i)定义了其他两个新的SDPng部分，<e2enp：qosdef>和<e2enp：qoscfg>，以及(ii)根据各个E2ENP 908阶段，在不同的时间经由不同的方法，允许经由搭载由SIP 910(或者其他信令会话103协议)独立地递送SDPng 912的各个结果部分。
这个提议对SDPng 912<cfg>部分引入了一些小变化，并对于包含在那个部分中的信息应该如何被链接到其它新的部分而提供详细的指导方针。
这个提议还修订了SDPng 912<constraints>部分语义，因为<e2enp：qoscfg>部分，它允许规定QoS相关性804和时间同步805限制并且早已覆盖大部分的相应特征。
此提议因此试图定义尽可能多的SDPng 912的模块化扩展，使得允许与不支持所述扩展的应用的简单互操作性。
SIP 910被定义为用于在对等体之间建立通信的一个信令会话103协议。它一般只考虑连接的开始、搁置使用和/或应用特定的特征。利用SDP或SDPng 912来描述这些特征。
在一些情况中，特别是考虑到从应用的观点来看，对于应用，需要具有一些关于如何处理通过SIP 910递送的SDP/SDPng信息的附加信息，协议运行象以模块化的方式一样。″模块化方式”不总是满足事件的ACID(原子性，一致性，绝缘性，持久性)特性，这就是为什么此SIP程序一般不应该被考虑一个事件。
因为E2ENP 908需要对等体中的三个不同的信息交换(即，端对端QoS协商802，端对端QoS协商806以及端对端QoS再协商808阶段)，所以需要在协议内部区分相应的程序。
SDPng 912能够明确地携带有关阶段类型、给定阶段的开始/停止和/或资源预留状态的信令，而与SIP 910(或者什么信令会话103协议被用于搭载SDPng信息)无关。就此而言，通过引入一个新的SDPng部分，在SDPng内容刚好开始时，一个基于SDPng的元协议作为PDU报头的形式将被定义来出现在所有与E2ENP相关的SDPng信息中。
如下示例示出了<e2enp：purpose>部分的一个可能实例：<e2enp：purpose>
<session user＝″Mary″session-id＝″2890844526″
       version＝″2890842807″nettype＝″IN″ad-
  drtype＝″IP4″
        addr＝″43.196.180.1″>
     <expires time＝″36000″/>
</session>
<use>
     <session user＝″Mary″session-id＝″2890843112″
     version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
     addr＝″43.196.180.1″/>
     <session user＝″Mary″session-id＝″2890843112″
     version＝″2890841001″nettype＝″IN″addrtype＝″IP4″
     addr＝″43.196.180.1″/>
</use>
<description
     type＝″request″
     name＝″pre-negotiation″
     mode＝″push″/></e2enp：purpose>
XML示例3
<session>单元唯一地识别在SDPng内容剩余部分中描述的给定E2ENP 908阶段。<session>单元的定义基于在[SDPNG03]中建议的<owner>单元。从<session>中导出(例如经由散列)简洁会话标识符的协商和使用以便限制E2ENPPDU的尺寸。<sessien>(具有一个计算出的散列)可被用于任何给定E2ENP阶段的第一个PDU或其级联中。
<expires>子单元表示与给定的<session>单元相应的SDPng信息多长时间被认为是有效的。响应于提议者810，每个应答者811将启动一个定时器，定时器被设置为<expires>单元中规定的数值。在此定时器期满时，应答者811将把相应的SDPng信息移动到一个”僵”状态中。反过来，在所述定时器期满之前提议者810将刷新给定的SDPng信息。
只有当再没有指示那个SDPng信息的媒体或信令会话102/103存在时，提议者810和/或应答者811才能够默默地舍弃所述”僵”信息。此基本原理还应用到指示给定的荒废SDPng信息的其它SDPng信息的情况(参见下一段)：只要指示给定”僵”信息的任何有效(即不处于”僵”状态)SDPng信息存在，则提议者810和/或应答者811不能默默地舍弃所述”僵”SDPng信息。
<session>单元所指的SDPng信息可被用于SDPng内容的其它情况中以便指代首选SDPng内容中定义的项目。经由<use>单元提供此机制，它允许创建一个首选项列表来了解<session>单元预先现有的情况。
例如，对于一个给定对等体对，通过在<e2enp：purpose>部分的<use>结构中表示那个预先协商信息的唯一<session>单元，则描述端对端QoS协商阶段806实例的SDPng内容将首选在前面预先协商的信息。此首选当然是不需要的(并且因此<use>单元将不存在)，相对于两个阶段的SDPng内容应该共同被搭载在一个SIP消息中(即在时间上连续执行的阶段情况)。
<expires>子单元在<use>部分内列出的<session>单元中的存在不是强制的。可是，如果存在，含意将与<expires>子单元的正常使用稍微不同：从首选它的<session>单元的观点来看，它的存在实际上将象征给定的首选<session>单元多长时间内应该被认为有效的(即，E2ENP会话有效性的剩余时间)。当然，在一个不比首选的会话103的<expires>子单元具体的时间初始值长的时间窗口内，一个给定<session>单元可以参考其他的。
<description>单元指示给定的<e2enp：purpose>部分所指的SDPng信息的性质。<description>单元的”类型”、”名称”和”模式”属性定义如下：类型：：＝“请求”|”响应”
“类型”属性识别一个给定E2ENP 908阶段的谁是提议者810以及谁是应答者811。名称：＝“标准”|”预先协商”|”协商”|”再协商”|”开始预留”|”准备预留”|”取消预留”|”已取消预留”|”期满”|”接管”
“名称”属性定义E2ENP 908阶段的类型，它的描述被包含在SDPng内容的剩余部分中：
·“标准”：根据M.Handley等人的”SIP 910：Session InitiationProtocol”(SIP 910：会话启动协议)(IETF SIP 910工作组，ACIRI，1999年3月，未完工程，<draft-ietf-sip-rfc2543bis-04.txt>)(在下面称为[SIPBIS04])，搭载此E2ENP 908内容的SIP消息的使用。
·“预先协商”802：搭载此E2ENP 908内容的SIP消息被用于执行端对端QoS预先协商阶段802。
·“协商”806：搭载此E2ENP 908内容的SIP消息被用于执行端对端QoS协商阶段806。
“再协商”808：搭载此E2ENP 908内容的SIP消息被用于执行端对端QoS再协商阶段808。
·“开始预留”：搭载此E2ENP 908内容的SIP消息被用于发信号开始预留过程(在端对端QoS协商806阶段期间或者在端对端QoS再协商阶段808期间)。
·“准备预留”：搭载此E2ENP 908内容的SIP消息被用于发信号完成预留过程(在端对端QoS协商806阶段期间或者在端对端QoS再协商阶段808期间)。
·“取消预留”：搭载此E2ENP 908内容的SIP消息被用于发信号请求释放预先保留的资源。
·“取消的预留”：搭载此E2ENP 908内容的SIP消息被用于确认预先保留的资源的释放。
·”期满”：搭载此E2ENP 908内容的SIP消息被用于强制实施由给定的<session>单元识别的SDPng信息的期满。上下文中，给定的<session>单元的<expires>子单元的属性时间将被设置为零。当这个命令被使用时，根据基本原理迫使基准给定的<session>单元的E2ENP908内容被释放。
·“接管”：这个命令在第三方协助协商806中被仲裁者106a1使用，用于向正在发生重定向的对等体通知：协商806正在重新定向到谁。
某些阶段应该是连接的，″名称”属性将只指示最近的阶段。″名称”单元的其它定义将来可以被考虑。模式：＝“推”|”拉”|”推拉”
“模式”属性表示协商809模式。这个属性只应用属性”名称”被设置为”预先协商”或”协商”。″类型”、”名称”和”模式”单元的缺省值分别为”请求”、”标准”和”推”。
<仲裁>参数是可选的，并且可以采用如下任何数值：仲裁：＝“第三方协助”|”外部协商”
如果它未被应用，则协商806的类型只不过是对等的。这个参数被用来指示一个对等体正在代表别人协商。这也将在SIP消息的报头”From”以及<purpose>部分的单元<session>上被暗示。代表别人协商的对等体通常应该被考虑像一个代理、会议服务等等的调解部分那样服务。仲裁者106a1使用参数仲裁以便通知协商各方：它不是要发送和/或接收的一方而只是调解协商806的一方。在这种情况下，仲裁者106a1应该使用作为它的功能”第三方协助”的指示。
每当登录网络运营者中时(在接通时间以及每当垂直切换发生时)，网络运营者将核实用户的QoS首选项(与终端能力已经匹配)与网络能力。
可是，在这个时候，仍然不可能预知是否以及何时那些情况出现：其中，两个端对等体没有机会商定无论什么的一个公共QoS合同组。在这种情况中，通常采用的一种解决方案是沿着数据路径插入代码转换单元。
把这些单元与SIP代理和目录服务联系起来的可能性被预想，使得迫使提议者使用一个特定的代码转换器，或者它的一条链路。
每当两个端对等体之间的E2ENP会话失败时，提议者可以尝试要求来自网络运营者或者任何其他服务提供者的支持，以便提供代码转换服务。
这意味着经由一个目录服务来发现任何可用代码转换器单元(组)，满足提议者给出的要求以及应答者的能力，并管理提议者、中间的各个代码转换器以及应答者之中的第三方协商。代码转换业务因此将与MEGACO现今实行的那样类似地使用E2ENP，MEGACO(“MediaGateway Control(MEGACO)″(媒体网关控制)，http：//www.ietf.org/html.charters/megaco-charter.html，在下面称为[MEGACO])。代码转换业务将改编对等体链路中的节点对，并看管经由E2ENP经济原理适当地预留资源(类似于资源释放的考虑)。
在两个终端用户之间的连接应该跨距多个管理领域和/或技术，再一次通过使用用于执行第三方协商的E2ENP，由不同提供者提供的代码转换服务也有可能合作。
就此而言，″外部协商”描述这种情况，其中，仲裁者106a1担当一个外部的第三方，代表试图迫使两个对等体在它们本身之间执行E2ENP的一个实体。如上所述的代码转换服务将协力控制一个或多个这样的”外部仲裁者”。
控制多个处理单元之间的路径建立的外部功能性的这种思想在各种文献中是很有名的(例如Z.M.Mao，R.Katz的”Achieving ServiceProtability in ICEBERG”(冰山中实现服务便携性)(in Proc.OfIEEE′00 Clobecomm Workshop”，”2000 IEEE Service Portabilityand Virtual”(2000 IEEE服务便携性和虚拟用户环境)IEEE，2000年12月)。因此所建议的解决方案的目的因此是允许把E2ENP协议的范围扩展到复杂的情况，从而要求类似代码转换器那样的中间组件。就此而言，由代码转换服务核心控制的多个E2ENP外部仲裁者的概念被认为是本发明建议的新颖性。
相对于与上面描述的那些不同的附加值，<mediation>单元可能经历未来的发展。如果仲裁者106a1在数据媒体流中的主动参与将被考虑，或者如果一个以上仲裁组件在协商806中将发生时，例如，会议控制单元、QoS代理等等的卷入，则这将经由<mediation>单元来指示。
如下示例对应于仲裁者106a1和未来的应答者106a2之间的E2ENP会话内的SIP会话的开始消息：
邀请sip：mary_fix@195.37.78.173
来源：sip：mary_moby@3ffe：1200：3012：c006：290：27ff：fe7d：d024
去往：sip：mary@fix@195.37.78.173
内容类型：application/sdpng/e2enp<e2enp：purpose>
<session user＝“Kate”session-id＝“2890844526”
version＝“2890842807”nettype＝“IN”addrtype＝“IP4”
addr＝“43.196.180.1”/>
<description type＝“request”name＝“negotiation”/>
<mediation mode＝“third-party-assisted”/></e2enp：purpose>
XML示例4
根据这个示例，对等体”marry_fix@195.37.78.173”将识别对等体”mary_moby@3ffe：1200：3012：c006：290：27ff：fe7d：d024”仅仅是所有者为”Kate”的对等体”43.196.180.1”的仲裁者106a1。
如[SIPBIS04]中所述的SIP响应”380备选服务”不但可能被使用来指示当前不能进行呼叫的那个业务的一个冗余业务，而且可能被使用于向另一设备重新定向一个连接--如果被呼叫的对等体没有能力处理该呼叫，但是可以利用使用一些分配和存在业务来检测在它附近地区内能够处理该呼叫的另一对等体。设备和服务的分配过程在本基础发明的范围之外，但是一般来说，如蓝牙系统规范版本1.1(http：//www.bluetooth.com/files/Bluetooth_11_Specific-ations_Book.pdf)(在下面称为[BLUE])中所述的类似蓝牙那样的现有技术，以及如J.Rosenberg等人的”SIP 910 Extensions forPresence”(存在的SIP 910扩展)(SIMPLE工作组，未完工程，<draft-rosenberg-impp-presence-01.txt>)(在下面称为[SIPPRE01])中所述的SIP 910的存在支持，可以被考虑。
根据[SIPBIS04]，″在响应的消息主体中”，备选服务被描述。描述一个备选服务的配置文件设定的地址和首选项的一种可能SDPng912结构在下面被示出：
<e2enp：alternative-service type＝[TYPE]>
     <service>
          <service-id id＝″my-funny-service″
                    protocol＝″SIP″
                    version＝[SIP VERSION]
                    address＝[SIP ADDRESS]/>
           <session user＝″Mary″session-id＝″2890843112″
               version＝″2890841393″nettype＝″IN″ad-
               drtype＝″IP4″addr＝″195.37.78.173″/>
      </service>
 </e2enp：alternative-service>
XML示例5
其中
TYPE            类型＝“标准”|”仲裁”，
                -″标准”-如[SIPBIS04]中定义的标准使用，
                -″仲裁”-用于仲裁目的。
SIP_ADDRESS     对应如[SIPBIS04]中定义的SIP一致地址的格式，和
SIP_VERSION     对应如[SIPBIS04]中定义的SIP 910的SIP一致版本语法。
部分<service>被用来描述备选服务，是指已经知道的E2ENP消息会话描述112或在它们内被携带。许多这些携带的描述用<purpose>部分来开始。从而，部分<service>可以被重复。
在仲裁的情况下，多个<service>部分可以具有相同的<service-id>但是地址不同的会话描述，因为仲裁者106a1将通知提议者106b和未来的应答者106a2有关仲裁者106a1一方面与提议者106b执行另一方面与未来的应答者106a2执行的相应协商，而不必处理如仲裁者要求中所述的未知信息。
如果该使用是根据[SIPBIS04]的标准，则多个<service>部分描述多个备选服务。
部分<alternative-service>的当前描述只是在E2ENP和调解的协商的感测中。当SIP启用的服务被考虑时将来将考虑如[SIPBIS04]所定义的在感测中<alternative-service>的使用的另外描述。<e2enp：alternative-service type＝″ediation″>
 <service>
      <service-id id＝″my-funny-service″protocol＝″SIP″
           version＝″SIP/2.0″
           address＝″sip：mary_fix@195.37.78.173″/>
      <session user＝″Mary″session-id＝″2890843112″
           version＝″2890841393″nettype＝″IN″
           addrtype＝″IP4″addr＝″195.37.78.173″/>
 </service></e2enp：alternative-service><e2enp：purpose>
 <session user＝″Mary″session-id＝″2890843112″
         version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
         addr＝″195.37.78.173″/>
 <mediation mode＝″third-party-assisted″/></e2enp：purpose>
XML示例6
根据仲裁者106a1的要求，禁止使用对未知会话的首选项。那就是为什么通过实现仲裁者，来自<service>部分中的、所涉及会话内的<purpose>部分的<use>单元应该像上面的示例中那样被省略。仲裁者然后应该考虑收集所有涉及的信息并把它明确(没有参考)放入当前的描述(组)中。
图10展现了示出所谓的<e2enp：alternative-service>部分的使用的示例。
在<service-id>单元内第三消息中的地址和版本的指示可以直接被提议者106b(Kate的设备)使用来创建对新的应答者106a2(Mary的家庭终端)的新SIP 910呼叫。在提议者106b不知道呼叫正被重新定向到的那个移动设备时的情况下特别需要此信息。
与存在的SDPng提议[SDPNG03]相比，因此建议来区分编解码器定义与RTP有效裁荷类型定义和编解码器参数化。对于编解码器参数化，我们因此计划伴随一个给定编解码器定义的参数列表，例如，在音频编解码器的情况下抽样速率和信道数量。这导致一个新的SDPng部分的定义，以及音频编解码器和RTP配置文件的重新定义。
利用这个假设，通过首先删掉不被所有对等体支持的所有编解码器，协商各方可以快速收敛在协议上。一旦共同商定的编解码器组已经被识别，则作为进一步的一个步骤，协商各方可以处理有效载荷类型和编解码器参数化的协商806。有效载荷类型定义在[RTP-Profile]中被描述，并且RTP配置文件在[SDPNG03]中被定义。
关于音频编解码器，静态有效载荷类型与固定编解码器参数化相关，如[SIPBIS04]中所定义的：因此，只有对于动态的有效载荷类型，需要编解码器参数化的一个详细规范。就此而言，我们建议使用]中如[SDPNG03]中所述的同轴格式。
关于视频编解码器，从QoS观点来看，在[RTP-Profile]中指示的参数化不足以完全表示给定编解码器的特征。两种可能的解决方案被预想：
1.在任何用户特定的预先协商802之前，预先协商名称，有效载荷类型以及(部分地)编解码器的参数化：这意味着把端对端QoS预先协商802阶段分成两个分离的子阶段：在初期阶段，只有与终端相关的信息的预先协商802将发生；这个子阶段然后后面跟着一个(或多个)用户特定的预先协商802子阶段，它在稍后时间平衡用户配置文件信息，其中，这些稍后的子阶段每一个都将把用户配置文件信息映射到前一子阶段的结果。在终端相关的预先协商802子阶段中还要预先协商编解码器参数化的原因源自于这个事实：即，协商每一方可能想要相对于给定对等体的硬件/软件资源总量而向下变窄视频编解码器的可能配置范围，使得符合可行性要求。
2.可替代地，确定用户配置文件的哪些子集与给定能力以及本地资源的(可能)数量匹配，并且只协商与对等体以及编解码器名称和有效载荷类型的那些子集。
在图11中描述的图中说明了两个备选。在只协商编解码器的情况下，″用户级别QoS”不存在，并且”QoS合同草图”等于”系统配置文件”。分别地，对于这样一种情况，只有系统能力将被核实。遵循此基本原理，可以以一种简单的方式设计应用：它们处理初期子阶段中的编解码器参数化协商806，或者它们只须处理用户特定的QoS规范的协商806。
编解码器描述可以被对等体能够在它们本身之中离线预先协商的一般用途的能力描述所同化。预先协商信息还可以是指和/或被结合到如[SDPNG03]中所述的SDPng 912配置文件中。
此外，原始SDPng 912编解码器参数化中的间隔将被引入以便减少协商的项目数。特别相对于视频媒体流206特性，此方法还以一种直觉的方式以及避免含糊来允许适配路径的定义。
一种新的SDPng 912<e2enp：qosdef>部分提供用于以模块化的方式表示能力和流级别QoS合同1108的装置：
-用设置为”capabilities”(能力)的属性”name”(名称)限制的<e2enp：qosdef>部分的一个实例只描述关于能力的与终端相关的信息，而
-用设置为”contracts”(合同)的属性”name”(名称)限制的<e2enp：qosdef>部分的实例描述那些能力的各个参数化，其就流级别QoS合同1108方面匹配给定的用户配置文件信息。
应用和/或媒件将选择预先协商<e2enp：qosdefname＝“capabilities”>之外的最佳编解码器，以及给定用户配置文件信息之外的QoS合同1108的子集。结果信息(<e2enp：qosdef name＝“capabilities”>和用户配置文件信息的交叉结果子集)将然后形成<e2enp：qosdef name＝“contracts”>部分，它处理在应用层的流级别QoS合同1108。这个新的部分不同于包含在用户配置文件信息中的原始信息，在此范围，特定的编码属性现在被规定。此<e2enp：qosdef name＝“contracts”>部分然后将在预先协商802阶段期间在对等体之中被交换。图11示出了一个方案1100，其中从用户配置文件和系统配置信息中导出QoS合同1108。在那之后，它们被核实。
两种类型的<e2enp：qosdef>部分的预先协商802可以在不同的时间发生在对等体之间，与稍后实际的使用无关，并且通过使用与给定的<e2enp：qosdef>部分相关的目的部分的<expires>单元，在时间上以不同的时间度量被规划。在E2ENP 908信息有效时间需要限制，以便避免在稍后时刻使用荒废的信息。
<e2enp：qosdef name＝“capabilities”>部分允许对等体商定在稍后媒体会话102期间要使用的公共能力子集。这个部分担当应用到每个类型媒体(音频，视频等等)的两种类别单元的存储器，编解码器定义和有效载荷类型定义。来自在[SDPNG03]中规定的原始音频编解码器、RTP和视频编解码器配置文件的定义被预想使用，但是具有某些扩展，如下所示。<e2enp：qosdef name＝“capabilities”>
<audio：codec name＝“PCMU”scope＝“applicable”/>
<audio：codecname＝“G729”scope＝“applicable”/>
<audio：codecname＝“G722”scope＝“possible”/>
<audio：codecname＝“L16”scope＝“possible”/>
<rtp：ptname＝“rtp-avp-0”pt＝“0”format＝“PCMU”/>
<rtp：ptname＝“rtp-avp-18”pt＝“18”format＝“G729”/>
<rtp：ptname＝“rtp-avp-9”pt＝“9”format＝“G722”/>
<rtp：ptname＝“rtp-avp-10”pt＝“10”format＝“L16”/>
<rtp：ptname＝“rtp-avp-11”pt＝“11”format＝“L16”/>
<video：codecname＝“H263”scope＝“applicable”/>
<video：codec name＝“H261”scope＝“applicable”/>
<video：codecname＝“MPV”scope＝“possible”/>
<video：codecname＝“MP2T”scope＝“possible”/>
<rtp：ptname＝“rtp-avp-34”pt＝“34”format＝“H263”/>
<rtp：ptname＝“rtp-avp-31”pt＝“31”format＝“H261”/>
<rtp：ptname＝“rtp-avp-32”pt＝“32”format＝“MPV”>
   <video：codec frame-rate-range＝“30，30”
                frame-size-set＝“SIF”
               color-quality-range＝“ 0，10000”
               overall-quality-range＝“0，10000”/>
</rtp：pt>
<rtp：ptname＝“rtp-avp-33”pt＝“33”format＝“MP2T”>
  <video：codec frame-rate-range＝“30，30”
               frame-size-set＝“720×576”
               color-quality-range＝“0，10000”
               overall-quality-range＝“0，10000”
               overall-quality-range＝“9500，9800”/>
</rtp：pt>
<rtp：ptname＝“rtp-avp-100”pt＝“100”format＝“WAVI”>
   <video：codec frame-rate-range＝“5，30”
                 frame-size-set＝“QCIF，CIF”
                 color-quality-range＝“9100，10000”
                 overall-quality-range＝“9100，10000”/>
</rtp：pt>
</e2enp：qosdef>
XML示例7
为了简洁，这个示例示出了有编解码器参数化和没有编解码器参数化的视频编解码器的定义。换句话说，<e2enp：qosdefname＝“capabilities”>部分将包含编解码器参数化或者不包含它们。
人们可以很容易注意到：在这个部分中传送的信息现在与用户终端设备的一种配置文件等效。这个信息是用户独立的，并因此对用户配置文件信息中描述的用户配置文件信息内容补充，以及对处理流级别QoS合同1108的<e2enp：qosdef>部分(从所述用户配置文件信息中导出)的内容补充。
属性”范围”在一个请求(协商提议)中指示相应SDPng 912单元是否要被认为是所要求的(可应用)或者期望(可能的)选项。然而在响应(协商反提议)中，那个属性指示是否相应SDPng 912单元已经被核实(可应用)或者已经被拒绝(不可应用)。范围：″不可应用”|”可应用”|”可能的”
应答者811也可以在反提议中指示它可以提供什么能力，以及提供到什么程度。如果一个给定能力”as is”(像那样)被支持，则只有相应标识符被指示，并且范围属性设置为”applicable”(可应用)。如果一个给定能力不被支持，则相应标识符被简单地省略。
如果应答者811在反提议中在<e2enp：qosdefname＝“capabilities”>部分中建议给定能力的参数化的一个修改版本(作为原始请求子集)，则在两个类型的<e2enp：qosdef>部分中返回更新了的整个描述。在任何情况下，处理流级别QoS合同1108的<e2enp：qosdef>部分在一个响应中只包含更新的编解码器参数化。
另外，应答者811可以指示一个新的选项(对提议者810来说在预先协商802时刻是未知的)：这将被标记为”possible”(可能的)。这种思想是：提议者810因此能通知一个可能的选项，所述选项稍后能够被最终使用，提议者810将用与那个选项匹配的新能力升级。
例如，应答者811可能指示一个编解码器的支持，提议者810当前不支持所述编解码器。提议者810将以某种方式获得那个给定编解码器(例如通过下载软件组件)，提议者810能因此升级它的策略以便考虑此新能力。
值”possible”(可能的)还可以指示应答者811的状态，其相对于提议者810所建议的编解码器，处于部分忙碌中。用这种方式，应答者811可以考虑它的当前工作负载。这例如能够在对提议者810的应答中转换，来指示应答者811通常具有大容量但是此刻它只有一部分可用。提议者810然后可以保存此信息，不论何时尝试升级所述连接以便用不同的QoS级别工作时，用于未来的再协商808。
在一个稍后时刻能力被删除或者重新配置，相应的<e2enp：qosdefname＝“capabilities”>预先协商802过程的一个新的实例将发生在对等体之中，以便预先积极地并且及时地传播关于该给定变化的信息，以使对等体能够使用适当的适应策略。
如果应答者811把一个能力增加为”possible”(可能的)，在与那个新的能力相应的单元中，相应的参数化将在<e2enp：qosdefname＝“capabilities”>部分中直接被返回。在这种情况下，参数化只须指示相对于那个能力的配置信息。在稍后时刻，提议者810应该用此额外的能力升级，提议者810可以从配置信息中引出一些合同1108用于运行新一轮预先协商802过程。
上述处理后，任何时候，对等体还可以再协商能力以便彼此通知有关能力有效性中的任何改变。
继续上面的示例，下列代码分段显示了在从前一段落中描述的映射过程中导出的新<e2enp：qosdef name＝“contracts”>部分中的编解码器参数化示例。这个部分处理应用层QoS合同1108，它通常可应用到被识别媒体类型的任何媒体流206。
此新的部分包含若干复杂的XML单元：一个委托的<policy>单元，用于协商强制实施的资源管理策略；至多任何下列单元的一个实例：
-<音频>：描述音频媒体流206的所有QoS合同1108
-<视频>：描述视频媒体流206的所有QoS合同1108
-<数据>：描述数据媒体流206的所有QoS合同1108
-<控制>：描述控制媒体流206的所有QoS合同1108，
在此，这种QoS合同1108从用户配置文件信息与能力的映射中导出。这些单元中至少一个将被呈现。<e2enp：qosdef name＝″contracts″>
 <policy name＝″Let us optimize((memory && network)||CPU)″>
       <predicate id＝″predicate-1″
        first-term＝″optMemoryUsage″
          second-term＝″optNetworkPerformance″
        function＝″and″/>
       <predicate id＝″predicate-2″
        first-term＝″predicate-1″
          second-term＝″optCpuLoad″
        function＝″or″/>
       <criterion type＝″expression″idref＝″predicate-2″/></policy><audio>
 <contract name＝″audio-contract-1″
 sampling-rate-set＝″4000，8000″channel-set＝″1″/>
 <contract name＝″audio-contract-2″
 sampling-rate-set＝″8000，12000″channel-set＝″1，2″/>
 <contract name＝″audio-contract-3″
 sampling-rate-set＝″12000，16000″channel-set＝″1″/>
 <contract name＝″audio-contract-4″
 sampling-rate-set＝″16000，44100″channel-set＝″1″/>
 <contract name＝″audio-contract-5″
 sampling-rate-set＝″44100，64000″channel-set＝″2″>
      <spare/>
 </contract>
 <rtp：map contract＝″audio-contract-1″
 format＝″rtp-avp-0″role＝″receiver″/><rtp：map contract＝″audio-contract-2″format＝″rtp-avp-18″role＝″receiver″/><rtp：map contract＝″audio-contract-3″format＝″rtp-avp-9″role＝″receiver″/><rtp：map contract＝″audio-contract-4″format＝″rtp-avp-10″role＝″receiver″/><rtp：map contract＝″audio-contract-4″format＝″rtp-avp-11″role＝″receiver″/>
<rtp：map contract＝″audio-contract-5″
format＝″rtp-avp-125″role＝″receiver″/></audio><video>
 <contract name＝″video-contract-1″
 frame-rate-set＝″10，15″frame-size-set＝″CIF″
 color-quality-range＝″9100，9700″
 overall-quality-range＝″9500，9800″/>
 <contract name＝″video-contract-2″
 frame-rate-set＝″15，20″frame-size-set＝″QCIF″
 color-quality-range＝″9700，9850″
 overall-quality-range＝″9800，9900″/>
 <contract name＝″video-contract-3″
 frame-rate-set＝″20，25″frame-size-set＝″QCIF，CIF″
 color-quality-range＝″9850，9900″
 overall-quality-range＝″9900，9960″/>
 <contract name＝″video-contract-4″
 frame-rate-set＝″25，30″frame-size-set＝″CIF″
 color-quality-range＝″9900，9970″
 overall-quality-range＝″9960，9990″/>
      <contract name＝″video-contract-5″
      frame-rate-set＝″30″frame-size-set＝″720×576″
      color-quality-range＝″9000，10000″
      overall-quality-range＝″9000，10000″/>
      <rtp：map contract＝″video-contract-1″
      format＝″rtp-avp-31″role＝″receiver″/>
      <rtp：map contract＝″video-contract-1″
      format＝″rtp-avp-34″role＝″receiver″/>
      <rtp：map contract＝″video-contract-1″
      format＝″rtp-avp-100″role＝″receiver″/>
      <rtp：map contract＝″video-contract-2″
      format＝″rtp-avp-31″role＝″receiver″/>
      <rtp：map contract＝″video-contract-2″
      format＝″rtp-avp-34″role＝″receiver″/>
      <rtp：map  contract＝″video-contract-2″
      format＝″rtp-avp-100″role＝″receiver″/>
      <rtp：map contract＝″video-contract-3″
      format＝″rtp-avp-31″role＝″receiver″/>
      <rtp：map contract＝″video-contract-3″
      format＝″rtp-avp-34″role＝″receiver″/>
      <rtp：map contract＝″video-contract-3″
      format＝″rtp-avp-100″role＝″receiver″/>
      <rtp：map contract＝″video-contract-4″
      format＝″rtp-avp-31″role＝″receiver″/>
      <rtp：map contract＝″video-contract-4″
      format＝″rtp-avp-34″role＝″receiver″/>
      <rtp：map contract＝″video-contract-4″
      format＝″rtp-avp-100″role＝″receiver″/>
      <rtp：map contract＝″video-contract-5″
      format＝″rtp-avp-33″role＝″receiver″/>
 </video></e2enp：qosdef>
XML示例8
颜色质量范围(color-quality-range)和整体质量范围(overall-quality-range)的描述在上面被介绍。在这种情况下，frame-rate-set＝“10，15”是指接收者应该至多能够解码15Fr/s以及至少10Fr/s。导致不足10Fr/s的任何解码被认为是合同1108的妨碍。除非合同变化，否则发送者不需要支持15Fr/s以上，因为，例如，发现在接收者端的更多资源，并且实行一个合同变化的请求。
<policy>单元传送协商策略的类型。″名称”属性提供人类可该的策略描述。可选<predicate>子单元允许表示包括两个项目的一个布尔值判定，每一个从如下设置中引出：
“optMemoryUsage”-指示存储器使用最优化策略。
“optNetworkPerformance”-指示网络604能力最优化策略。
“optPowerConsumption”-指示功耗最优化策略。
“optCpuLoad”-指示CPU载入最优化策略。
将来可以附加与其它策略相应的另外的数值。
可替代地，判定项目的数值可以从<predicate>单元的其它实例(instance)组中引出。布尔值函数的类型经由”function”(函数)属性来指示，它可以采用”and”、”or”组之外的任何值。″not”函数未被使用，因为一个策略不存在，就隐含指示这样一个策略未被使用。<predicate>子单元从而允许规定上面列出的基本策略的组合。这些组合表示在各个策略之间特定的相关性。
<criterion>子单元经由”type”(类型)属性识别一个给定的策略，它可以采用如上所述的组之外的任何值。此外，通过把串”expression”(表达式)规定为属性”type”(类型)的值，并且通过使用识别<predicate>单元给定实例的另外一个属性”idref”，则此单元的一个实例可以强制实施<predicate>单元的实例。<criterion>子单元是委托，并且只有它的一个实例能够出现在<policy>单元的一个给定实例内。
<contract>单元表示交叉结果过程的结果。那些用户1101与可用能力匹配的应用层QoS要求因此从用户1101的用户配置文件信息中被拷贝，并且在对等体之间被协商。它因此可能导致在协商806过程结束时，用户1101的原始应用层QoS要求向下缩小到它的一个子集。
相对于上面提出的要求以及备用合同的概念，<contract>单元的<spare>子单元因此被引入来指示那些备用合同，那些备用合同不由给定用户的优选网络提供者所提供。
<spare>子单元然后将是一个可选的单元，并且它的存在指示给定合同1108将不由提议者810的优选网络604运营商所提供。应答者811基于她/他与她/他的优选网络604运营商的协议，类似地把不指示的那些滤除为不备用。
当一个垂直切换发生时，任一一方可以努力核实包括备用的在内的所有她/他的合同1108，其最后可能相对于新的网络提供者和/或新类型的接入网络604而变成可应用的。
<rtp：map>单元被建议为SDPng 912RTP配置文件[SDPNG03]的一个扩展，来表示给定应用层QoS合同1108与一个特定格式的关联。有效载荷类型由”format”(格式)属性规定，它参考<rtp：pt>单元的”name”(名称)属性的实例。
属性”contract”(合同)通过参考<contract>单元的”name”(名称)属性的实例来识别相关的应用层QoS。
属性”role”(角色)指示给定的关联应用层QoS合同/流格式按照上面提出的要求，是由一个接收者、发送者还是发送者/接收者来建议。用这种方式，不但接收者而且发送者可以预先积极地传播信息，这些信息稍后基于AP将用于决定如何处理再协商808。
可以通过引入一新的部分<e2enp：qoscfg>作为<cfg>部分的一个补充来形成QoS环境和媒体流206编组(以及，更明确地，关联)的概念。更明确地，<e2enp：qoscfg>部分包含一个给定媒体流206的适配路径(AP)描述，以及它的关联(或者更通常来讲，编组)的定义。较高级QoS合同1108获得媒体流206各个组之中的QoS相关性804和时间同步805限制以及它们的(较高级别)AP，所述较高级QoS合同1108还可以用这个新的部分规定。
包含在<e2enp：qoscfg>部分中的信息可以在对等体之中被预先协商，而与稍后的实际使用无关；或者在连接建立期间被协商。
在E2ENP 908思想的环境内，SPDng原始<cfg>部分的范围需要被澄清：<cfg>部分只是用与传送相关的信息定义格式映射(例如RTP有效载荷类型)；然而AP的完整定义(就定义在<e2enp：qosdef>部分中的能力和QoS合同1108方面)完全由新的<e2enp：qoscfg>部分提供。
在此提议和[SDPNG03]之间的唯一区别是，在<rtp：session>单元中另外属性的引入，用于规定哪一类型和版本的网络604被使用(分别地，”nettype”和”addrtype”属性)。这个变化也影响SDPng 912RTP配置文件[SDPNG03]。此外，通过使用在S.Olson、G.Camarillo和A.Roach的”Support for IPv6 in SDP”(SDP中IPv6的提供)(IETF互联网草案，未完工程，<draft-olson-sdp-ipv6-02.txt>)(在下面称为[Olson01])中为SDP所建议的语法来表示SDP地址。<cfg>部分的所建议的SDPng 912扩展在下面示例中的以粗体外观的形式被指示。<cfg>
<component name＝″audio-stream-1″
media＝″audio″>
     <alt name＝″AVP-audio-0″>
          <rtp：session format＝″rtp-avp-0″>
                <rtp：udp role＝″receive″
                 nettype＝″IN″
                 addrtype＝″IP4″
                 addr＝″43.196.180.1″
                 rtp-port＝″7800″
                 rtcp-port＝″7801″/>
          </rtp：session>
     </alt>
     <alt name＝″AVP-audio-18″>
          <rtp：session format＝″rtp-avp-18″>
            <rtp：udp role＝″receive″
             nettype＝″IN″
             addrtype＝″IP4″
             addr＝″43.196.180.1″
             rtp-port＝″7800″
             rtcp-port＝″7801″
      </rtp：session>
 </alt></component>  <component name＝″video-stream-1″me-   dia＝″video″>
   <alt name＝″AVP-video-34″>
        <rtp：session format＝″rtp-avp-34″>
              <rtp：udp role＝″receive″
               nettype＝″IN″
               addrtype＝″IP4″
               addr＝″43.196.180.1″
               rtp-port＝″7900″
               rtcp-port＝″7901″/>
        </rtp：session>
   </alt>
   <alt name＝″AVP-video-31″>
        <rtp：session format＝″rtp-avp-31″>
              <rtp：udp role＝″receive″
               nettype＝″IN″
               addrtype＝″IP6″
               addr＝″3ffe：1200：3012：c006：290：27ff：fe7d：d024″
               rtp-port＝″7920″
               rtcp-port＝″7921″/>
        </rtp：session>
   </alt>
   <alt name＝″AVP-video-98″>
        <rtp：session format＝″rtp-avp-98″>
              <rtp：udp role＝″receive″
                  nettype＝″IN″
                  addrtype＝″IP6″
                  addr＝″∷ffff：43.196.180.15″
                  rtp-port＝″7940″
                  rtcp-port＝″7941″/>
      </rtp：session>
 </component></cfg>
XML示例9
请注意用于规定与两个不同有效载荷类型相关的一个给定地址/端口对的<cfg>部分的使用，它的选择根据AP规则和<e2enp：qosdefname＝“contracts”>部分的<rtp：map>单元中所述的映射，取决于哪一QoS合同1108(<e2enp：qoscfg>部分之外)被强制实施。
在这个提议与传统SDP和SDPng 912之间的区别在于：后者基本不集中在QoS协商806上，而是集中在能力协商806上。这意味着SDP/SDPng 912允许发送者向接收者(组)给出有关发送者打算用于发送的格式和传送信息的信息。
为了尽力把E2ENP 908与此熟知的方法匹配，人们应该注意：在端对端QoS预先协商阶段802已经考虑了绝对的能力协商806。实际上，预先协商802阶段通常可以被认为用于仅仅指示对等体当发送和接收时可能都想要使用的流级别QoS合同1108。更明确地，<e2enp：qosdef name＝“contracts”>部分的<rtp：map>单元的属性”role”(角色)允许那么做。
可是，这两个同音异义的属性处理两个不同的方面：使用于<e2enp：qosdef name＝“contracts”>部分中的”role”(角色)属性允许接收者也基于发送者传播的信息/首选项来表达AP和高级QoS合同/AP。然而正如前述的，<cfg>部分的”role”(角色)属性只允许应用/媒件配置本身适当地使用媒体流206(就能力和传送方面方面)。
<e2enp：qoscfg>部分允许在各个抽象层定义AP以及QoS相关性804和时间同步805限制，从流级别QoS合同1108开始。每个抽象层由这个部分中的属性”name”(名称)来识别。
这个部分在流级别的一个示例在下面的XML文献分段中被指示。  <e2enp：qoscfg level＝″stream″>
   <！--adaptation path for single media streams 206-->
   <adapath name＝″audio1″ref_component＝″audio-stream-1″>
        <default name＝″nominal″
        ref_contract＝″audio-contract-1″/>
        <alt name＝″choice1″
        ref_contract＝″audio-contract-2″/>
   </adapath>  <adapath name＝″video1″ref_component＝″video-stream-1″>
   <default name＝″nominal″
    ref_contract＝″video-contract-1″/>
    <alt name＝″choice1″
    ref_contract＝″video-contract-2″/>
    <alt name＝″choice2″ref_contract＝″video-contract-3″
    />
    <event id＝″video1-e-1″reason＝″higher-frame-rate″>
         <path name＝″upgrade-1″
            guard＝″.ge.15.and..le.20″
            source＝″video-contract-1″
            target＝″video-contract-2″/>
       <path name＝″upgrade-2″
            guard＝″.ge.20″
            source＝″video-contract-2″
            target＝″video-contract-3″/>
  </event>
  <event id＝″video1-e-2″reason＝″lower-frame-rate″>
       <path name＝″degrade-2″
            guard＝″.ge.15.and..le.20″
            source＝″video-contract-3″
            target＝″video-contract-2″/>
       <path name＝″degrade-2″
            guard＝″.le.15″
            target＝″video-contract-1″/>
 </event></adapath><！--Possible associations of media streams 206 betweenuser A and B--><context name＝″association1-1″scope＝″applicable″>
 <comp name＝″element1″ref_adapath＝″audio1″/>
 <comp name＝″element2″ref_adapath＝″video1″/>
 <constraints>
              <par name＝″lipsync-delay″ref_adapath＝″audio1″
                       max＝″2″/>
              <par name＝″aggregated-bw″max＝″64000″/>
         </constraints>
    </context>
    <context name＝″association1-2″scope＝″possible″>
         <comp name＝″element1″ref_adapath＝″audio1″/>
    </context>
     <adapath name＝″associations-A-B″>
          <default name＝″nominal″
          ref_context＝″association1-1″/>
          <alt name＝″choice1″ref_context＝″association1-2″/>
     </adapath>
</e2enp：qoscfg>
XML示例10
如下子段落详述了出现在这个部分中的每个单元。
通过收集从<qosdef name＝capabilities”>部分的<contract>单元组中引出的、并且只与接收者相关的一组互斥流级别QoS合同1108(根据上面提出的要求)，出现在上面示例中的<adapath>单元的开头两个实例允许定义两个分离的适配路径。经由”ref_component”属性，每个<adapath>单元与<cfg>部分的一个特定<component>相关。这个属性只对于描述流级别AP的<adapath>单元是委托的。
每个QoS合同1108是AP中的一个备选选项：因此，用于定义它们的<alt>结构的使用(alt代表备选)。通过假设上述的分层FSM模型，这些AP的每一个表示一个独立的FSM，它的初始状态由给定的<adapath>结构的单元<default>来明确指示。
通过假设上述的分层FSM模型，通过例如使用S.Bhatti和G.Knight的”Enabling QoS adaptation decisions for Internetapplications”(启动互联网应用的QoS适配判定)(London/UK，1999)(在下面称为[Bhatt99])以及[BRAIN]中所述的模糊逻辑，通过把监视的QoS级别与在给定AP中定义的QoS合同1108组匹配，则可以动态地确定从给定AP内的一个QoS合同1108转换到另一个的选择。可替代地，<adapath>结构可以包括那些QoS合同1108之中的状态转移的一个预定义组：在这种情况下，<event>结构表示：在检测到类似像上面示例中的帧速率增加或者帧速率降低这样的给定事件之后，哪一转移将应被触发。这些事件指明熟知的监视通知，其应用和/或媒件可以被设计来考虑。就此而言，事件的名称和语义二者都将受到标准化。一个给定<event>可以与多个路径相关，它们的触发确定将被激活的那一个。
个体转移在<path>结构中被描述，它描述了触发情形(被指示为防护参数)和包含在转移中的QoS合同1108(用源和目标属性来指示)。<path>结构中的源属性是可选的，在此范围，可能有那个属性规范会被故意省略的情况。在那些情况中，实际上，相应的转移将发源于给定分层FSM当前被设置的任何一个状态。用这种方式，能够在一个给定组内把任何QoS合同1108的变化模拟为在触发相应的转移情况下被定义的一个(一种缺省机制)。在上面的示例中，通过一个较低帧速率(参见<reason>属性)的检测所触发的事件<video1-e-2>，将迫使被称为video1(视频1)的<adapath>结构所描述的FSM来强制实施video-contract-1(视频合同1)，而无论在那个事件被抛出的那个时刻哪个合同1108被强制实施。为了实现互操作性，应该注意：对等体应该商定原因(reason)属性的语义。在上面的示例中出现的类似”higher-frame-rate”(较高帧速率)或者”lower-frame-rate”(较低帧速率)那样的术语以及它们的含意因此应该受到标准化。转移组的这个预先定义是可选的。
属性”scope”(范围)指示在一个请求(协商提议)中相应SDPng912单元是否要被认为是所要求的(可应用)或者期望(可能的)选项；然而在响应(协商反提议)中，那个属性指示是否相应SDPng 912单元已经被核实(″可应用”)或者已经被拒绝(″不可应用”)。范围：″不可应用”|”可应用”|”可能的”
应答者811也可以在反提议中指示它可以提供什么能力，以及提供到什么程度。
如果一个给定能力”as is”(像那样)被提供，则只有相应标识符被指示，并且范围属性设置为”可应用”。如果一个给定能力不被提供，则相应标识符被简单地省略。
如果应答者811在反提议中在<e2enp：qosdef>部分中建议给定能力的参数化的一个修改版本(作为原始请求子集)，则在两个<e2enp：qosdef name＝“capabilities”>和<e2enp：qosdefname＝“contracts”>部分中返回更新了的整个描述。在任何情况下，<e2enp：qosdef name＝“contracts”>部分在一个响应中只包含更新的编解码器参数化。
另外，应答者811可以指示一个新的选项(对提议者810来说在预先协商802时刻是未知的)：这将被标记为”可能的”。这种思想是：提议者810因此能通知一个可能的选项，所述选项稍后能够被最终使用，提议者810将用与那个选项匹配的新能力升级。
<context>单元定义给定媒体流206的可能关联，从而允许定义时间同步805和QoS相关性804限制。如此，<context>单元主要描述了高级QoS合同1108。
在上面的示例中，视频媒体流206和音频媒体流206，和所定义的两个时间同步和QoS相关性804规范一起，在给定的环境(″关联1-1”)中被定义为相关。可替代地，还可以被使用只包括音频媒体流206(″关联1-2”)的一个环境。
在出现在上面示例中的<adapath>单元的第二实例中描述何时以及如何实施强制任一环境。在这种情况下，<default>单元的使用很明显：音频媒体流206和视频媒体流的组合(″association1-1”(关联1-1))被指示为优选的一个。只使用音频媒体流(″association1-2”(关联1-2))的情况然后将被认为是一种备份情况，它可以被强制实施以便应付例如QoS妨碍。<adapath>单元的个体子单元经由”ref_context”属性来参考前述的<context>单元的实例。
作为一个总的规则，人们因此会注意到在非循环首选项链路中彼此参考的<adapath>和<context>单元的返回出现。备选<context>结构被编组在定义FSM的一个<adapath>结构中。这个AP和任何其它(并行的)的能因此接着被卷入一个<context>结构内，这在一个较高的级别设置限制。而且，还有备选来定义这些<context>结构，它能因此在一个更高级别AP中被收集。此过程可以被递归应用。
一个给定用户能够强制实施较高级QoS相关性804和时间同步805限制--作为扩展的用户配置文件信息的形式--以便通过与不同对等体建立的给定媒体流206组来改编资源应用(和因此的QoS)。就此而言，给定用户不需要与对等体协商此信息。
可是，如果给定用户要求在稍后一个时刻强制实施一些新的限制，或者发现先前存在的限制不再能够被满足，由于把一些对等体稍后加入到当前开放的电信会话102/从当前开放的电信会话102中留下一些对等体，则根据给出的会议策略，可能需要新一轮E2ENP 908(这在本基础发明的范围之外)。
最后，对等体也可以凭借第三方实体管理预先协商802、协商806和再协商808(″完整”的)，包括关于QoS相关性804和时间同步805方面的较高级别规范。此实体将担当如下文献中所述的一种QoS代理，所述文献为T.Robles、A.Kadelka、H.Velayos、A.Lappetelainen、A.Kassler、H.Li、D.Mandato、J.Ojala和B.Wegmann的”QoS Support for an All-IP System Beyond 3G”(超过3G的所有IP系统的QoS提供)(IEEE通信杂志，2001年8月，第39卷，No.8)(在下面称为[Roble01])以及[BRAIN]，它们在本基础发明的范围之外。
媒体流可以以各种方式被关联。在下面的示例中，会话102的概念将被建议，它意为例如电视会议1204a/b的实例。就此而言，在给定电视会议1204a/b会话102的环境内，在给定用户(用户A)和它的对等体(B，C和D)之间的媒体流206的关联以各种方式被群集。然后，通过使用前述的<context>结构，结果的群集与QoS环境相关。
就此而言，每个聚集可以与一组限制关联，所述限制指令属于所述给定群集的媒体流206的各种关联之中特定级别的相关性804/805。这意味着所述限制影响属于每个关联的所有媒体流206，与属于给定关联的个体媒体流206 of QoS规范无关。<context>结构从而为媒体流206的并行束规定QoS相关性804/805。备选环境因此能是可能的，正如<adapath>结构中所述(电视会议的每一实例一个)。
这些<adapath>结构因此可与FSM的描述相比较，它的状态反过来包含其它并行的<adapath>结构，其每一个描述给定用户和给定对等体之间的媒体流206束。此递归模型允许使用如[Booch99]中所述的状态制图。<e2enp：qoscfg level＝″session″>
 <context name＝″vc-session-1-1″scope＝″applicable″>
      <comp name＝″element-1″
      ref_adapath＝″associations-A-B″/>
      <comp name＝″element-2″
      ref_adapath＝″associations-A-C″/>
      <constraints>
           <par name＝″aggregated-bw″max＝″140000″/>
           <par name＝″frame-rate″avg＝″8″/>
     </constraints>
</context>
<context name＝″vc-session-1-2″scope＝″applicable″>
     <comp name＝″element-1″
     ref_adapath＝″associations-A-C″/>
     <constraints>
          <par name＝″frame-rate″avg＝″8″/>
     </constraints>
</context>
<context name＝″vc-session-2-1″scope＝″possible″>
     <comp name＝″element-1″
     ref_adapath＝″associations-A-D″/>
</context>
<adapath name＝″videoconference 1204a/b-1″>
     <default name＝″nominal″
     ref_context＝″vc-session-1-1″/>
     <alt name＝″choice-1″ref_context＝″vc-session-1-2″/>
</adapath>
<adapath name＝″videoconference 1204a/b-2″>
     <default name＝″nominal″ref_context＝″vc-session-2-
1″/>
     <alt name＝″choice-1″ref_context＝″vc-session-2-1″/>
</adapath></e2enp：qoscfg>
XML示例11
继续上面描述的递归方法，基于更高级别的基本原理，我们还能够集合媒体流206。例如，我们可以关联由某个应用的所有实例管理的所有媒体流206，并从其他应用中区分结果QoS环境，并且利用较高级QoS相关性804规范。
<e2enp：qoscfg level＝″application″>
     <context name＝″videoconference-tool″
     scope＝″applicable″>
          <comp name＝″choice-1″ref_adapath＝″videoconference-
1″/>
          <comp name＝″choice-2″ref_adapath＝videoconference-
2″/>
          <constraints>
               <par name＝″num-active-flows″max＝″6″/>
               <par name＝″cpu-load″max＝″0.20″/>
               <par name＝″mem-req″max＝″110M″/>
          </constraints>
     </context>
</e2enp：qoscfg>
XML示例12
这个示例再一次示出用于表示上述信息的<e2enp：qoscfg>部分的使用。在这个示例中，依照[Roble01]和[BRAIN]中描述的BRENTA概念，我们可以看到此高级别规范如何轻易地允许表示有关本地资源消耗的限制。
在端对端QoS简洁再协商阶段808之后的想法是：在类似由于所述的切换而从QoS妨碍中恢复过来之类的关键任务的时间期间，避免执行一个完全的再协商808。通过使对等体能够彼此发出强制实施的新的(预先协商的)QoS合同1108，和/或通过--在切换到一个新的接入网604和/或网络提供者后--发出那些导致可应用和/或不再可应用的(预先协商的)QoS合同1108，则可以实现此目的。就此而言，需要E2ENP 908特定基于SDPng的支持。
在预先协商AP之外，<e2enp：enforce>新的SDPng部分允许对等体之一(通常，检测到QoS变化或妨碍的第一个对等体)发出信号给应该强制实施QoS合同1108的其它对等体。
该思想是根据预先协商的QoS规范的分级结构传送信令信息。这意味着正确地划定(scope)每个QoS合同名称。至少两个备选实施可用：为QoS合同1108使用一个名称空间或者用于参考文献一部分的语言，就像XPath标准，如”ML Path Language Recommendation”(XML路径语言建议版本1，http：//www.w3.ofg/TR/xpath，1999年11月))所述，或者仍未标准化的XPointer技术，如”XPointerRecommendation”(XPointer建议)(W3C，2000，未完工程，http：//www.w3.org/TR/xptr)(在下面称为[XPOINT])中所述。
通过在给定的基于树形QoS规范内预先待决任何较高级QoS合同1108的名称(从中给定的QoS合同1108所依靠)，则前一个解决方案基于把完全规定的名称赋给QoS合同1108，使用作为分隔字符，例如点字符。可是，这种解决方案需要在多个E2ENP 908部分和E2ENPPDU各处一致使用(经常相当复杂相当长的)名称。此外，这种解决方案迫使应用能够正确地解析给定的名称空间。
例如，在video1 AP内的视频合同2的完全规定名称，在关联-1-1QoS环境内，在关联-A-B AP之外，将看上去像如下：
associations-A-B.association1-1.video1.video-contract-2.(关联-A-B.关联-1.视频1.视频合同2.)
备选解决方案基于XPath甚至基于XPointer技术(作为本基础发明的那个，尚未达到标准化状态)，它们两个通过各种XML文献都表明关于单元明确指示的当前趋势。
在本基础发明的范围中，我们决定使用后一个解决方案，相对于所述概念，与上述其他的(或任何其它等价物)相比没有任何通用性浪费。为了解释选择的解决方案，我们引入下列XML文件分段，描述使用于上面示例中的相同的信息：<e2enp：enforce>  <xsl：variable name＝″association″>
 <xsl：value-of
 select＝
   ″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′]″/>  </xsl：variable>  <xsl：variable name＝″stream″>
<xsl：value-of
select＝
  ″//context[@name＝″$association″]/comp [@ref_adapath＝′video1′]/″/>   </xsl：variable>   <xsl：variable name＝″contract″>
 <xsl：value-of
    select＝
      ″//adapath[@name＝″$stream″]/alt[@ref_contract＝′video-contract-2′]/″/>  </xsl：variable>
  <target name＝″$contract″/>
</e2enp：enforce>
XML示例13
强制实施的QoS合同1108由单元<target>指示。
在这个XML文档分段中，人们可以轻易地认识到对于给定树枝的根单元使用属性(关联-A-B)，而在那个分支中的其他单元经由各自起源的参考属性来命名(ref context，ref adapath，ref contract)。这意味着通过多个部分/阶段，只有<contract>、<context>和<adapath>单元的名称必须被唯一使用，而前述单元的XML子单元的名称可以任意选择。通过使用此方法，通过向给定的QoS环境终止上面的规范，人们可以不但强制实施媒体流206级别QoS合同1108的信令(正如上面的示例中的)，而且强制实施任何高级QoS合同1108的信令。例如，在下面的XML文档分段：  <e2enp：enforce>
<xsl：variable name＝″association″>
   <xsl：value-of
      select＝
         ″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′]″/>
</xsl：variable>  </e2enp：enforce>
XML示例14
能被使用于向其它对等体发出信号，高级关联1-1应该被强制实施，不管现在强制实施的流级别QoS合同1108(在这种情况下，缺省状态将指令在新的QoS环境中实施哪一媒体流206级别QoS合同1108)。
此外，<e2enp：enforce>部分还可以被用于向其它对等体发出强制实施的一个特定的AP，其中，缺省状态然后将被用来消除剩余的较低级别信息。例如，如下<e2enp：enforce>部分：<e2enp：enforce>  <xsl：variable name＝″association″>
 <xsl：value-of
    select＝
       ″//adapath[@name＝′associations-A-B′]/alt[@name＝′association1-1′]″/>  </xsl：variable>  <xsl：variable name＝″stream″>
<xsl：value-of
   select＝
      ″//context[@name＝″$association″]/comp[@name＝′video1′]/″/>   </xsl：variable>   <target name＝″$stream″/></e2enp：enforce>
XML示例15
将迫使对等体A对于”video1”(视频1)使用”video-contract-1”(视频合同1)，因为那个合同1108在预先协商的<e2enp：qoscfg>部分中被规定作为缺省。
前述的XPath(甚至XPointer)技术可以使用来根据上面的基本原理允许一个对等体向QoS合同1108要阻塞的其他对等体发出信号。
就此而言，一个新的SDPng部分因此被建议：<e2enp：block>部分。如下示例描述了这种新部分的使用。
<e2enp：block>
  <xsl：variable name＝″association″>
     <xsl：value-of
      select＝
        ″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′]″/>
  </xsl：variable>
  <xsl：variable name＝″stream″>
    <xsl：value-of
     select＝
       ″//context[@name＝″$association″]/comp[@ref_adapath＝′video1′]/″/>
  </xsl：variable>
  <xsl：variable name＝″contract″>
    <xsl：value-of
      select＝
        ″//adapath[@name＝″$stream″]/alt [@ref_contract＝′video-contract-2′]/″/>
  </xsl：variable>
  <target name＝″$contract″/>
</e2enp：block>
XML示例16
要阻塞的QoS合同1108由单元<target>指示。
前述的XPath(甚至XPointer)技术还可以使用来根据上述基本原理允许一个对等体向QoS合同1108要开启的其他对等体发出信号。
就此而言，一个新的SDPng部分因此被建议：<e2enp：unblock>部分。如下示例描述了这种新部分的使用。
<e2enp：unblock>
  <xsl：variable name＝″association″>
     <xsl：value-of
      select＝
        ″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′]″/>
</xsl：variable>
<xsl：variable name＝″stream″>
  <xsl：value-of
   select＝
     ″//context[@name＝″$association″]/comp[@ref_adapath＝′video1′]/″/>
</xsl：variable>
<xsl：variable name＝″contract″>
  <xsl：value-of
   select＝
     ″//adapath[@name＝″$stream″]/alt[@ref_contract＝′video-contract-2′]/″/>
</xsl：variable>
<target name＝″$contract″/>  </e2enp：unblock>
XML示例17
要开启的QoS合同1108由单元<target>指示。
在这个章节中呈现的解决方案的环境内，如D.Kutscher等人的”Requirements for Session Description and CapabilityNegotiation”(会话描述和能力协商的需求)(IETF互联网草案，未完工程，<draft-kutscher-mmusic-sdpng-req-01.txt>)(在下面称为[SDPNG01])中所述的原始SDPng 912<constraints>部分的语义，可以被翻译为应用到前述新的SDPng部分中描述的整个QoS规范中的QoS相关性804和/或时间同步805限制规范的一种形式。所述文档提供了在多方多媒体会议方案中会话102描述和端点能力协商的框架相关的一组要求。
通过考虑SIP 910和SDPng 912作为E2ENP 908应该映射的协议，需要指出SIP 910是一个非对称的协议。SIP提议者914-应答者911模型没有给出在提议者914端用于对差错、失败情形或例外(状态改变)在它们出现时发信号的可能性。E2ENP 908在它的阶段内需要一些SIP消息往返行程，在E2ENP信令中，每一种方式的往返行程消息将被证明它在所有包括的对等体处的校正和可接受性。另外，在E2ENP阶段的运行时间内，端对等体的状态转变应该被考虑。这些变化可能关系到被包括的一个对等体：
-较高优先级协商(组)；
-对等体的较高优先级内部过程的开始，它影响资源管理和E2ENP908配置文件设定；
-硬件和/或软件崩溃，导致资源损失。
就此而言，使用SIP 910的E2ENP将在它的SDPng 912主体内携带差错码，指示提议者914发生的故障和故障原因；或者提议者914和应答者911的SIP 910差错码。关于E2ENP和它们构造的可能SDPng差错码的研究应该被彻底考虑：为了解决此问题，用于描述E2ENP差错码和信号差错的各个新SDPng XML分段被认为是可能的解决方案，但是为了简洁，在示例中未示出。因为E2ENP 908经由搭载被应用到SIP 910，所以SDPng 912内各自搭载的差错码和消息应该被E2ENP 908的发展所考虑。一般来说，提议者914应该考虑用消息的SDPng 912部分内的原因通知来重复呼叫，应答者911应该使用也描述SDPng 912消息部分中的原因的SIP 910”状态码”。
E2ENP应当能够递送同一可能性来对包含在E2ENP信令中的在任何对等体处发生的内部和外部故障情形、例外和差错发出信号。就此而言，通过在被E2ENP影响的对等体处应用差错码，E2ENP应该是对称的。
根据J.Rosenberg和H.Schulzrinne的”An Offer/AnswerModel with SDP”(SDP的一种提供/应答模型)(IETF互联网草案，未完工程，<draft-rosenberg-mmusic-sdp-offer-answer00.txt>)(在下面称为[SDPOA00])，可以规定”一旦媒体已经被提议者914发送，则一个提供必须准备接收由那个提供所描述的媒体”。相对于E2ENP908和适配机制，此方法不是故障容忍的，因为当协商数据在运行协商806的时刻内或者在媒体流已经开始之前变成无效时，它应该考虑在故障和升级情况中对等体的可能动态重新配置。
还应该考虑沿着E2ENP 908信令路径与端对等体相互作用的一些中间组件可能引起协议的干扰——如果它们不了解它的话。在这种情况下，这里应该有用于检测并弥补这种干扰的机制。
下面是可能误差情况的一个描述，其中，需要提议者914和应答者911之间的通知的一些形式，来指示改变情形和引起的干扰。箭头(4)指示可能的解决方案。′A′指示应答者911而′O′指示提议者914。
1.推模式
·应答者911发现提议者914的提议不匹配它的能力
    o应答者911有能力下载编解码器
     §应答者911应该通知提议者914：该事件可以持续比较
       久，因为她/他需要时间下载和调整他的配置文件数据。
      ->A->用”100 trying”(尝试)或”183 Session
           Progress”(会话过程)来应答
    o应答者911没有能力下载编解码器
     §如果应答者911是一个服务->A->0用”380备选服务”来应
      答，如果应答者911已知这样一个服务。提议者914然后
      可以与所述备选服务开始一个新的预先协商802。
     §->应答者911从<e2enp：qosdef name＝“capabilities”>
       中删除提议者106b的所有能力并且为能力和合同1108产
       生一个反提议(<e2enp：qosdefname＝“capabilities”>以
       及<e2enp：qosdef name＝“contracts”>)。
        ·如果提议者914可以下载编解码器->提议者914下载编
          解码器，最终重新整理配置文件，最终开始一个新的预
          先协商802。
        ·如果提议者914不能下载编解码器->提议者914应该考
          虑使用代码转换器服务。
        §->如果提议者914此刻请求不可用的能力提供，应答者
          911还可以发出606不可接受。
 ·应答者911发现提议者914的提议匹配应答者911的能力，但是
    所提供的合同1108无法被提供。
      o应答者911分别微调她/他的配置文件
       §应答者911应该通知提议者914：所述事件可能持续比较
         久，由于配置文件的调整。
          ->A->0用”100 trying”(尝试)或”183 Session
            Progress”(会话过程)来应答。
       §->如果提议者914此刻请求不可用的QoS提供，应答者
          911还可以发出606不可接受。
    o应答者911没有可能调整她/他的配置文件
   §如果应答者911是一个服务，->A->O用”380 Alternative
     Service”(备选服务)来应答，如果应答者911已知这样一个
     服务。提议者914然后可以与所述备选服务开始一个新的预
     先协商802。
   §通过微调提议者914的合同1108范围或者通过建议全新的
    范围，应答者911为所述(<e2enp：qosdef
    name＝“contracts”>)做出一个反提议。->提议者914计划调
    整她/他配置文件并最后开始一个新的预先协商802。
2.拉模式
·提供者914发现应答者911的应答没有匹配她/他的能力
    o提供者914有能力下载编解码器
     §提供者914下裁编解码器，分别调整他的配置文件并开始
     一个新的预先协商802。
    o提供者914没有能力下载编解码器
     §提供者914应该考虑使用一个代码转换器服务。
·提供者914发现应答者911的提议没有匹配她/他的”合同”--配
置文件
  o提供者914在向应答者911产生一个反提议之前相应地调整
   她/他的配置文件
  o提供者914以推模式开始一个新的预先协商802，以便强制
   实施应答者911的适配。
3.推拉模式
这种情况应该作为上面两种情况的结合来对待。
在提供者914和/或应答者911中预先协商并保存的一些数据由于改变配置文件信息的原因，可能发生改变：
·不同的用户利用它们有关设备(提供者914和/或应答者911)的
能力策略。
·一些较高优先级(内部和/或外部)过程使用资源以使预先协商的
配置文件不再生效。
·一些系统配置改变已经发生，例如：
     o由于占用或资源事故引起的本地资源预留故障。
     o例如如果相对于较低网络QoS级别，网络604只支持”成本
      有效”，引起的网络资源预留故障。
     o新的编解码器和/或硬件子设备被安装，因此影响能力和
      QoS配置文件。
提供者914和/或应答者911在它们努力开始一个另外的预先协商802或协商806的时间之前可能发现此类过早的满期。在这种情况下，对等体应当能够在它们的通信伙伴一端强制实施预先协商数据的满期，从而把它过早地推入”僵”状态中。
->过早满期的必需指示跟随新的预先协商802。就此而言，<expires>单元被设置为零并且另外一个命令”expire”可以被使用。
如果在运行媒体流的时间内一个配置文件变化发生->发现妨碍的一端将开始新的完全再协商808 E2ENP 908过程。
如果一个被呼叫的对等体接收到具有它不支持的协商806模式指示的一则消息，则在它这一端发生故障。在这种情况下，应答者811发送”606不可接受”给提供者810，在消息主体中指示应答者811支持协商806。提供者810应该分别地开始再协商806阶段。
这可能是使用服务的情况，因为服务应当能够并行支持多个客户并因此可以具有协商806模式的首选项。
由于对等体和/或网络604故障，SIP消息(SDPng 912)的主体或者整个SIP消息可能畸形。如果应答者911获得这样一则消息，可能的应答可以是：
·->“400坏请求”--如果整个SIP消息畸形。
·->”420坏扩展”-如果只有SDPng 912消息畸形。
如果提供者914获得一则畸形的消息或者已经接收一则”畸形的消息”通知。提供者914应该重复SIP 910请求。
当希望开始一个协商806的第三方妨碍协商806时，如下步骤被执行：
·如果所述呼叫有相同的优先级：
->如果对等体决定它能够在稍后时刻处理所述呼叫，则对等体发出”182被排队”。
如果其它的对等体发出所述呼叫快些并已经占有应答对等体的所有可用能力时，则对等体发出”600忙”。当可能需要最后的完全再协商808时，通过已经运行媒体流206，这更是如此。
->如果其它的对等体对于发出所述呼叫快些并且占有了应答对等体的所有可用能力时，则对等体发出”603婉谢”，但是应答对等体知道所述呼叫将继续多长。这也是此刻相对于优先级的一个类似的事件正在被处理并且呼叫者不得不等待的情况。
->如果对等体是一个服务并且具有关于公共备选服务的信息，则对等体发出”380备选服务”。
·如果所述呼叫有较高优先级：
  o在提供者914端上：
    ->提供者914应当能够通知应答者911有关协商806的中断-
      -一些SDPng 912差错码。
  o在应答者911端上：
    ->由于指示中断的一些原因，应答者911可以发出”600忙”或
     者”603婉谢”。
    ->取决于已经运行媒体流206的呼叫优先级以及当前可用资源，
      对等体可以执行快速或完整的再协商808，或者完全取消媒体
      流。
根据[SIPBIS04]，可以规定”代理通常不修改会话102描述，但是如果有必要可以那么做，例如对于网络604地址转换器，以及如果会话102描述不被一个用密码写的完整机制保护”。这意味着代理了解SDPng 912的消息主体并可以改变它们。为了保护从不理解协议的组件中不改变E2ENP 908消息，->对于E2ENP消息应该应用数字签名和提要。一些另外的信令机制也应该被应用在E2ENP 908的SDPng 912中以便使对等体能够彼此通知：一则E2ENP消息正被未参与E2ENP 908的一些网络604组件改变。
消息的完整性应该被认为是一个安全问题，它是将来研究的一个课题。如果应答者911一般了解E2ENP 908但是不了解它的版本。->应答者911用SDPng 912描述发出”606不可接受”消息，指示不支持所述E2ENP 908版本但是支持另一E2ENP 908版本。这也是保证E2ENP908版本向下兼容性所需要的。这意味着对于所有的E2ENP 908版本，描述E2ENP 908版本的XML部分应该一致。
在安全性问题中屏蔽网络604的考虑(即代理，防火墙的使用)，它是将来研究的一个课题。下面只是关于安全性可能如何影响E2ENP908差错信息的一个简短描述：
1.屏蔽组件不了解E2ENP 908但是了解SIP 910和/或SDPng912。在这种情况下，将需要与屏蔽组件的一个非E2ENP 908预先协商802，以便使其对如下E2ENP协议透明。
2.屏蔽组件了解E2ENP 908。在这种情况下，E2ENP 908可以以对最后非E2ENP 908信息(验证，安全性等等)的参考的形式来携带涉及非透明组件的信息，从而使非透明组件能够默默地并转发E2ENP消息。对此信息不感兴趣的提供者106b和应答者106a2只须舍弃它。此方法允许默默地处理非透明(关于E2ENP 908)组件，从而使网络604明确透明并屏蔽某些SIP 910”请求失败4xx”消息，那些消息可能会消极地影响E2ENP 908。
与关于E2ENP 908的SIP 910使用有关的特定问题可以被汇总如下：
1.E2ENP 908是SIP 910上的一个元协议，在此范围，E2ENP 908不遵循分层范例。
2.E2ENP元协议应该在SIP消息中被明确地命名以便避免E2ENP会话103中中间组件的干扰。
根据[SIPBIS04]中的SIP 910定义，”Subject”(主题)报头字段”提供一个提要或者指示所述呼叫的性质，允许呼叫过滤而不必解析会话102描述”，从而指示主题：E2ENP
可用于在E2ENP 908开始请求中定义E2ENP 908会话103的开始。理解E2ENP 908的中间组件然后只须转发在SIP 910定义中指示的E2ENP 908呼叫的消息。
为了沿着信令路径跟踪E2ENP 908消息并确保端对端协商806呼叫被明白地理解，元协议的一个附加指示应该在”Content-Type”(内容类型)报头被携带：内容-类型：application/e2enp/sdpng
以便通知理解SIP 910的所有中间组件：E2ENP 908的消息主体不应该经历改变。由于根据定义”Subject”(主题)报头只对于请求呼叫而被使用，这相对于响应呼叫的不可侵犯性是不够的，所以需要这个附加指示。
在内容类型名称
”application/e2enp/sdpng”(应用/e2enp/sdpng)
的结构中，E2ENP 908的指示在中间，因此避免了解SIP 910和SDPng 912但是不了解E2ENP 908的组件误用消息主体。了解E2ENP908的组件应该每一个也都了解SDPng 912。
3.注意：通过执行第三方协商，应该考虑附加状态呼叫应答”380备选服务”的使用。在一个构造模型“提供者-仲裁者-应答者″中，从仲裁者106a1的观点看，应答者811是”备选服务”。
在如下部分中，一些示例将被呈现，以描述该解决方案如何可以用于实际情况中。
第一个示例处理电视会议1204a/b服务，其中，一对一和一对多方案被使用。
第二个示例处理第三方协助协商806方案。第三个示例描述多对多方案的情况。
更明确地，在图12中描述了这种情况：一个给定用户A将认为是同时加入两个不同电视会议会话1204a/b的人。用户A不担当代表其它对等体的混和者，而是在简单参与两个不同的电视会议1204a/b。在我们的词汇中，电视会议应用的每个实例被命名为”电视会议会话”1204a/b。用户A 1202a然后将与用户B 1202b和用户C 1202c举行电视会议会话#1，并且与用户D 1202d举行电视会议会话#2。
在这个示例中，我们只须集中在被用户A 1202a请求并感知的QoS级别上。因此，我们把这个示例限制到用户A 1202a为了从她/他的对等体1202b/c/d中呼入媒体流206而希望获得的QoS级别的协商806上。此外，我们可以假定用户A 1202a有足够信息来在包括在两个电视会议会话1204a/b中的所有媒体流206上强制实施QoS相关性804和时间同步805。
在本节剩余部分中，下列协定被应用：
1.消息序列图表首先被给出，其详细叙述了将要应用的协议程序。SDPng内容用关键词来参考：提议用关键词”bid-x”来参考，而应答用关键词”answer-y”来参考，其中，在两种情况下x和y代表一个递增的正整数值。
2.然后，SDPng内容的详细说明被收集在一个独立的子节中。
以下框图指的是在一对一通信方案100中的一个预先协商：
推模式：对等体A：接收者/提议者914-对等体B：发送者/应答者911 A：本地-许可-控制(提议-1.1-初步建议)：成功 A：选项(提议-1.1)->B B：本地-许可-控制(提议-1.1)：应答-1.1 B：200OK(应答-1.1)->A
拉模式：对等体A：接收者/提议者914-对等体B：发送者/应答者911 A：选项->B B：本地-许可-控制(提议-1.2)：成功 B：200OK(提议-1.2)->A A：本地-许可-控制(提议-1.2)：应答-1.2提议-1.2 A：选项(应答-1.2)->B B200OK->A
注释(1)：提议者914可能需要或者可能不需要用第二个选项方法把应答告知应答者911。
比如，在视频点播系统方案的情况下，提议者914可以相等地使用RTSP描述方法来搜集与给定媒体相关的QoS合同1108的信息。假使那样，则直到实际的媒体流开始之前，应答者911(例如VoD服务器)都将不需要通知提议者914(即客户的)的选择。在此文件中，我们的注意力集中在会议方案上，其中，对等体将实质上在相等尺码上被考虑：每个对等体打算被通知其它对等体以用于稍后的通信。例如，如果对等体B打算执行QoS相关性804和时间同步805，则这尤其是真实的。因此，上述方案的确适用于在此阐明的示例。
推拉模式对等体A：发送者-接收者/提议者914-对等体B：发送者-接收者/应答者911 A：本地-许可-控制(提议-1.3)：成功 A：选项(提议-1.3)->B B：本地-许可-控制(提议-1.4)：成功 B：本地-许可-控制(提议-1.3)：应答-1.3提议-1.3 B：200OK(应答-1.3+提议1.4)->A A：本地-许可-控制(提议-1.4)：应答-1.4提议-1.4 A：选项(应答-1.4)->B B：200OK->A
注释(2)：当从提议者914接收到一个提议的时候，通过遵循经济原理的子情况(首先提交到本地资源，然后提交到远程对等体的本地资源)，应答者911首先确认它自己的提议(例如基于用户配置文件信息)，然后确认提议者914的提议。
在以下部分中，用上述示例中关键词bid-x、answer-y表示的SIP消息环境被描述。  Bid-1.1  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890843112″
          version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
        <expires time＝″36000″/>
  </session>
   <description
        type＝″request″
        name＝″pre-negotiation″
        mode＝″push″/>  </e2enp：purpose>  <e2enp：qosdef name＝″capabilities″>
<audio：codec name＝″PCMU″scope＝″applicable″/>
<audio：codec name＝″G729″scope＝″applicable″/>
<audio：codec name＝″G722″scope＝″possible″/>
<rtp：pt name＝″rtp-avp-0″pt＝″0″format＝″PCMU″/>
<rtp：pt name＝″rtp-avp-18″pt＝″18″format＝″G729″/>
<rtp：pt name＝″rtp-avp-9″pt＝″9″format＝″G722″/>
<video：codec name＝″H263″scope＝″applicable″/>
<video：codec name＝″H261″scope＝″applicable″/>
<video：codec name＝″WAVI″scope＝″possible″/>
<rtp：pt name＝″rtp-avp-34″pt＝″34″format＝″H263″/>
<rtp：pt name＝″rtp-avp-31″pt＝″31″format＝″H261″/>
<rtp：pt name＝″rtp-avp-100″pt＝″100″format＝″WAVI″>
      <video：codec frame-rate-range＝″5，30″
            frame-size-set＝″QCIF，CIF″
            color-quality-range＝″9100，10000″
                 overall-quality-range＝″9100，10000″/>
 </rtp：pt></e2enp：qosdef><e2enp：qosdef name＝″contracts″>
 <policy
 name＝″Let us optimize((memory && network)||CPU)″>
       <predicate id＝″predicate-1″
        first-term＝″optMemoryUsage″
          second-term＝″optNetworkPerformance″
        function＝″and″/>
  <predicate id＝″predicate-2″
       first-term＝″predicate-1″
       second-term＝″optCpuLoad″
       function＝″or″/>
 <criterion type＝″expression″idref＝″predicate-2″/></policy><audio>
 <contract name＝″audio-contract-1″
 sampling-rate-set＝″4000，8000″channel-set＝″1″/>
 <contract name＝″audio-contract-2″
 sampling-rate-set＝″8000，12000″channel-set＝″1，2″/>
 <contract name＝″audio-contract-3″
 sampling-rate-set＝″12000，16000″channel-set＝″1″/>
 <rtp：map contract＝″audio-contract-1″
 format＝″rtp-avp-0″role＝″receiver″/>
 <rtp：map contract＝″audio-contract-2″
 format＝″rtp-avp-18″role＝″receiver″/>
 <rtp：map contract＝″audio-contract-3″
 format＝″rtp-avp-9″role＝″receiver″/></audio><video>
 <contract name＝″video-contract-1″
 frame-rate-set＝″10，15″frame-size-set＝″CIF″
 color-quality-range＝″9100，9700″
 overall-quality-range＝″9500，9800″/>
 <contract name＝″video-contract-2″
 frame-rate-set＝″15，20″frame-size-set＝″QCIF″
 color-quality-range＝″9700，9850″
 overall-quality-range＝″9800，9900″/>
         <contract name＝″video-contract-3″
         frame-rate-set＝″20，25″frame-size-set＝″QCIF，CIF″
         color-quality-range＝″9850，9900″
         overall-quality-range＝″9900，9960″/>
         <rtp：map contract＝″video-contract-1″
         format＝″rtp-avp-34″role＝″receiver″/>
         <rtp：map contract＝″video-contract-2″
         format＝″rtp-avp-31″role＝″receiver″/>
         <rtp：map contract＝″video-contract-2″
         format＝″rtp-avp-100″role＝″receiver″/>
    </video>   </e2enp：qosdef>
XML示例18
应答-1.1
反提议指出应答者911支持什么能力和达到什么程度。如果给定能力支持”as is”，则只有相应的标识符以及可适用的范围属性.设置为可应用的。如果给定能力不被支持，则相应的标识符被简单地省略(在这个示例中，G.729音频编码解码器和WAVI视频编码解码器)。如果在<e2enp：qosdef name＝“contracts”>部分中给定能力被更新，则具有该更新的整个描述被返回。在任何情况下，<e2enp：qosdef name＝“contracts”>在响应中只包含了更新的编码解码器参数化。在这个示例中，PCMU音频编码解码器和H.261视频编码解码器由应答者911再参数化。
最后，反提议可以列出一些提议者914不支持的能力。在这个示例中为L16音频编码解码器和MPEG-2视频编码解码器。
对提议<e2enp：qosdef name＝“contracts”>部分的反提议可以由应答者911来建议，与<e2enp：qosdef＝“capabilities”>部分中的对应行无关，反之亦然。在这个示例中，G.722音频编码解码器的范围被反提议为<e2enp：qosdef name＝“capabilities”>部分中可适用的，而<e2enp：qosdef name＝“contracts”>部分中的相应合同1108保持原样。
如上所述，对相对于PCMU音频编码解码器的合同1108的反提议在<e2enp：qosdefname＝“contracts”>部分中被建议，而<e2enp：qosdef name＝“capabilities”>部分中的相应提议保持原样。这种灵活性应归于不同部分的模块化定义。
关于原始提议的变化用黑体字指出。在这个示例中，应答者911应答提议者914，其指出：
-G729音频编码解码器不能被支持(删除的对应行)。
-L16音频编码解码器可以被支持(用配置设置指出”可能的”)。
-WAVI视频编码解码器不能被支持(删除的对应行)。
-MPEG-2视频编码解码器可以被支持(用配置设置指出”可能的”)。
-只应该使用网络资源优化策略。
-音频合同1：只能应用所建议抽样范围的子集。
-视频合同2：只能应用所建议帧速率范围的子集。
<e2enp：purpose>
     <session user＝″Mary″session-id＝″2890843112″
            version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
            addr＝″43.196.180.1″>
         <expires time＝″36000″/>
    </session>
    <description
         type＝″response″
         name＝″pre-negotiation″
         mode＝″push″/>  </e2enp：purpose>  <e2enp：qosdef name＝″capabilities″>
   <audio：codec name＝″PCMU″scope＝″applicable″/>
   <audio：codec name＝″G722″scope＝″applicable″/>
   <audio：codec name＝″L16″scope＝″possible″/>
   <rtp：pt name＝″rtp-avp-0″pt＝″0″format＝″PCMU″/>
   <rtp：pt name＝″rtp-avp-9″pt＝″9″format＝″G722″/>
   <rtp：pt name＝″rtp-avp-11″pt＝″11″format＝″L16″/>
   <video：codec name＝″H263″scope＝″applicable″/>
   <video：codec name＝″H261″scope＝″applicable″/>
   <video：codec name＝″MP2T″scope＝″possible″/>
   <rtp：pt name＝″rtp-avp-34″pt＝″34″format＝″H263″/>
   <rtp：pt name＝″rtp-avp-31″pt＝″31″format＝″H261″/>
   <rtp：pt name＝″rtp-avp-33″pt＝″33″format＝″MP2T″>
         <video：codec frame-rate-range＝″30，30″
               frame-size-set＝″SIF″
               color-quality-range＝″0，10000″
                 overall-quality-range＝″0，10000″/>
</e2enp：qosdef>
<e2enp：qosdef name＝″contracts″>
     <policy name＝″Let us optimize((memory && network)||CPU)″>
           <criterion type＝″optNetworkPerformance″/>
      </policy>
      <audio>
           <contract name＝″audio-contract-1″
           sampling-range＝″5000，7000″channels＝″1″/>
           <contract name＝″audio-contract-3″/>
      </audio>
      <video>
           <contract name＝″video-contract-1″/>
           <contract name＝″video-contract-2″
           frame-rate-range＝″15，18″
           frame-size＝″QCIF″quality-range＝″9700-9850″/>
     </video>
</e2enp：qosdef>
XML示例19
提议-1.2和应答-1.2
在<e2enp：purpose>部分指出这种情况下的拉模式的范围内，所述提议和应答不同于之前段落中被描述的其它提议和应答。
对于”OPTIONS”(选项)：<e2enp：purpose>
 <session user＝″Mary″session-id＝″2890843112″
        version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
        addr＝″43.196.180.1″>
        <expires time＝″3600″/>
   </session>
   <description
        type＝″request″
        name＝″pre-negotiation″
        mode＝″pull″/> </e2enp：purpose>
XML示例20
对于”Bid-1.2”：  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890843112″
          version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
          addr＝″ 43.196.180.1″>
       <expires time＝″3600″/>
  </session>
  <description
       type＝″response″
       name＝″pre-negotiation″
       mode＝″pull″/></e2enp：purpose>...″Bid-1.2″content...
XML示例21
对于”Answer-1.2”：  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890843112″
          version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″3600″/>
  </session>
  <description
          type＝″request″
          name＝″pre-negotiation″
          mode＝″pull″/>   </e2enp：purpose>...″Answer-1.2″content...
XML示例22
和来自对等体B的最终回复是：  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890843112″
          version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″3600″/>
   </session>
   <description
         type＝″response″
         name＝″pre-negotiation″
         mode＝″pull″/>  </e2enp：purpose>
XML示例23
这些提议和应答与前面段落中描述的那些不同，在此范围内，<e2enp：purpose>部分在这个情况中指示推拉模式。”Bid-1.3”将包括为如下<e2enp：purpose>：   <e2enp：purpose>
    <session user＝″Mary″session-id＝″2890843112″
    version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
    addr＝″43.196.180.1″/>
    <description
         type＝″request″
         name＝″pre-negotiation″
         mode＝″push-pull″/>  </e2enp：purpose>
XML示例24
更具体地说，”Aswer-1.3+Bid-1.4”解释了这种情况，其中，E2ENP 908 SDPng内容包括提议和应答者911的应答。为了从应答中区别提议，它们中的每一个都应该是清楚的<e2enp：purpose>部分的特色。这意指推拉式的预先协商802导致两个预先协商802会话103的交叉，它们每个都有自己的标识符。
更具体地，如果”Bid-1.3”表示类似如上所述部分的<e2enp：purpose>部分的特征，则”Answer-1.3+Bid-1.4”则应该表示象下面的两个<e2enp：purpose>部分的特征：  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890843112″
          version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″36000″/>
  <description
       type＝″response″
       name＝″pre-negotiation″
       mode＝″push-pull″/></e2enp：purpose>...″Answer-1.3″content...<e2enp：purpose>
 <session user＝″Kate″session-id＝″2890844526″
        version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
        addr＝″43.196.180.145″>
     <expires time＝″36000″/>
<use>
     <session user＝″Mary″session-id＝″2890843112″
     version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
     addr＝″43.196.180.1″/>
</use>
<description
     type＝″request″
     name＝″pre-negotiation 802″
         mode＝″push-pull″/>  </e2enp：purpose>  ...″Bid-1.4″content...
XML示例25
在应答者911基于应答者911的选择(例如从用户配置文件信息)和基于提议者914的提议(和最后基于QoS相关性804和/或时间同步805限制)公式化其提议的范围内，应答者911的提议经由<use>结构来参考提议者914的提议。
当然，通过遵循上述示例，”应答-1.4”将作为<e2enp：purpose>包括以下：
<e2enp：purpose>
     <session user＝″Kate″session-id＝″2890844526″
            version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
            addr＝″43.196.180.145″>
         <expires time＝″3600″/>
    </session>
    <use>
        <session user＝″Mary″session-id＝″2890843112″
        version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
        addr＝″43.196.180.1″/>
    </use>
    <description
         type＝″response″
         name＝″pre-negotiation″
         mode＝″push-pull″/>  </e2enp：purpose>
XML示例26
在以下部分中，协商和资源预留将被描述：
推模式对等体A：接收者/提议者914-对等体B：发送者/应答者911 A：本地-许可-控制(提议-2.1)：成功 A：本地-资源-预留(提议-2.1)：成功 A：邀请(提议-2.1)->B B：本地-许可-控制(提议-2.1)：应答-2.1提议-2.1 B：本地-资源-预留(应答-2.1)：成功 B：183会话进程(应答-2.1)->A A：本地-资源-预留(应答-2.1)：成功 A：PRACK(命令-开始-预留)B B：200OK(PRACK的)(命令-开始-预留)->A A：网络604预留(基于应答-2.1) B：网络604预留(基于应答-2.1) B.COMET(命令-准备-预留)->A A：200OK(COMET的)->B A.COMET(命令-准备-预留)->B B：200OK(COMET的)->A B：180响铃->A B：200OK(邀请的)->A A：确认->B
注释(1)：在已经事先登记关于”提议-2.1”的本地资源之后，对等体A最后预留被协商的子集”应答-2.1”以便释放任何过剩资源。
拉模式对等体A：接收者/提议者914-对等体B：发送者/应答者911 A：邀请->B B：本地-许可-控制(提议-2.2)：成功 B：本地-资源-预留(提议-2.2)：成功 B：183会话进程(提议-2.2)->A A：本地-许可-控制(提议-2.2)：应答-2.2提议-2.2 A：本地-资源-预留(应答-2.2)：成功 A：PRACK(应答-2.2-参见注释(3))->B B：本地-资源-预留(应答-2.2)：成功 B：200OK(PRACK的)(命令-开始-预留)->A A：网络604预留(基于应答-2.2) B：网络604预留(基于应答-2.2) B.COMET(命令-准备-预留)->A A：200OK(COMET的)->B A.COMET(命令-准备-预留)->B B：200OK(COMET的)->A B：180响铃->A B：200OK->A A：确认->B
注释(2)：在已经事先登记关于”提议-2.2”的本地资源之后，对等体B最后预留被协商的子集”应答-”以便释放任何过剩资源。
注释(3)：除了<e2enp：purpose>部分之外，”提议-2.2”和”应答-2.1”实质上相当于(相应地)”提议-2.1”和”应答-2.1”，其带有属性”模式”设置到”拉”的特征，并且在”应答-2.2”的情况下，属性”类型”设置到”开始-预留”。
推拉模式对等体A：发送者-接收者/提议者914-对等体B：发送者-接收者/应答者911 A：本地-许可-控制(提议-2.3)：成功 A：本地-资源-预留(提议-2.3)：成功 A：邀请(提议-2.3)->B B：本地-许可-控制(提议-2.4)：成功 B：本地-许可-控制(提议-2.3)：应答-2.3提议-2.3 B：本地-资源-预留(提议-2.4)：成功 B：本地-资源-预留(应答-2.3)：成功 B：183会话进程(应答-2.3+提议-2.4)->A A：本地-资源-预留(应答-2.3)：成功 A：本地-许可-控制(提议-2.4)：应答-2.4提议-2.4 A：本地-资源-预留(应答-2.4)：成功 A：PRACK(应答-2.4-参见注释(6))->B B：本地-资源-预留(应答-2.4)：成功 B：200OK(PRACK的：命令-开始-预留)->A A：网络604预留(基于应答-2.3+应答-2.4)(注释(7)) B：网络604预留(基于应答-2.3+应答-2.4)(注释(8)) B.COMET(命令-准备-预留)A A：200OK(COMET的)->B A.COMET(命令-准备-预留)B B：200OK(COMET的)->A B：180响铃->A B：200OK->A A：确认->B
注释(4)：在已经事先登记关于”提议-2.3”的本地资源之后，对等体A最后预留被协商的子集”应答-2.3”以便释放任何过剩资源。
注释(5)：在已经事先登记关于”提议-2.4”的本地资源之后，对等体B最后预留被协商的子集”应答-2.4”以便释放任何过剩资源。
注释(6)：除了<e2enp：purpose>部分之外，”提议-2.3”/”提议-2.4”和”应答-2.3”/”应答-2.4”实质上相当于(相应地)”提议-2.1”和”应答-2.1”，其带有设置到推拉的”模式”单元的特征，和在”应答-2.4”的情况下带有设置到”开始-预留”的属性”类型”的特征。
注释(7)：”应答-2.3”是用于接收的TSpec，”应答-2.4”是用于发送的TSpec。
注释(8)：”应答-2.3”是用于发送的TSpec，”应答-2.4”是用于接收的TSpec。
在以下部分中，用上述示例中关键词bid-x、answer-y表示的SIP消息环境将被描述。
提议-2.1
这个提议指的是预先协商信息，通过指出会话103标识符，该指示符唯一地指出经由<e2enp：purpose>部分中的<使用>结构的信息。在这个示例中，所涉及信息是”提议-1.1”，其过去被用于预先协商能力和流级别QoS合同1108。换言之，对等体可能已经直接在”提议-1.1”中预先协商包含在这个段落中的AP信息，以便加速协商806阶段。<e2enp：purpose>
 <session user＝″Mary″session-id＝″2890844526″
        version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
        addr＝″43.196.180.1″>
      <expires time＝″3600″/>
 </session>
 <use>
       <session user＝″Mary″session-id＝″2890843112″
       version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
       addr＝″43.196.180.1″/>
  </use>
  <description
       type＝″request″
       name＝″negotiation″
       mode＝″push″/></e2enp：purpose><cfg>
 <component name＝″audio-stream-1″media＝″audio″>
      <alt name＝″AVP-audio-0″>
    <rtp：session format＝″rtp-avp-0″>
          <rtp：udp role＝″receive″nettype＝″IN″
          addrtype＝″IP4″addr＝″43.196.180.1″
          rtp-port＝″7800″
          rtcp-port＝″7801″/>
     </rtp：session>
</alt>
<alt name＝″AVP-audio-9″>
     <rtp：session format＝″rtp-avp-9″>
           <rtp：udp role＝″receive″nettype＝″IN″
           addrtype＝″IP4″addr＝″43.196.180.1″
           rtp-port＝″7840″
           rtcp-port＝″7851″/>
      </rtp：session>
 </alt></component><component name＝″video-stream-1″media＝″video″>
<alt name＝″AVP-video-34″>
     <rtp：session format＝″rtp-avp-34″>
           <rtp：udp role＝″receive″nettype＝″IN″
           addrtype＝″IP4″addr＝″43.196.180.1″
           rtp-port＝″7900″
           rtcp-port＝″7901″/>
      </rtp：session>
</alt>
<alt name＝″AVP-video-31″>
           <rtp：session format＝″rtp-avp-31″>
                 <rtp：udp role＝″receive″nettype＝″IN″
                 addrtype＝″IP4″addr＝″43.196.180.1″
                 rtp-port＝″7920″
                 rtcp-port＝″7921″/>
      </rtp：session>
 </component></cfg><e2enp：qoscfg level＝″stream″>
<！--adaptation path for single media streams 206-->
<adapath name＝″audio1″ref_component＝″audio-stream-1″>
     <default name＝″nominal″
     ref_contract＝″audio-contract-1″/>
     <alt name＝″choicel″
     ref_contract＝″audio-contract-3″/>
</adapath>
<adapath name＝″video1″ref_component＝″video-stream-1″>
     <default name＝″nominal″
     ref_contract＝″video-contract-1″/>
     <alt name＝″choice1″
     ref_contract＝″video-contract-2″/>
</adapath>
<！--Possible associations of media streams 206 betweenuser A and B-->
<context name＝″association1-1″scope＝″applicable″>
     <comp name＝″element1″ref_adapath＝″audio1″/>
     <comp name＝″element2″ref_adapath＝″video1″/>
     <constraints>
          <par name＝″lipsync-delay″reference＝″audio1″
          max＝″2″/>
          <par name＝″aggregated-bw″max＝″64000″/>
           </constraints>
   </context>
   <context name＝″association1-2″scope＝″possible″>
        <comp name＝″element1″ref_adapath＝″audio1″/>
   </context>
   <adapath name＝″associations-A-B″>
        <default name＝″nominal″
        ref_context＝″association1-1″/>
        <alt name＝″choice1″ref_context＝″association1-2″/>
   </adapath>  </e2enp：qoscfg>
XML示例27
应答-2.1考虑到SDPng 912<cfg>部分，这个示例中的应答者911通过列表只应答提议者914协议已经到达的传送信息。关于原提议的变化用黑体字指出。在这个示例中，应答者911通过指出下面的内容来应答提议者914：
”AVP-video-33”选项不被支持，由于例如IPv6不被应答者911支持(对应行被删除)。
“association1-1”：只能应用所建议”lipsync-delay″的子集。
association1-1：只能应用所建议”aggregated-bw″的子集。
“association1-2”：被确认为可适用的。
在这个阶段，对等体经由<e2enp：qoscfg>部分来协商媒体流206AP和关联AP：在这个示例中，应答者911用提议QoS相关性804的子集和时间同步805限制来应答(只详细描述了被改变的单元：变化用黑体字指出)。
<e2enp：purpose>
     <session user＝″Mary″session-id＝″2890844526″
            version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
            addr＝″43.196.180.1″>
         <expires time＝″3600″/>
    </session>
    <use>
         <session user＝″Mary″session-id＝″2890843112″
         version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
         addr＝″43.196.180.1″/>
    </use>
    <description
         type＝″response″
         name＝″negotiation″
         mode＝″push″/>  </e2enp：purpose>  <cfg>
   <component name＝″audio-stream-1″media＝″audio″>
        <alt name＝″AVP-audio-0″/>
        <alt name＝″AVP-audio-9″/>
   </component>
   <component name＝″audio-stream-1″media＝″video″>
        <alt name＝″AVP-audio-34″/>
        <alt name＝″AVP-audio-31″/>
  </component> </cfg><e2enp：qoscfg level＝″stream″>
 <！--adaptation path for single media streams -->
 <adapath name＝″audio1″/>
 <adapath name＝″video1″/>
 <！--Possible associations of media streams betweenuser A and B-->
    <context name＝″association1-1″scope＝″applicable″>
         <comp name＝″element1″ref_adapath＝″audio1″/>
         <comp name＝″element2″ref_adapath＝″video1″/>
         <constraints>
              <par name＝″lipsync-delay″reference＝″audio1″
                      max＝″1.5″/>
              <par name＝″aggregated-bw″max＝″56000″/>
         </constraints>
    </context>
   <context name＝″association1-2″scope＝″applicable″>
        <comp name＝″element1″ref_adapath＝″audio1″/>
   </context>
   <adapath name＝″associations-A-B″/>  </e2enp：qoscfg>
XML示例28
为了把命令发信号到对等体来开始预留资源，SDPng内容将简单地带有设置来”开始-预留”的属性name”的<e2enp：purpose>部分的特征，如同以下示例：
<e2enp：purpose>
     <session user＝″Mary″session-id＝″2890843112″
     version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
     addr＝″43.196.180.1″/>
         <description
              type＝″request″
              name＝″start-reservation″/>
   </e2enp：purpose>
XML示例29
为了发信号到对等体以告知预留已经被完成，SDPng内容将简单地带有具有设置来”准备-预留”的属性”name”的<e2enp：purpose>部分的特征，如同以下示例：
 <e2enp：purpose>
      <session user＝″Mary″session-id＝″2890843112″
      version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
      addr＝″43.196.180.1″/>
      <description
           type＝″request″
           name＝″ready-reservation″/>
</e2enp：purpose>
XML示例30
正如上面所预期的，对等体可能已经直接在”提议-1.1”中预先协商描述在这个段落剩余部分中描述的AP信息，以便加速协商806阶段。下面是预先协商802提议和应答信息(对于推模式预先协商802简易情况下的一个示例)，然后是协商806提议和应答的示例(再一次推模式)。以下示例基于上述相应的示例。
提议-1.1-具有媒体流206 AP和组AP(关于流关联)
    <e2enp：purpose>
         <session user＝″Mary″session-id＝″2890843112″
              version＝″2890841393″nettype＝″IN″
             addrtype＝″IP4″addr＝″43.196.180.1″>
             <expires time＝″36000″/>
        </session>
        <description
             type＝″request″
             name＝″pre-negotiation″
             mode＝″push″/>
  </e2enp：purpose>
  <e2enp：qosdef name＝″capabilities″>
       <audio：codec name＝″PCMU″scope＝″applicable″/>
       <audio：codec name＝″G729″scope＝″applicable″/>
       <audio：codec name＝″G722″scope＝″possible″/>
<rtp：pt name＝″rtp-avp-0″pt＝″0″
format＝″PCMU″/>
<rtp：pt name＝″rtp-avp-18″pt＝″18″
format＝″G729″/>
<rtp：pt name＝″rtp-avp-9″pt＝″9″
format＝″G722″/>
<video：codec name＝″H263″scope＝″applicable″/>
<video：codec name＝″H261″scope＝″applicable″/>
<video：codec name＝″WAVI″scope＝″possible″/>
<rtp：pt name＝″rtp-avp-34″pt＝″34″
format＝″H263″/>
<rtp：pt name＝″rtp-avp-31″pt＝″31″
format＝″H261″/>
<rtp：pt name＝″rtp-avp-100″pt＝″100″
format＝″WAVI″>
     <video：codec frame-rate-range＝″5，30″
      frame-size-set＝″QCIF，CIF″
      color-quality-range＝″9100，10000″
     overall-quality-range＝″9100，10000″/>
</rtp：pt></e2enp：qosdef><e2enp：qosdef name＝″contracts″>
 <policy name＝″Let us optimize((memory && network)||CPU)″>
       <predicate id＝″predicate-1″
        first-term＝″optMemoryUsage″
        second-term＝″optNetworkPerformance″
        function＝″and″/>
       <predicate id＝″predicate-2″
        first-term＝″predicate-1″
        second-term＝″optCpuLoad″
        function＝″or″/>
       <criterion type＝″expression″
       idref＝″predicate-2″/>
  </policy>
  <audio>
       <contract name＝″audio-contract-1″
       sampling-rate-set＝″4000，8000″
       channel-set＝″1″/>
       <contract name＝″audio-contract-2″
       sampling-rate-set＝″8000，12000″
       channel-set＝″1，2″/>
       <contract name＝″audio-contract-3″
       sampling-rate-set＝″12000，16000″
       channel-set＝″1″/>
       <rtp：map contract＝″audio-contract-1″
       format＝″rtp-avp-0″role＝″receiver″/>
       <rtp：map contract＝″audio-contract-2″
       format＝″rtp-avp-18″role＝″receiver″/>
 <rtp：map contract＝″audio-contract-3″
 format＝″rtp-avp-9″role＝″receiver″/></audio><video>
 <contract name＝″video-contract-1″
 frame-rate-set＝″10，15″
 frame-size-set＝″CIF″
 color-quality-range＝″9100，9700″
 overall-quality-range＝″9500，9800″/>
            <contract name＝″video-contract-2″
            frame-rate-set＝″15，20″
            frame-size-set＝″QCIF″
            color-quality-range＝″9700，9850″
            overall-quality-range＝″9800，9900″/>
            <contract name＝″video-contract-3″
            frame-rate-set＝″20，25″
            frame-size-set＝″QCIF，CIF″
            color-quality-range＝″9850，9900″
            overall-quality-range＝″9900，9960″/>
            <rtp：map contract＝″video-contract-1″
            format＝″rtp-avp-34″role＝″receiver″/>
            <rtp：map contract＝″video-contract-2″
            format＝″rtp-avp-31″role＝″receiver″/>
            <rtp：map contract＝″video-contract-2″
            format＝″rtp-avp-100″role＝″receiver″/>
 </video></e2enp：qosdef><e2enp：qoscfg level＝″stream″>
 <！--adaptation path for single media streams -
 ->
 <adapath name＝″audio1″
 ref_component＝″audio-stream-1″>
      <default name＝″nominal″
      ref_contract＝″audio-contract-1″/>
      <alt name＝″choice1″
      ref_contract＝″audio-contract-3″/>
 </adapath>
   <adapath name＝″video1″
   ref_component＝″video-stream-1″>
        <default name＝″nominal″
        ref_contract＝″video-contract-1″/>
        <alt name＝″choice1″
        ref_contract＝″video-contract-2″/>
   </adapath>
   <！--Possible associat.of media streams 206 be-  tween user A & B -->
  <context name＝″association1-1″scope＝″applicable″>
       <comp name＝″element1″ref_adapath＝″audio1″/>
       <comp name＝″element2″ref_adapath＝″video1″/>
       <constraints>
            <par name＝″lipsync-delay″
            reference＝″audio1″max＝″2″/>
            <par name＝″aggregated-bw″max＝″64000″/>
       </constraints>
  </context>
  <context name＝″association1-2″scope＝″possible″>
       <comp name＝″element1″ref_adapath＝″audio1″/>
  </context>
  <adapath name＝″associations-A-B″  >
  <default name＝″nominal″
      ref_context＝″association1-1″/>
      <alt name＝″choice1″
      ref_context＝″association1-2″/>
 </adapath></e2enp：qoscfg>
XML示例31
应答-1.1-具有媒体流206 AP和组AP(关于流关联)<e2enp：purpose>
 <session user＝″Mary″session-id＝″2890843112″
         version＝″2890841393″nettype＝″IN″
         addrtype＝″IP4″addr＝″43.196.180.1″>
       <expires time＝″36000″/>
  </session>
  <description
       type＝″response″
       name＝″pre-negotiation 802″
       mode＝″push″/></e2enp：purpose><e2enp：qosdef name＝″capabilities″>
 <audio：codec name＝″PCMU″scope＝″applicable″/>
 <audio：codec name＝″G722″scope＝″applicable″/>
 <audio：codec name＝″L16″scope＝″possible″/>
 <rtp：pt name＝″rtp-avp-0″pt＝″0″
 format＝″PCMU″/>
 <rtp：pt name＝″rtp-avp-9″pt＝″9″
 format＝″G722″/>
 <rtp：pt name＝″rtp-avp-11″pt＝″11″
 format＝″L16″/>
 <video：codec name＝″H263″scope＝″applicable″/>
 <video：codec name＝″H261″scope＝″applicable″/><video：codec name＝″MP2T″scope＝″possible″/><rtp：pt name＝″rtp-avp-34″pt＝″34″format＝″H263″/><rtp：pt name＝″rtp-avp-31″pt＝″31″format＝″H261″/><rtp：pt name＝″rtp-avp-33″pt＝″33″format＝″MP2T″>
       <video：codec frame-rate-range＝″30，30″
             frame-size-set＝″SIF″
             color-quality-range＝″0，10000″
            overall-quality-range＝″0，10000″/></e2enp：qosdef><e2enp：qosdef name＝″contracts″>
 <pollcy name＝″Let us optimize((memory && network)||CPU)″>
       <criterion type＝″optNetworkPerformance″/>
 </policy>
 <audio>
      <contract name＝″audio-contract-1″
      sampling-range＝″5000，7000″
      channels＝″1″/>
      <contract name＝″audio-contract-3″/>
 </audio>
 <video>
      <contract name＝″video-contract-1″/>
      <contract name＝″video-contract-2″
       frame-rate-range＝″15，18″
       frame-size＝″QCIF″
       quality-range＝″9700-9850″/>
 </video></e2enp：qosdef>   <e2enp：qoscfg level＝″stream″>
    <！--adaptation path for single media streams
    -->
    <adapath name＝″audio1″/>
    <adapath name＝″video1″/>
     <！--Possible ass.of media streams 206 be-
     tween user A & B -->
     <context name＝″association1-1″
     scope＝″applicable″>
          <comp name＝″element1″
          ref_adapath＝″audio1″/>
          <comp name＝″element2″
          ref_adapath＝″video1″/>
          <constraints>
               <par name＝″lipsync-delay″
               reference＝″audio1″max＝″1.5″/>
               <par name＝″aggregated-bw ″
               max＝″56000″/>
          </constraints>
     </context>
     <context name＝″association1-2″
          scope＝″applicable″>
          <comp name＝″element1″
          ref_adapath＝″audio1″/>
     </context>
     <adapath name＝″associations-A-B″/>
</e2enp：qoscfg>
XML示例32
提议-2.1-只具有参考媒体流206 AP和组AP(关于流关联)
<e2enp：purpose>
     <session user＝″Mary″session-id＝″2890844526″
            version＝″2890842807″nettype＝″IN″
            addrtype＝″IP4″addr＝″43.196.180.1″>
         <expires time＝″3600″/>
    </session>
  <use>
       <session user＝″Mary″
       session-id＝″2890843112″ver-
       sion＝″2890841393″nettype＝″IN″ad-
       drtype＝″IP4″addr＝″43.196.180.1″/>
  </use>
  <description
       type＝″request″
       name＝″negotiation″
       mode＝″push″/></e2enp：purpose><cfg>
<component name＝″audio-stream-1″
     media＝″audio″>
     <alt name＝″AVP-audio-0″>
          <rtp：session format＝″rtp-avp-0″>
                <rtp：udp role＝″receive″
                nettype＝″IN″addrtype＝″IP4″
                addr＝″43.196.180.1″
                rtp-port＝″7800″
                rtcp-port＝″7801″/>
           </rtp：session>
     </alt>
     <alt name＝″AVP-audio-9″>
          <rtp：session format＝″rtp-avp-9″>
                <rtp：udp role＝″receive″
                nettype＝″IN″addrtype＝″IP4″
                addr＝″43.196.180.1″
                           rtp-port＝″7840″
                           rtcp-port＝″7851″/>
                      </rtp：session>
                 </alt>
            </component>
            <component name＝″video-stream-1″
                 media＝″video″>
                 <alt name＝″AVP-video-34″>
                      <rtp：session
                      format＝″rtp-avp-34″>
                           <rtp：udp role＝″receive″
                           nettype＝″IN″addrtype＝″IP4″
                           addr＝″43.196.180.1″
                           rtp-port＝″7900″
                           rtcp-port＝″7901″/>
                      </rtp：session>
                 </alt>
                 <alt name＝″AVP-video-31″>
                      <rtp：session
                      format＝″rtp-avp-31″>
                          <rtp：udp role＝″receive″
                          nettype＝″IN″addrtype＝″IP4″
                          addr＝″43.196.180.1″
                          rtp-port＝″7920″
                          rtcp-port＝″7921″/>
               </rtp：session>
          </component>
     </cfg>
XML示例33
应答-2.2-只具有参考媒体流206 AP和组AP(关于流关联)
        <e2enp：purpose>
             <session user＝″Mary″session-id＝″2890844526″
                    version＝″2890842807″nettype＝″IN″
                    addrtype＝″IP4″addr＝″43.196.180.1″>
                 <expires time＝″3600″/>
            </session>
            <use>
                 <session user＝″Mary″
                 session-id＝″2890843112″ver-
                 sion＝″2890841393″nettype＝″IN″ad-
                 drtype＝″IP4″addr＝″43.196.180.1″/>
            </use>
            <description
                 type＝″response″
                 name＝″negotiation″
                 mode＝″push″/>
      </e2enp：purpose>
      <cfg>
          <component name＝″audio-stream-1″
               media＝″audio″>
               <alt name＝″AVP-audio-0″/>
               <alt name＝″AVP-audio-9″/>
           </component>
           <component name＝″audio-stream-1″
                media＝″video″>
                <alt name＝″AVP-audio-34″/>
                <alt name＝″AVP-audio-31″/>
           </component>
      </cfg>
XML示例34
在这种情况下，通过用<default>结构指出的合同1108来开始媒体流，提议者914和应答者911暗中一致同意执行预先协商的多个AP。
由于在协商806时一些情况的应用(和媒体流开始时的，其在协商806之后立即应用)，任一的对等体将决定另外的，<e2enp：qoscfg>的简化形式可以被包含，其指出新的一个或多个缺省合同1108。
记住分层FSM模式中的缺省状态对应于给定(最后套用的)FSM的初始状态。
在再协商808的情况下，<e2enp：purpose>部分的”模式”属性不被使用。对等体A：接收者/应答者911-对等体B：发送者/提议者914 B：被检测的QoS违反/改变：选择新的QoS级别从预先协商的APs ＝>提议-3.1执行 B：本地-许可-控制(提议-3.1)：成功 B：本地-资源-预留(提议-3.1)：成功 B：执行(提议-3.1)->A(参见注释(3)) A：本地-许可-控制(提议-3.1)：应答-3.1提议-3.1 A：本地-资源-预留(应答-3.1)：成功 A：200OK(应答-3.1-参见注释(4))->B B：执行(命令-开始-预留)->A A：200OK A：网络604预留(基于应答-3.1) B：网络604预留(基于应答-3.1)A.COMET(命令-准备-预留)B B：200OK(COMET的)->A B.COMET(命令-准备-预留)A A：200OK(COMET的)->B
注释(1)：通过添加任何所需资源和/或释放任何过剩资源，两个对等体储备资源相应于关于先前储备资源量的再协商的QoS级别。
注释(2)：对于”Comand-start-reservation”(命令-开始-预留)和”Command-stop-reservation”(命令-停止-预留)的描述请参阅上述内容。
注释(3)：”DO”方法使用”BYE”方法的简易、可靠的确认机制。其它方法也是可能的。比如，再邀请的应用将执行三方确认，其担保对等体以协调和保险方式用新的QoS级别开始媒体流。强迫对等体使用另一个终端或者执行端对端QoS完全再协商808可能是有用的。正确方法的选择还未定论。
注释(4)：这个消息中的”应答-3.1”带有设置为”start-reservation”(开始-预留)的属性”type”(类型)的特征。
在以下部分中，用上述例子中关键词bid-x、answer-y表示的SIP消息环境将被描述。
提议-3.1
在这个例子中，关于已经在上述阶段中协商的信息(由<e2enp：purpose>部分的<use>单元包裹的<session>单元识别的最后一个)，对等体B请求对等体A执行一个替换QoS合同。更具体地说，对等体B请求对等体A执行流级别QoS合同1108”video-contract-2”(视频合同2)，而不是执行缺省”video-contract-1”(视频合同1)，关于当前激活关联”association-1”(关联1)的视频媒体流206”video1”(视频1)。这个命令经由<enforce>部分表示。在这个XML段中，XPath的应用通过一个简化方式被示出以便获得<enforce>部分的概念。一种在此建议的SDPng扩展总体的严格形式描述将在后面提供。
此外，对等体A发现视频合同1不再适用于接入网络604/网络供应商的新类型：因此，对等体A发”block”信号给合同1108。备用合同1108是可用的和当前有效的，”unblock”信号还可以被包括在这个提议中。  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890844526″
          version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″3600″/>
  </session>
  <use>
       <session user＝″Mary″session-id＝″2890843112″
       version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
       addr＝″43.196.180.1″/>
  </use>
   <description
        type＝″request″
        name＝″re-negotiation″/> </e2enp：purpose> <e2enp：enforce>   <xsl：variable name＝″association″>
  <xsl：value-of
  select″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′|″/>  </xsl：variable>  <xsl：variable name＝″stream″>
 <xsl：value-of
 select-″//context[@name＝″$association″]/comp[@ref_adapath＝′video1′]/″/>  </xsl：variable>  <xsl：variable name＝″contract″>
 <xsl：value-of
 select＝″//adapath[@name＝″$stream″]/alt[@ref_contract＝′video-contract-2′]/″/>  </xsl：variable>  <target name＝″$contract″/></e2enp：enforce><e2enp：block>  <xsl：variable name＝″association″>  <xsl：value-of
  select＝″//adapath[@name＝′associations-A-B′]/alt[@ref_contexc＝′association1-1′]″/>  </xsl：variable>  <xsl：variable name＝″stream″>
 <xsl：value-of
select＝″//context[@name＝″$association″]/comp[@ref_adapath＝′video1′]/″/>  </xsl：variable>
<xsl：variable name＝″contract″>
  <xsl：value-of
   celect＝″//adapath[@name＝″$stream″]/alt[@ref_contract＝′video-contract-1′]/″/>
</xsl：variable>
<target name＝″$contract″/>  </e2enp：block>
XML示例35
换言之，对等体B还可以简单地向对等体A指出一些高级信息，其中，对等体A然后将靠采取缺省值来分解剩余的低级信息。比如，以下<e2enp：enforce>部分：
<e2enp：enforce>
  <xsl：variable name＝″association″>
     <xsl：value-of
     select＝″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′]″/>
</xsl：variable>
<xsl：variable name＝″stream″>
  <xsl：value-of
   select＝″//context[@name＝″$association″]/comp[@ref_adapath＝′video1′]/″/>
</xsl：variable>
<target name＝″$stream″/>  </e2enp：enforce>
XML示例36
强迫对等体A使用”video1”(视频1)媒体流206的”videocontract 1”(视频合同1)，因为合同1108在预先协商的<e2enp：qoscfg>部分中被指定为缺省值。此外，对等体B可以请求对等体A切换到完全不同的媒体流206组，从预先协商的信息当中选择。比如，假定对等体A和对等体B之间的媒体流206的当前活动关联是”association1-1”(关联1-1)，则对等体B可以请求对等体A选择”association1-2”(关联1-2)，如同在以下<e2enp：enforce>部分的示例中的一样：  <e2enp：enforce>
<xsl：variable name＝″association″>
   <xsl：value-of
   select＝″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-2′]]″/>   </xsl：variable>   <target name＝″$association″/> </e2enp：enforce>
XML示例37
应答-3.1根据需求31，应答者911将限制它的反应来批准提议者914的提议或者简单地选择低QoS级别，低QoS级别将从预先协商的信息中选择。遵循在前一段落中指出的示例，对等体A然后可以选择接受现有提议或从预先协商信息当中选择一个比较选择方案，其仍然满足提议者914的原提议。
在前一种情况下，”应答-3.1”将看起来如下：
   <e2enp：purpose>
        <session user＝″Mary″session-id＝″2890844526″
          version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″3600″/>
  </session>
  <use>
      <session user＝″Mary″session-id＝″2890843112″
      version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
      addr＝″43.196.180.1″/>
  </use>
  <description
       type＝″response″
       name＝″re-negotiation″/></e2enp：purpose>
XML示例38
应答者911的响应中不存在的<e2enp：enforce>部分指出了，应答者911已经同意提议者914的提议。
在应答者911(这个示例中的对等体A)优先选用较低QoS级别的情况下，”answer-3.1”(应答-3.1)将看起来类似以下：  <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890844526″
          version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
        <expires time＝″3600″/>
   </session>
   <use>
        <session user＝″Mary″session-id＝″2890843112″
        version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
        addr＝″43.196.180.1″/>
   </use>
    <description
         type＝″response″
         name＝″re-negotiation″/>  </e2enp：purpose>  <e2enp：enforce>
<xsl：variable name＝″association″>
   <xsl：value-of
   select＝″//adapath[@name＝′associations-A-B′]/alt[@ref_context＝′association1-1′″/>
</xsl：variable>
<xsl：variable name＝″stream″>
  <xsl：value-of
     select＝″//context[@name＝″$associstion″]/comp[@ref_adapath＝′video1′]/″/>
 </xsl：variable>
 <xsl：variable name＝″contract″>
   <xsl：value-of
   select＝″//adapath[@name＝″$stream″|/alt[@ref_contract＝′video-contract-3′|/″/>
</xsl：variable>
<target name＝″$contract″/>  </e2enp：enforce>
XML示例39
在这个示例中，假设定义比所建议的视频合同1定义的QoS级别低的视频合同3已经在两个对等体之间被预先协商(在前一示例中未示出)。换言之，对等体A可以通过指定另一个关联来指定低级别QoS，类似于前一段落中所描述的：
   <e2enp：purpose>
   <session user＝″Mary″session-id＝″2890844526″
          version＝″2890842807″nettype＝″IN″addrtype＝″IP4″
          addr＝″43.196.180.1″>
       <expires time＝″3600″/>
  </session>
  <use>
      <session user＝″Mary″session-id＝″2890843112″
      version＝″2890841393″nettype＝″IN″addrtype＝″IP4″
      addr＝″43.196.180.1″/>
  </use>
  <description
       type＝″response″
       name＝″re-negotiation″/></e2enp：purpose><e2enp：enforce>  <xsl：variable name＝″association″>
 <xsl：value-of
 select＝″//adapath[@name＝′associations-A-B′/alt[@ref_context＝′association1-2′″/>  </xsl：variable>  <target name＝″$association″/></e2enp：enforce>
XML示例40
在以下部分中，一对多通信方案200中的预先协商802将被描述：
推模式对等体A：提议者914-对等体B1...Bn：应答者106a2 A：本地-许可-控制：(提议-1.1) 成功 A：选项(提议-1.1)->Bj Bj：本地-许可-控制(提议-1.3)： 应答-1.1.Bj Bj：200OK(应答-1.3.Bj)->A         j∈{1，n}
注释(1)：不同的应答”应答-1.1.Bj”可以部分不同地彼此符合或彼此完全不同。实质上，它们相当于上述的”应答-1.1”。
注释(2)：在从对等体Bj接收所有回复之后，对等体A可以执行QoS相关性804和时间同步805约束，并且从而与对等体B再商谈新的较低QoS级别。
拉模式对等体A1...An：提议者106b-对等体B：应答者911 Aj：选项->B B：200OK(提议-1.2)->Aj Aj：本地-许可-控制(提议-1.2)： 应答-1.2.Aj Aj：选项(应答-1.2.Aj)->B Bj：本地-许可-控制(应答-1.2.Aj)： 成功 B：200OK(应答-1.2.Aj)->Aj             j∈{1，n}
注释(3)：不同应答”应答-1.2.Aj”可以部分不同地彼此符合或者彼此完全不同。实质上，”应答-1.2.Aj”相当于上述的”应答-1.2”。”提议-1.2”实质上也相当于上述的提议。
注释(4)：在本地许可控制中，对等体B可以在应答每个对等体Aj之前执行QoS相关性804和时间同步805约束，但是不同Aj通常彼此独立地执行E2ENP 908步骤。
因此，一般来说不可能的是，扣留对选项的应答超过相应的SIP持续时间。换言之，在对等体B可以执行QoS相关性804和时间同步805约束并且因此可以执行与每个对等体Aj的新预先协商802之后，对等体B可以在某个时窗内决定接受请求。
在这种情况下，对等体B然后将扮演提议者914的角色。例如，对等体B可以象在lecture方案中一样是发送者，其与每个接收者首先分别预先协商QoS，并且然后最后重新运行一些预先协商802以便执行QoS相关性804与时间同步805约束。
一对多情况下的预先协商双向连接可以产生实际的多对多连接；因此这个情况在此不被讨论。
双向协商806在此不被介绍，因为这可能产生多对多方案的情况，其中，同步发出应该被特别注释。从而，以下方案对于这种情况有效，其中，一对多关系的”一个”对等体是发送者(接收者)并且这类关系的”多”对等体中的每一个是接收者(发送者)。
推模式对等体A：提议者914-对等体Bai...Bn：应答者106a2 A：本地许可控制(提议-2.1参见注释(1))： 成功 A：本地资源预留(提议-2.1)： 成功 A：邀请(提议-2.1)->Bj Bj：本地许可控制(提议-2.1)： 应答-2.1.Bj5提议-2.1 Bj：本地资源预留(应答-2.1.BJ)： 成功 Bj：183会话进程(应答-2.1.Bj)->A A：最后，使来自不同Bj或要去往不同Bj的媒体流206相互关联 A：本地资源预留(应答-2.1.BJ)：成功(注释(2)) A：PRACK(命令开始预留)->B Bj：200OK(PRACK的) (命令开始预留)->A A：网络604预留(注释(3)) Bj：网络604预留(注释(4)) Bj：COMET(命令准备预留)->AA：200OK(COMET的)->Bj A.COMET(命令准备预留)->Bj B.Bj：200OK(COMET的)->A Bj：180响铃->A Bj：200OK(邀请的)->A A：确认->Bj                                  j∈{1，n}
注释(1)：”提议-2.1”实质上相当于在之前示例中描述的提议。
注释(2)：当Bj应答的时候通过释放任何过剩资源来平衡资源。
注释(3)：通过使用命令开始预留信令，对等体A将能够确定是否网络资源预留应该基于所有{“应答2.1.Bj”}或者只基于其当前可用的任何子集来执行以及确定执行时间。
注释(4)：基于Bj的应答2.1.Bj
拉模式对等体A1...Am：提议者106b-对等体B：应答者911 Aj：邀请->B B：本地-许可-控制(提议-2.2)： 成功 B：本地-资源-预留(提议-2.2)： 成功 B：183会话进程(提议-2.2.Aj)->A Aj：本地-许可-控制(提议-2.2.B)： 应答-2.2.Aj提议-2.2(注释(5)) Aj：本地资源预留(应答2.2.Aj)： 成功 Aj：PRACK(应答2.2.Aj-参见注释(6))->B B：最后使来自不同Aj或去往不同Aj的媒体流206相互关联 B：本地资源预留(应答-2.2.Aj)： 成功 B：200OK(PRACK的)(命令开始预留)->Aj Aj：网络604预留(注释(7)) B：网络604预留(基于所有{应答-2.2.Aj}) B.COMET(命令准备预留)->A Aj：200OK(COMET的)->B Aj.COMET(命令准备预留)->B B：200OK(COMET的)->A B：180响铃-->Aj B：200OK->Aj Aj：确认->B                               j∈{1，m}
注释(5)：不同应答”应答-2.2.Aj”可以部分不同地彼此符合或者彼此完全不同。
注释(6)：”提议-2.2”和”应答-2.2.Aj”实质上相当于(相应地)”提议-2.1”和”应答-2.1”，除了<e2enp：purpose>部分之外，其带有被设置来”拉”的属性”mode”的特征，并且在”应答-2.2.Aj”的情况下，其带有设置来”开始预留”的属性”name”的特征。
注释(7)：基于Bj的”应答-2.2.Aj”。
注释(8)：通过使用命令开始预留信令，对等体A将能够确定是否网络资源预留应该基于所有{“应答-22.Aj”}或者只基于其当前可用的任何子集来执行，以及确定执行时间。一对多情况下的协商双向连接可以产生一个实际的多对多连接；因此这个情况在此不被讨论。
通常，多方连接的再协商808(一对多连接)应该被视作相当于一对一连接的情况。当超过一个的媒体流206应该被同时再协商时，需求37只导致两个特殊情况。这两个情况通过以下环境被确定：
如果中央组件(那个”一”)发现妨碍，则它将检测是否受影响的媒体流206是组的媒体流206和是否它属于一组，以及它是否是受到QoS影响的组中的环境。通过单个媒体流206和通过发现组的环境不受影响，中央组件执行与各个对等体的一对一协商806，否则中央组件执行如下第一种情况中所述的一对多再协商808。
如果”多”对等体中的一个发现妨碍，则它用一对一方式把这个情况发信号到中央组件，这是因为”多”对等体不知道中央组件最后执行的媒体流206组。为了决定中央组件怎样进行检查受影响的媒体流206的从属性：如果媒体流206不属于媒体流组或该组的环境不受影响，则中央组件用一对一方式继续协商806。
如果中央组件发现不仅影响单个媒体流206的从属性，则它发信号到等候中的提议者914(如下情况2所述)，告知从现在开始它将负责再协商808。提议者914将取消它的呼叫并且等候来自中央组件的提议。
以下是关于两个一对多再协商808情况的示例：
1.所给出一对多连接的中央方发现影响所给出组的单个媒体流206的妨碍，根据这个组的配置文件设置(即根据预先协商高级APs)，执行整个媒体流206组的必要适配。在一对多连接的情况下，实际上只有看管媒体流206组的对等体来充当”一”的角色。对等体A：充当”一”的对等体发现妨碍-对等体B1...Bm：受影响的对等体A：被检测的QoS妨碍/改变：选择新的QoS级别来从预先协商的APs执行＝>提议-A|Bj(提议-1j可能对于每个Bj来说相同或不同)A：本地-许可-控制(提议-A|Bj)：成功A：本地-资源-预留(提议-A|j)：成功A：执行(提议-A|Bj)->BjBj：本地-许可-控制(提议-A|Bj)：应答-Bj提议-A|Bj(应答-Bj从预先协商的APs中提取，并且可能对于每个Bj来说是相同或不同的)Bj：本地资源预留(应答-Bj)：成功Bj：200OK(应答-Bj)->AA：最后重新构造流组以满足单一Bj-s的需求并且避免了由受影响组的一个或多个对等体所引起的最后多资源失败。A：执行(命令开始预留)->BjBj：200OK->ABj：网络604预留(基于应答-Aj)A：网络604预留(基于所有的应答-Aj)Bj.COMET(命令准备预留)->AA：200OK(COMET的)->BjA.COMET(命令准备预留)->BjBj：200OK(COMET的)->A                            j∈{1，m}2.”多”对等体中的一个发现妨碍：对等体B：”多”中的一个发现妨碍-对等体A：对媒体流206组负责B：被检测的QoS妨碍/改变：选择新的QoS级别来从预先协商的APs执行＝>提议-1B：本地-许可-控制(提议-1)：成功B：本地-资源-预留(提议-1)：成功B：执行(提议-1)->AA：检查组重新构造的必要性：重新构造必要A：200OK(应答-1)->B(应答-1发信号A被告知妨碍并且准备留意)。剩余部分类似于上述示例
在下面，第三方参与的协商怎样使用E2ENP 908的示例将被描述。
三个协商方是：
A-正在对其进行仲裁的对等体，
B-仲裁者对等体106a1，
和C-处理仲裁者106a1的提议者对等体914。
当提议者914呼叫仲裁装置并且相应的对等体发现它不能独自处理呼叫而可能把呼叫委托到另一个应答者911时，第三方参与的协商被触发。
被发现的应答者911从仲裁者106a1来看是一个替换装置，呼叫提议者914可以通过用户的相应批准来使用它而不是使用仲裁者106a1，仲裁者106a1是那个装置。
与仲裁者106a1预先协商802的目的将允许仲裁者106a1搜集那些对等体的信息，这些信息可能包含于可能的未来改变方向中。
仲裁者106a1可以通过使用一些服务发现机制或通过直接呼叫正在进行简化的被影响对等体来执行搜集，该机制是类似于在JINITM网络604技术(参照http：//www.sun.com/jini/)的发表文件中描述的，在下面被称为[JINI]，和类似于在[BLUE]中描述的蓝牙SDP，等等。
在后一种情况中，预先协商802可以被类似地执行到一对一预先协商802的情况中，其中，仲裁者106a1充当提议者914和对等体的角色，当仲裁被执行后充当应答者911的角色。目前来说，<e2enp：purpose>部分中的特殊标记被要求来指出提议者914是仲裁者106a1(<仲裁模式＝“第三方参与”/>)。
在对其仲裁的那方开始与仲裁者106a1的预先协商802的情况下，SIP方案如下： A：REFER->B B：202被接受->A B：选项->A A：200OK(应答)->B B：告知(应答或参考应答)->A A：200OK
仲裁者106a1刚好挑选A(应答)的设置并且使用它们来执行仲裁。仲裁对等体和提议者914之间的预先协商802与目的部分中的标记的一对一预先协商802非常一致，其中，应答者911是仲裁者106a1(<仲裁模式＝“第三方参与”/>。提议者914将使用推或推拉模式来触发仲裁者106a1的简化功能。不使用”200OK”为OPTIONS的应答，仲裁者106a1使用”380替换服务”从而指出它不是将要通信的对等体。提议者914已经被告知替换对等体存在的阶段，并且在被呼叫用户被告知而且统一使用替换对等体的情况下，提议者914可以通过应用一对一协商806方案来直接开始与替换对等体的协商806。
在具有仲裁者106a1的推或推拉模式中，第三方参与协商将总是被执行以便在它不能支持提议的情况下触发仲裁对等体的简化功能。C：本地许可控制(提议1)：成功C：本地资源预留(提议1)：成功C：邀请(提议1)->BB：本地许可控制(提议1)：不成功(B不能支持提议1中的这类设置)B：183会话进程(应答1)->C(应答包含B将是仲裁者106a1和C将最后预期替换服务为迟些回复的信息)C：PRACK->BB：200OK(PRACK)->CB：检查，是否替换是可用的(询问命名，注册服务)：成功B：检查替换(这些是B最后从预先协商802获知的A的设置)：成功B：询问是否用户同意呼叫：成功(这个信息可以从用户文件中被检索或者通过当时直接向用户发信号来获得，例如通过弹出式GUI窗口或通过播放音调。)B：邀请(提议2)->(提议2是提议1和B是仲裁者106a1的标记的组合)A：本地许可控制(提议2)：应答2提议2A：200OK(应答2)B：确认->AB：通知用户呼叫正在被重新定向和定向到什么装置上。B：重新构造应答2来通知替换服务C：应答2aB：380替换服务(应答2a)->CB：BYE->AA：200OK->B
由于这个协商的结果，对等体C获知对等体A的身份和设置并且可以开始与它的普通一对一协商(参见一对一协商806示例)。
通过仲裁者106a1执行再协商808只在当新的设备将被选择来与完全再协商808通信时的情况下有意义，否则再协商808将变得过于复杂。实际上，这将同E2ENP 908的简单性需求相抵触并且在任何情况下实际上将不合逻辑，这是因为提议者914已经从协商806步骤获知其应答者911的身份。通过由仲裁者106a1进行的再协商808，仲裁者106a1充当一个代理的角色。在完全再协商808的情况下，这个处理与上述的预先协商802和协商806相同。通过再协商808，仲裁者106a1也将满足被协商数据的完成需求。
多对多通信方案300、400和500的构造和协商806是相对于所考虑方案环境独立的，例如会议、游戏等等。一般的解决方案对于这种情况来说是不可能的，而是采取一些下面描述中的准备好的、主题相关的方案：J.Rosenberg和H.Schulzrinne的”Models for Multi-partyConferencing in SIP 910”(IETF SIP 910 PING WorkingGroup，workin progress，<draft-rosenberg-sipconferencing-models-01.txt>)，其在下面被称为[Rosen01]，和J.Rosenberg和H.Schulzrinne发表的”Models for Multi-party Conferencing inSIP”(IETF SIPPING Working Group，work in progress，<draft-ietfsipping-conferencing-models-00.txt>)，其在下面被称为[Rosen00a]，并且按照E2ENP 908发展它们将有助于明白应用多方连接时E2ENP 908的功能。以下示例从[Rosen00a]中取得并且按照与特别的网络有关E2ENP被进一步增强。
考虑到图13中的号码，下列步骤被考虑来应用E2ENP 908：
在号码1-A向B提供它的QoS观点。
在号码4-B向会议服务器提供A和B的QoS观点。
在号码4到14-会议服务器把它对会议(号码5)的观点提供到B并且B向服务器作出它自己的预定。
在号码15-A从B获知会议服务器对会议的观点。
在号码17-A用从B服务器传递的对QoS的观点邀请会议服务器。这些仅仅是对服务器QoS观点的参考，因为A和会议服务器双方都已经知道这个普通的观点。
在号码17到27-A向服务器作出它自己的预留。
在号码32-B向C提供关于会议的服务器观点。
在号码34-C向服务器提供它对根据来自B的信息而被限制的会议的观点。
在号码34到44-C向服务器作出它自己的预留。
在号码45-C告知B它已经准备就绪。
在号码49到52-B另外还告知会议服务器所有方都准备就绪并且服务器会向所有方提供一个起动命令。
从这个例子可以明显地看出，来自考虑预留的一对一方案中的一些办法还可以被应用于用户和会议服务器之间的对等通信。提议和应答通用于上述一对一协商示例中的那些提议和应答。这个示例用一对一方案中相同的方法描述了具有SIP消息的预留程序，唯一的区别是被放置为SDPng开销的消息类别。根据上述示例，最后的对等体可以扮演三个不同的角色：
特别的会议-启动程序-类似B
已经-会议参与者-类似A
新的-会议参与者-类似C
这三个角色对应三种具有相对于被交换的SDPng消息的会议服务器的不同通信模式。
最大通信开销含有B(特设会议始发者)，因为它携带已经会议参与者的所有SDPng消息。B的这个能力是一种仲裁能力，通过强制实施受影响的对等体与会议服务器协商并结束协商以便把控制转送给服务器从而来启动会议。
最小通信开销有一个类似A一样的早先协商参与者，因为早已通知会议服务器关于A的配置文件经由B和A只需要提醒服务器哪一配置文件属于它(参考图13-消息17)。
新的会议参与者C认识来自已经会议参与者的会议服务器配置文件的核实，因此将它的决定组最小化并能使它满足与会议服务器的一个较快协议。
C的通信开销因此大致与一对一通信的相同，因为它不得不独自满足与服务器的协议。
如下示例说明了上述某些故障情况。
一对一通信方案100
预先协商802：
对等体A：提议者914-对等体B：应答者911A：本地许可控制(提议-1.1)：成功A：选项(提议-1.1)->BB：本地许可控制(提议-1.1)：失败B：600忙/603拒绝
注释(1)：如果此刻没有能力处理任何呼叫，则应答者911用”600忙”应答。可替代地，应答者911可以用”603拒绝”应答，表示在稍后时刻呼叫可以发生，这个时间应该是已知的。同样能够使用推和拉模式，但是在拉模式中，”OPTIONS”(选项)呼叫不包含提议。
协商806：对等体A：提议者914-对等体B：应答者911A：本地许可控制(提议)：成功A：本地-资源-预留(提议)：成功A：邀请(提议)->BB：本地许可控制(提议)：不成功B：600忙/603拒绝/606不可接受/380备选服务
注释(2)：如果其它提议者914在发出呼叫中更快并且占有应答者911的所有可用容量，则应答者911发出”600忙”。如果其它提议者914对于发出所述呼叫更快并且占有应答者911的所有可用容量但是应答者911知道所述呼叫将继续多长，则应答者911发出”603拒绝”。这也就是此刻正在处理关于优先权的一个类似事件而呼叫者不得不等待的情况。如果提议者914请求此刻不可用的QoS支持，应答者911发出”606不可接受”。如果提议者914的情形对于他来说是不可接受但是他知道一个可以支持这些情形的备选服务，则应答者911发出”380备选服务”。应该用类似VoD的自动服务来使用这个呼叫。在上面的任何情况中，提议者914可以用”OPTIONS”(选项)开始一个新的呼叫，因为预先协商的情形可能不再有效。这个方案对于所有通信模式都是可应用的(推，拉，推拉)。在它们之间的唯一区别是用”INVITE”(邀请)发送一个初始提议或者稍后发送它(拉模式)。
再协商808：再协商808的失败情况与协商806相同。各个差错指示作为对提议者914的”DO”(实行)呼叫的一个回复而被返回。
一对多方案的协商806阶段的结构非常类似于一对一方案，就此而言，一对一方案中所述的E2ENP 908差错情况在这种情况下也有效。因为一对多方案连接到由”多”对等体引起的多个失败可能性，中央组件(“一”)应该有能力对付此类失败。如下是如何一些建议，建议如何可以对待这些：
-相对于SIP 910信令，在担当”一”的对等体和担当”多”的那些对等体的每一个之间的每个协商806连接将被认为是单一独立的一个。用这种方式，包含在协商806阶段中担当”多”的对等体不必须知道关于所述失败，而组中某些对等体却知道此。失败处理只在中央组件中发生。
-如果某些协商806连接在时限内不成功，则它们将在稍后时刻被调用用于重复协商806。中央组件将或者通过SIP 910呼叫的超时，或者通过接收来自被叫方的SIP差错信息，从而来检测此。E2ENP 908要求一致性而不要求分离，所以在失败之前通过重复呼叫，将足以保存不成功呼叫的当前数据以便获得有关它们当前状态的参考。这意味着由于不需要”undo”(取消)，所以不需要E2ENP 908运行的完整状态保存。
-中央方应当能够在线重新构造媒体流206。如果在所述时限内某些媒体流206再协商不成功，则中央组件因此只重新构造已经成功的那些，并且在稍后的瞬时尽力再协商失败的那些。在这里，同样，成功协商806不必须知道它们中失败的那些。
-中央组件尝试呼叫具有失败协商806的每一方多次，但是是有限次数，比如3次。如果在第三次呼叫之后还存在协商806阶段未成功的各方，则它们将从组中被抛出，并且它们的媒体流206将最终被删去，如果在数据连接上的RTP信令也不存在。此方法将给不成功的”多”对等体有可能有机会恢复并最终独自启动协商806。
-协商806呼叫的并行操作启用协商806的快速执行。就此而言，中央组件将灵活地有可能重新构造它的资源。需要知道中央组件可以服务的并行的多少方，并且如果超过这个限制，中央组件发出”486BusyHere”或者”380 Alternative Service”(380备选服务)(如果中央组件是一个服务并且知道备选的一个)。
如下部分指出第三方协助E2ENP 908的情况，其中再分配108搜索失败：A：本地许可控制(提议1)：成功A：本地资源预留(提议1)：成功A：邀请(提议1)->BB：本地许可控制(提议1)：不成功(B无法支持在提议1中那样的设定)B：183会话进程(应答1)->A(应答包含这样的信息，即：B是一个仲裁者106a1以及A应该稍后把380备选服务最终预期为一个回复)A：PRACK->BB：200OK(PRACK的)->AB：检查，如果备选可用的(询问命名，注册服务)：不成功(在下一行上也可能发生失败)B：检查备选(存在B最终从预先协商802中获知的C的设定)：失败B：606不可接受->A
仲裁者106a1发出信号：没有找到备选项，并且提议者914将再一次以拉模式呼叫，其适应于仲裁者106a1的设定。
如果用户拒绝呼叫再分配108，协商806可能结果是：A：本地许可控制(提议1)：成功A：本地资源预留(提议1)：成功A：邀请(提议1)->BB：本地许可控制(提议1)：不成功(B.无法支持在提议1中那样的设定)B：183会话进程(应答1)->A(应答包含这样的信息，即：B是一个仲裁者106a1以及A应该稍后把380备选服务最终预期为一个回复)A：PRACK->BB：200OK(PRACK的)->AB：检查，如果备选可用的(询问命名，注册服务)：成功，B：检查备选(存在B最终从预先协商802中获知的C的设定)：成功，B：询问用户是否同意呼叫：不成功(从用户配置文件中或者通过当场直接向用户发信号(例如通过跳出一个GUI窗口或者通过播放一个音调等等)，则可以重现这个信息)B：480临时不可用/603拒绝/606不可接受->A
仲裁者106a1应答：
“480临时不可用”，如果用户在某段时间内不对信号或弹出的窗口作出反应，则她/他将应思考不可用。
′603拒绝”，如果用户明确拒绝所述呼叫。
“606不可接受”，如果用户拒绝所述呼叫的委托。
如果与预期应答者911(C方)的协商806不成功或者被委托给一方不接受所述呼叫。A：本地许可控制(提议1)：成功A：本地资源预留(提议1)：成功A：邀请(提议1)->BB：本地许可控制(提议1)：不成功(B无法支持在提议1中那样的设定)B：183会话进程(应答1)->A(应答包含这样的信息，即：B是一个仲裁者106a1以及A应该稍后把380备选服务最终预期为一个回复)A：PRACK->BB：200OK(PRACK的)->AB：检查，如果备选可用的(询问命名，注册服务)：成功，B：检查备选(存在B最终从预先协商802中获知的C的设定)：成功，B：询问，如果用户商定所述呼叫：成功(从用户配置文件中或者通过当场直接向用户发信号(例如通过跳出一个GUI弹出一个音调等等)，则可以重现这个信息)B：邀请(提议2)->C(提议2是提议1和B是仲裁者106a1的指示这二者的组合)...(C出现错误)B：通知B的用户，再分配108不成功，最后通过弹出一个窗口来询问要做什么。B：480临时不可用/603拒绝/606不可接受->A
这些应答的含意是：
“480临时不可用”，如果用户在某段时间内不对信号或弹出的窗口作出反应，则她/他将应思考不可用。
“603拒绝”，如果用户明确拒绝所述呼叫。
“606不可接受”，如果用户想要传送但是所述呼叫的委托失败。这个应答将启动与作为应答者911的仲裁者106a1的新协商806开始。提议者914将考虑以拉模式执行新的协商806以便不触发它的促进功能就把他自己与仲裁者106a1的配置文件适应。
最后，在本基础发明和现有技术之间的主要有利区别可以被简单地汇总如下：
-SDPng 912的使用，用于实现E2ENP 908概念，因此利用由基于XML的文档结构所提供的灵活性，
-在E2ENP 908和应用之间定义的一个清楚接口的定义，由于明示标识符的使用，其把一个给定SDPng 912描述与E2ENP 908过程的给定阶段唯一映射，
-对于好几个多媒体流206，同时描述QoS环境分层结构的能力，
-对于好几个多媒体流206，同时协商QoS环境的分层结构的能力，
-通过使用会话和阶段的概念，好几个多媒体流206的所述QoS环境分层结构的递增协商，和
-代码转换服务核心控制的多个E2ENP外部仲裁者的概念被认为是本发明建议的一个新颖性。
表1：所使用的缩写缩写简短的描述ATM异步传输模式CC/PP合成能力/首选项配置文件CSCW计算机支持的合作工作E2ENP端对端协商协议(E2ENP)HDTV高清晰度电视HTTP超文本传输协议IETF互联网工程任务组IPInternet协议IRT始发者角色令牌MSC信息序列图OS操作系统RDF资源描述框架RTP实时协议RTSP实时媒体流协议RSVP资源预留协议SAP会话通知协议SCCP简单会议控制协议SDP会话描述协议SIP会话启动协议VoD视频点播UML统一模拟语言XML扩展标识语言
表2：描述的特征和它们相应的参考标记参考标记特征100一对一通信方案，示出了在电信会话102的交换情形中的呼叫再分配，其中展现了如何能够安排未来类似电话通信的思想。此方案是描述第三方协商情况的一个特殊一对一通信情况。102在两个用户104a+b之间的电信会话。短语″电信会话″和″多媒体会话″的含意是相同的并且能可相互交换使用。103信令会话104a参与一对一通信方案100的第一用户(Mary)104b参与所述一对一通信方案100的第二用户(Kate)106a1第一用户104a的能够接收呼叫110的互联网启用的移动设备(在这里：互联网启用的手表)在这里被称为″仲裁者″，它可以发出消息，来指示出自像106b之类″提供者″的″who is calling″(谁正在呼叫？)(呼叫者的标识)以及″what the callis all about″(该呼叫是关于什么的？)(主题信息)。″仲裁者″根据用户104a关于该促进的一些预先设定，或者通知它的用户104a有关呼入呼叫，或者自动继续。106a2在第一用户104a室内的视频启用的灵巧终端设备，在这里称为″应答者″106b第二用户104b的终端设备，在这里称为″提供者″108再分配程序110第二用户104b启动的呼叫112要被呈现的数字化高分辨率图片的描述。还进一步被处理为″媒体描述″或″会话信息″。200示出一个虚拟演讲的一对多通信方案。202参与所述一对多通信方案200的演讲者(T.Martin教授)参考标记特征204a参与所述一对多通信方案200的第一个学生(A)204b参与所述一对多通信方案200的第二个学生(B)204c参与所述一对多通信方案200的第三个学生(C)206媒体流208配置文件协商209a演讲者202旅馆房间中的终端209b1第一个学生204a的终端209b2第二个学生204b的终端209b3第三个学生204c的终端300示出一个简单形式电视会议的多对多通信方案302a参与所述多对多通信方案300的第一个用户(Caroline)302b参与所述多对多通信方案300的第二用户(Martha)302c参与所述多对多通信方案300的第三用户(Miranda)302d参与所述多对多通信方案300的第四用户(秘书)304相关信息306a第一用户302a和第二用户302b的共享终端306b第三用户302c的终端306c第四用户302d的终端400示出一个复杂电视会议方案的多对多通信方案402a参与所述多对多通信方案400的第一个用户(Susanne Jones)402b参与所述多对多通信方案400的第二个用户(主考者#1)402c参与所述多对多通信方案400的第三用户(主考者#2)402d作为一个观察者参与所述多对多通信方案400的第四用户(Jones先生)参考标记特征404a第一用户402a的终端404b第二用户402b的终端404c第三用户402c的终端404d第四用户402d的终端500一个示例，示出多方通信方案的一些附加方面，考虑了支持通信各方和业务的发现的一些服务的使用，以及协商的开始。502装备有局域网(LAN)的火车504火车502的移动路由器路由器是关于用户508a和508b设备的″中间组件″。506基站508a参与所述多方通信方案500的第一用户(R.Harris医生)508b参与所述多方通信方案500的第二用户(A.Frank先生)600三个对等体602a-c(A，B和C)的协商806方案的相互作用图，示出了为什么需要提供一致性。602a参与所述协商方案600和700的第一对等体(A)602b参与所述协商方案600和700的第二对等体(B)602c参与所述协商方案600的第三对等体(C)604通信网。在参与一个会话的端终端之间包含″特设解决方案的任何移动网，PAN等等。700两个对等体602a+b(A和B)的协商方案的相互作用图，示出了为什么需要避免僵局，即为什么E2ENP908必须保证没有″保持并等待″的情形，或者只有一个有限期间内可能出现这样一个情形。800表示E2ENP 908的阶段802、804、805和806以及808，以及操作者106b、106a1和106a2的相互作用图802能力、流适配路径和流关联路径的预先协商参考标记特征804在一个给定用户和她/他的对等体之间多个流或者一组流的QoS相关性805在一个给定用户和她/他的对等体之间多个流或者一组流的QoS时间同步806使用阶段802和804期间预先协商的ID来快速协商(利用经济原理)808使用阶段802、804和806期间预先协商的ID来快速再协商(利用经济原理)809完成协商过程810提供者811应答者812中间组件900使用下一代会话描述协议(SDPng，912)和会话启动协议910(SIP)的端对端协商协议(E2ENP的功能性902a提供者106b的E2ENP代理902b应答者106a2的E2ENP代理904a″提供者″的分布式资源管理106b单元904b″应答者″的分布式资源管理106a2单元906a ″提供者″106b的SIP用户代理906b″应答者″106a2的SIP用户代理908端对端协商协议(E2ENP)910会话启动协议(SIP)911应答者912下一代会话描述协议(SDPng)914提供者1000示出所谓的<e2enp alternative-service>(e2enp：备选服务)部分的使用的示例。1100方案，其中从被E2ENP 908使用的用户配置文件和系统配置信息中导出的QoS合同1108被核实。参考标记特征1101用户1102运行在移动用户104a的移动设备106a1上的应用1104匹配逻辑1106核实程序1108由这次908使用的QoS合同1200同时加入两个不同电视会议会话1204a+b的用户1202a(A)的示例1202a加入两个不同电视会议会话1204a+b的第一用户(A)1202b加入第一电视会议会话1204a的第二用户(B)1202c加入所述第一电视会议会话1204a的第三用户(C)1202d加入第二电视会议会话1204b的第四用户(D)1204a第一电视会议会话1204b第二电视会议会话1300被称作″转移到特设″的多对多通信方案的示例。