SIP协议的基本设计思想是将协议的基本功能与功能扩展功能相分离，前者构成稳定而相对简单的SIP基础标准，后者源于增值业务的需要，对应为一系列草案文件，经过一定时间的运行试验，成熟的扩展功能将纳入基础标准。本章将介绍SIP扩展的原则及其具体的SIP、SDP扩展。
一、SIP扩展介绍
当扩展SIP时，必须遵循一定的扩展原则。扩展SIP时，不能破坏SIP简单性和可管理性；不能破坏SIP对等关系；必须保持SIP会话建立过程与SIP会话描述之间的独立性；不要改变原有方法的语义。
二、传送ISUP信令的扩展
1、SIP-T介绍
SIP-T(SIPforTelephones)是基于SIP的一种扩展协议，用于在IP网间传送ISUP信令，以解决PSTN信令在IP网上的协议转换和传送问题。SIP-T将传统电话网信令(目前仅对ISUP消息)通过“封装”和“翻译”转化为SIP消息，提供了用SIP实现传统PSTN网与SIP网络的互连机制。
2、SIP-I协议
SIP-I(SessionInitiationProtocolwithEncapsulatedISUP)由ITU-TSG11制定，SIP-I协议系列包括TRQiBICCVISUPSIP和Q.1912.5o前者定义了SIP与BICC/ISUP互通时的技术需求，包括互通接口模型、互通单元IWU所应支持的协议能力集、互通接口的安全模型等。后者根据IWU在SIP侧的NNI上所应支持的协议能力配置集A、B、C,详细定义了3GPPSIP与BICC/ISUP的互通，一般情况下SIP与BICC/ISUP的互通，等等。
SIP-L基本上与SIP-T相同。但从ISUP封装角度讲，SIP-I不需要使用S/MIME；SIP-I需要接收方能够理解ISUP（必须有Content-Disposition处理参数）；在SIPoverlap信令中，封装在每个INVITE中的是更薪过的IAM,而不是IAM+SAM。从SIP/ISUP消息映射来看，causecode映射不相同；Q.1912.5使用pre-conditions.而RFC3578没有使用；关于ISUP参数，Q.1912.5比RFC3578更详细。最重要的是，SIP-I协议系列具有ITU-T标准固有的清晰性、准确性，可操作性非常强。
三、穿越防火墙
概述
为了尽可能地减少对IPv4地址的耗尽，通常，SIP用户代理处于私网内部，配置为私有IP地址，网络出口配置了NAT/FW来提供网络地址和端口转换功能。私网可以是一级私网或多级私网，在多级私网模型下，第N级以上级私网通常为提供Internet接入的ISP网络，且SIP用户代理可位于不同级私网内部。因此,处于私网内部的SIP用户代理与网外的其他终端用户或媒体服务器发生通信时，应实现SIP协议的NAT/FW穿越和RTP/RTCP流的NAT/FW穿越。
根据NAT类型不同，NAT可分为静态NAT、动态NAT和NAPT。根据NAT工作方式不同，NAT类型可分为FullCone方式NAT、RestrictedCone方式NAT、PortRestrictedCone方式NAT和SymmetricCone对称方式NAT,具体可参见RFC3489。因此,SIP协议的NAT穿越应支持多种NAT类型和多种NAT工作方式的穿越。
SIP协议穿越NAT/FW存在的问题
1.数据包地址与载荷部分地址不一致
在SIP协议的呼叫建立过程中，消息接收方始终按照协议载荷内的源地址和端口信息来回传响应消息和发送相应的媒体流。当H.323终端和SIP终端通过NAT/FW进行地址转化时，NAT/FW会将IP包头中的源IP地址和源端口号转换为NAT/FW的网络出口地址，从而造成载荷内的地址和端口（如SDP部分中的地址和端口）与IP包头的源地址和源端口的不一致。此时，消息接收方无法将响应消息正确回传到消息发送方，主被叫方无法建立正常通信连接。
2.媒侔流端口动态分配
S疋终端所使用的媒体流端口需要通过SIP信令呼叫流程来进行动态协商。因此，动态创建的媒体流端口之间的连接将被防火墙阻断。
3.防火墙端口主动开放
防火墙配置是允许内部用户主动访问外部，不允许外部用户主动访问内部。因此，在不采用相应策略的情况下，网外用户发起到网内的呼叫将被拒绝，即网内用户只允许做主叫不允许做被叫。如果允许网内用户做被叫，则防火墙需要增加相应策略，开放几乎所有网外IP地址,从而给内部网络带来严重的安全隐患。
参考模型
支持SIP协议的NAT/FW穿越可分为信令和媒体穿越两部分，信令穿越和媒体穿越的功能可以分别由信令中继功能(SRF)和媒体中继功能(MRF)来完成，当SRF和MRF采用独立的物理实体来实现时，SRF和MRF之间的接口协议可采用MIDCOM协议或其他协议(其他协议待定)。当采用信令和媒体穿越分离的模型时，SRF功能可以集成于服务器中，MRF功能可以集成于NAT设备中。-
信令和媒体穿越不分离时，可采用代理技术和隧道技术。
协议扩展
SIP终端利用私有IP地址有两种情况，一种为主叫用私有IP地址发起请求和接受响应，另一种为被叫通过私有IP地址接受请求和回送响应。
第一种情况，当位于NAJ后的SIP终端与外界通信时，需要在SIP终端发出的INVITE请求中加入扩展字段rport,表明需要穿透NAT。经过NAT处理后的消息送到SIP代理服务器，代理服务器发现SIP消息中含有rport字段，从而确认INVITE请求经过了NAT,SIP服务器记录经过NAT后临时分配的合法IP地址和端口号。这时需要另外一个扩展字段received,并将NAT临时分配的合法IP地址和端口号分别放到received和rport中。以后当NAT网关收到代理的消息后，将查找相应NAT对应表，将UDP包中的目的地址和端口替换成内部的私有地址，再转发给内部网络。
第二种情况，则需要添加新的字段Translate,以起翻译作用。
四、临时应答的可靠传输
SIP应答分为正常应答和临时性应答，对于前者可保证可靠传输，而对于后者，RFC3261并未保证可靠传输，RFC3262定义了用于可靠传输临时应答的SIP扩展。这种新的扩展称为PRACK(ProvisionalResponseACK),UAS会不断重传临时应答，直到收到UAC的确认为止，一旦UAS收到UAC收到的PRACK,便停止重传。但PRACK自身也需要确认，所以UAS也必须为PRACK发送一个200应答,表明PRACK成功。目前,IANA为PRACK分配了标志：lOOreh'
五、用户偏好扩展
不同的呼叫者可能具有不同的个人偏好，为此SIP扩展中定义了三个新的标题头和Contact参数，其适用范围如下表所示。
三个头的BNF语法描述如下:
1.Request-Disposition
Request-Disposition=("Request-Disposition"/"d")HCOLONdirective*(COMMAdirective)其中，directive=proxy-directive/cancel-directive/fork-directive/recurse-directive/parallel-directive/queue-directive)
proxy-directive="proxy"/"redirect1*
cancel-directive="canceln/"no-cancel"
fork-directive="fork"/"no-fork"
recurse-directive="recurse"/"no-recurse"
parallel-directive二"parallel"/"sequential"
queue-directive="queue"/"no-queue"
2.Accept-Contact
Accept-Contact=("Accept-Contact"/"a")HCOLONac-value*(COMMAac-value)其中，ac-value=n*"*(SEMIac-params)
rc-value=*(SEMIrc-params)
ac-params=feature-param/req-param/explicit-param/generic-param
rc-params=feature-param/generic-param
req-param="require"
explicit-param="explicit"
3.Reject-Contact
Reject-Contact=("Rqect-Contact"/Hj")HCOLONrc-value*(COMMArc-value)各参数的含义同Accept-Contacto
会议中的信号信息传过会议后的SIP信令通路的建立是必要的。这个通路是SIP的 re-INVITEs、BYEs和其他与一个独立会话联系的SIP请求所采用的。它允许SIP代理服务器 接收并潜在地对会议中的信号信息起作用。
•在PSTN网关之间传送呼叫中的PSTN信令消息。
•传送SIP会议中生成的DTMF数字。
•传送无线信号强度信息以支持无线移动应用。
•在会议的参加者之间传送影像或其他的信息。
INFO方法的信令通路是呼叫建立之后建立的信令通路。这可以是呼叫方与被呼叫方用户 代理之间的直接信令，也可以是包括牵涉到呼叫建立和自己增加到初始INVITE信息记录路由 头部的SIP代理服务器的信令通路。
会议中信息能够在INFO信息头部或作为一个消息体的一部分来进行通信。消息体和/或 消息头部的定义被用来传送在本文档讨论范围之外的会议中信息。
如果INFO请求与任何现存的呼叫leg不匹配，那么一个481呼叫Leg/Transaction不存在 的消息必须在一个UAS中被发送。
如果一个服务器收到一个其能理解消息体的INFO请求，但是它又对与INFO过程有关的 消息体规则没有一点了解，那么这个消息体可能被翻译并显示给用户。这个INFO被一个200 0K所回应了。
如果INFO请求包括一个服务器不能理解的消息体，那么在INFO相关的消息体的进程规 则缺乏时，服务器必须回应一个415不支持的媒体类型消息。
那些在SIP呼叫状态中或被SIP初始化后的会议中完成一个改变的消息体不能被放在一个 INFO消息中发送。
，其他请求失败（4xx）、服务器失败（5xx）和全局失败（6xx）回应将被送给INFO请求。
如果一个最终的回应没有被送给INFO,那么一个UAS的取消（CANCEL）将用一个“487 请求已取消”回应给INFO。然而，INFO消息决不许改变SIP呼叫的状态或SIP初始化的回应。
另外，INFO方法并不定义确保按顺序传送的附加机制。
3.6.4利用INFO扩展的指导方针
以下是在定义利用INFO方法的SIP扩展时必须考虑的几个方面：
•被INFO消息传送的消息体的大小必须要考虑。由于消息将可能在UDP上传送，并 且可能重组一个大的消息，消息体应该保持较小。
•有一种可能是INFO消息能被一个SIP代理服务器创建。完成这一 INFO消息中的信 息的创建过程需要被考虑。
•当定义被INFO消息传送的消息体时，大部分消息体的应用将会很有用。
•用INFO消息的扩展不允许依靠INFO消息做那些影响SIP呼叫的状态或相关会议的 状态的事。
•本文档定义的INFO扩展不依赖于请求或代理请求头部的应用。用INFO消息的扩展 名可能需要应用这些机制。然而，有可能请求或代理请求的应用最好能避免，以便在 SIP实体间可以互操作。
3.7 SIMPLE
即时消息/存在技术目前到了一个转折点。缺少基于标准的可互操作的IM/存在(Presence) 系统造成难于控制和监测这种流行业务工具的部署。专有网络和协议也阻碍IM用户与所在单 位之外的其他人相互通信。
用户需要的是一种实现IM/存在技术的统一的协议，其作用正如简单邮件传输协议、HTTP 和实时协议(RTP)对于电子邮件、Web和语音流的作用。解决方案是“即时消息与存在利用 扩展会话初始协议” (SIMPLE)o
Internet工程任务组的SIMPLE工作组受命定义一套SIP扩展。该小组预计将于今年公布 一项建议标准。IETF的IM与存在协议工作组在RFC 2778和2779中公布了对IM/存在技术的 一般要求和它的模型。
1. 简单方式
SIMPLE在本质上与SIP相同:SIP没有采用GET和POST等数据索取方式,而采用INVITE 和BYE等信令方式来启动和结束一次呼叫或会话。
SIMPLE增加了一种叫做MESSAGE的新的请求方式来发送所谓寻呼模式IM的一次性 IM。SUBSCRIBE被用于请求将存在信息发送给请求方，而NOTIFY则被用于传输存在信息。
通信各方在一段时间交换多条消息的更长时间的IM会话利用INVITE和一种名为“消息 会话中继协议”(MSRP)的传输协议来启动。当与SIMPLE 一同使用时，MSRP用于传送IM 的文本，就像在SIP中RTP用于传送一次IP电话呼叫中的语音包。
IM/Presence基础设施中的许多部分可重复利用SIP。例如，一个IM客户机向SIP注册服 务器发送REGISTER消息，通知它可以接收IM。正如在普通SIP系统中一样，注册服务器处 理来自端点的登录。
2. 传播消息
IM客户机直接或通过SIP代理服务器和SIP重定向服务器，向其他每一个IM客户机发 送实际的IM流和最新的存在信息。SIP代理服务器在SIP系统元素（'如SIP电话）之间转发 SIP请求，重定向服务器则被用于告之客户机有关已经移动的通信方的信息。
IM客户机利用MIME发送多媒体请求。由于SIP被设计为可方便地像对一个端点传送信 令那样，向一组端点传送信令，因此多方IM和聊天室已经得到了支持。
IM/存在与SIP的关系就像是SMS与移动电话信令系统的关系。SMS利用移动电话网搭 载文本消息，IM/存在则搭载在SIP上，SIP就是Intemet格式的电话信令。
3.8 SIP多方会议扩展
多媒体会议系统中传输的信息流包含音频、视频、数据和控制信息，会议系统主要包含 两个部分内容：（1）使得参与者可以加入或者离开会议；（2）会议控制，其中包括会议管理 （如创建、修改和删除会议）、用户管理（增加和删除会议参与者，修改他们的属性）和底层 （Floor）管理。会议系统中各种元素的不同组织方式构成了不同类型的会议模型，一般会将 会议系统分为3种类型，即集中型、分散型和混合型。
图3-1为基于多代理服务器的会议模型，为了方便起见，以会议模型中的拨入模型讨论会 议的一致性。对于媒体服务器而言，它接收多个Proxy的控制消息，并维护与每个加入的Proxy 的连接。在有参与者加入会议时，Proxy通知媒体服务器有新的UA加入，以便媒体服务器组 织媒体流和数据信息，同时要让新的参与者知道这是一个会议，有若干个用户代理（UA）在 会议中。这里不采用中心会议成员服务器，当UA呼叫某个会议时，Proxy对定位服务器查询, 确定处于会议中的其他Proxy,然后通过与其他Proxy的信息交流，通知其他成员有新成员 加入。当然，仅使用原来的SIP方法是不够的，必须对SIP功能扩展，以使得SIP支持多代理 的多媒体会议。
在由A、B、C、D和4个UA组成的会议中，Proxy 1> Proxy2也为会议的组成部分，当 UA E要加入会议时，E向其本地Proxy3发出INVITE消息，Proxy3向Location Service定位 媒体服务器的地址，在E加入会议之后，E将向媒体服务器发送媒体流，并从媒体服务器接收 媒体流。
Proxy3同时向Proxy 1和Proxy2发送用户E加入会议的消息'Proxy 1和Proxy2向各自的 状态成员发送E加入会议的消息，在得到各自参与者的ACK后，再向Proxy3发送ACK。如 果某个状态成员在一定时间内没有返回ACK,则认为该用户不愿意让其他参与者知道其存在。
INFO 扩展
一、INFO 筒介
1、INFO目的
没有通用的目标机制来在会话过程中沿着SIP信令通路承载会话控制信息。INFO消息的 目的是沿着SIP信令通路携带应用层消息。INFO方法并不是用来改变SIP呼叫的状态或会议 SIP的初始化状态参数。它仅是用于发送通常与会议有关的应用层的可选信息。会议中的信号信息传过会议后的SIP信令通路的建立是必要的。这个通路是SIP的 re-INVITEs、BYEs和其他与一个独立会话联系的SIP请求所采用的。它允许SIP代理服务器 接收并潜在地对会议中的信号信息起作用。
2、用法举例
以下是一些INFO消息的可能应用：•在PSTN网关之间传送呼叫中的PSTN信令消息。
•传送SIP会议中生成的DTMF数字。
•传送无线信号强度信息以支持无线移动应用。
•在会议的参加者之间传送影像或其他的信息。
二、INFO 方法
INFO方法被用于沿着呼叫的信令通路进行会议中信令消息间的通信。INFO方法并不是 用于改变SIP呼叫的状态，也不是用于改变被SIP初始化的会议状态。然而，它提供增加的选 项信息可以进一步加强SIP的应用程序功能。INFO方法的信令通路是呼叫建立之后建立的信令通路。这可以是呼叫方与被呼叫方用户 代理之间的直接信令，也可以是包括牵涉到呼叫建立和自己增加到初始INVITE信息记录路由 头部的SIP代理服务器的信令通路。
会议中信息能够在INFO信息头部或作为一个消息体的一部分来进行通信。消息体和/或 消息头部的定义被用来传送在本文档讨论范围之外的会议中信息。
1.INFO请求方法的响应
如果服务器收到一个INFO请求，其必须发出一个最后的回应。如果INFO请求被现有的 呼叫成功地接收到，则UAS必须发送一个200 OK没有消息体的回应给一个INFO请求。在 此之外，不需要其他的操作。INFO相关的头使用范围如表3-3所示。
表3-3 INFO相关头使用范围
| 头部（Header） | 地方（Whew） | 信息（INFO） |
| 接收Accept | R | o |
| 接收 编码 Accept-Encoding | R | 0 |
| 接收一语言 Accept-Language | R | 0 |
| 允许Allow | 200 | |
| 允许Allow | 405 | 0 |
| 认可 Authorization | R | 0 |
| 呼叫号Call-ID | gc | m |
| 连接 Contact | R | 0 |
| 连接 Contact | Ixx | - |
| 连接 Contact | 2xx | |
| 连接 Contact | 3 xx | |
| 连接 Contact | 485 | |
| 连接 编码 Content-Encoding | e | 0 |
| 内容 长度 Content-Length | e | 0 |
| 内容一类型 Content-Type | e | * |
| CSeq | gc | m |
| 数据Date | g | 0 |
| 加密 Encryption | g | 0 |
| 期满Expires | g | 0 |
| From | gc | m |
| 隐藏Hide | R | 0 |
| 最大一向前流Max-Fonvards | R | 0 |
| 组织 Oi^anization | g | 0 |
| 优先权 | R 1 | 0 |
| 头部（Header） | 地方（Where） | 信息（INFO） |
| Proxy验证 | 407 | 0 |
| Proxy验证 | R | o |
| Proxy-需求 | R | 0 |
| 请求 … | R | 0 |
| 重试-之后 | R | |
| 重试-之后 | 404,480,486 | 0 |
| 重试•之后 | 503 | 0 |
| 重试-之后 | 600,603 | 0 |
| 回应-关键字 | R | 0 |
| 记录-路由 | R | 0 |
| 记录-路由 | 2xx | 0 |
| 路由 | R | 0 |
| 服务器 | r | 0 |
| 主体 | R | 0 |
| 时崗戳 | g | 0 |
| To劉； | gc(l) | m |
| 不支持的 ' | 420 | 0 |
| 用户代理 | g | o |
| Via | gc⑵ | m |
| 告警 | r | o |
| ,WWW-验证 | 401 | o |
如果INFO请求与任何现存的呼叫leg不匹配，那么一个481呼叫Leg/Transaction不存在 的消息必须在一个UAS中被发送。
如果一个服务器收到一个其能理解消息体的INFO请求，但是它又对与INFO过程有关的 消息体规则没有一点了解，那么这个消息体可能被翻译并显示给用户。这个INFO被一个200 0K所回应了。
如果INFO请求包括一个服务器不能理解的消息体，那么在INFO相关的消息体的进程规 则缺乏时，服务器必须回应一个415不支持的媒体类型消息。
那些在SIP呼叫状态中或被SIP初始化后的会议中完成一个改变的消息体不能被放在一个 INFO消息中发送。
，其他请求失败（4xx）、服务器失败（5xx）和全局失败（6xx）回应将被送给INFO请求。
2. SIP用户代理的行为
INFO请求的协议规则控制了标记（tags）的用法。如果一个最终的回应没有被送给INFO,那么一个UAS的取消（CANCEL）将用一个“487 请求已取消”回应给INFO。然而，INFO消息决不许改变SIP呼叫的状态或SIP初始化的回应。
三、 INFO消息体
INFO消息的目的是在SIP用户代理间传送会议中的信息。这一信息尽管能够在INFO信 息头中传送，但它一般将被放在消息体中传送。另外，INFO方法并不定义确保按顺序传送的附加机制。
3.6.4利用INFO扩展的指导方针
以下是在定义利用INFO方法的SIP扩展时必须考虑的几个方面：
•被INFO消息传送的消息体的大小必须要考虑。由于消息将可能在UDP上传送，并 且可能重组一个大的消息，消息体应该保持较小。
•有一种可能是INFO消息能被一个SIP代理服务器创建。完成这一 INFO消息中的信 息的创建过程需要被考虑。
•当定义被INFO消息传送的消息体时，大部分消息体的应用将会很有用。
•用INFO消息的扩展不允许依靠INFO消息做那些影响SIP呼叫的状态或相关会议的 状态的事。
•本文档定义的INFO扩展不依赖于请求或代理请求头部的应用。用INFO消息的扩展 名可能需要应用这些机制。然而，有可能请求或代理请求的应用最好能避免，以便在 SIP实体间可以互操作。
3.7 SIMPLE
即时消息/存在技术目前到了一个转折点。缺少基于标准的可互操作的IM/存在(Presence) 系统造成难于控制和监测这种流行业务工具的部署。专有网络和协议也阻碍IM用户与所在单 位之外的其他人相互通信。
用户需要的是一种实现IM/存在技术的统一的协议，其作用正如简单邮件传输协议、HTTP 和实时协议(RTP)对于电子邮件、Web和语音流的作用。解决方案是“即时消息与存在利用 扩展会话初始协议” (SIMPLE)o
Internet工程任务组的SIMPLE工作组受命定义一套SIP扩展。该小组预计将于今年公布 一项建议标准。IETF的IM与存在协议工作组在RFC 2778和2779中公布了对IM/存在技术的 一般要求和它的模型。
1. 简单方式
SIMPLE在本质上与SIP相同:SIP没有采用GET和POST等数据索取方式,而采用INVITE 和BYE等信令方式来启动和结束一次呼叫或会话。
SIMPLE增加了一种叫做MESSAGE的新的请求方式来发送所谓寻呼模式IM的一次性 IM。SUBSCRIBE被用于请求将存在信息发送给请求方，而NOTIFY则被用于传输存在信息。
通信各方在一段时间交换多条消息的更长时间的IM会话利用INVITE和一种名为“消息 会话中继协议”(MSRP)的传输协议来启动。当与SIMPLE 一同使用时，MSRP用于传送IM 的文本，就像在SIP中RTP用于传送一次IP电话呼叫中的语音包。
IM/Presence基础设施中的许多部分可重复利用SIP。例如，一个IM客户机向SIP注册服 务器发送REGISTER消息，通知它可以接收IM。正如在普通SIP系统中一样，注册服务器处 理来自端点的登录。
2. 传播消息
IM客户机直接或通过SIP代理服务器和SIP重定向服务器，向其他每一个IM客户机发 送实际的IM流和最新的存在信息。SIP代理服务器在SIP系统元素（'如SIP电话）之间转发 SIP请求，重定向服务器则被用于告之客户机有关已经移动的通信方的信息。
IM客户机利用MIME发送多媒体请求。由于SIP被设计为可方便地像对一个端点传送信 令那样，向一组端点传送信令，因此多方IM和聊天室已经得到了支持。
IM/存在与SIP的关系就像是SMS与移动电话信令系统的关系。SMS利用移动电话网搭 载文本消息，IM/存在则搭载在SIP上，SIP就是Intemet格式的电话信令。
3.8 SIP多方会议扩展
多媒体会议系统中传输的信息流包含音频、视频、数据和控制信息，会议系统主要包含 两个部分内容：（1）使得参与者可以加入或者离开会议；（2）会议控制，其中包括会议管理 （如创建、修改和删除会议）、用户管理（增加和删除会议参与者，修改他们的属性）和底层 （Floor）管理。会议系统中各种元素的不同组织方式构成了不同类型的会议模型，一般会将 会议系统分为3种类型，即集中型、分散型和混合型。
图3-1为基于多代理服务器的会议模型，为了方便起见，以会议模型中的拨入模型讨论会 议的一致性。对于媒体服务器而言，它接收多个Proxy的控制消息，并维护与每个加入的Proxy 的连接。在有参与者加入会议时，Proxy通知媒体服务器有新的UA加入，以便媒体服务器组 织媒体流和数据信息，同时要让新的参与者知道这是一个会议，有若干个用户代理（UA）在 会议中。这里不采用中心会议成员服务器，当UA呼叫某个会议时，Proxy对定位服务器查询, 确定处于会议中的其他Proxy,然后通过与其他Proxy的信息交流，通知其他成员有新成员 加入。当然，仅使用原来的SIP方法是不够的，必须对SIP功能扩展，以使得SIP支持多代理 的多媒体会议。
Proxy3同时向Proxy 1和Proxy2发送用户E加入会议的消息'Proxy 1和Proxy2向各自的 状态成员发送E加入会议的消息，在得到各自参与者的ACK后，再向Proxy3发送ACK。如 果某个状态成员在一定时间内没有返回ACK,则认为该用户不愿意让其他参与者知道其存在。
