一、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,则认为该用户不愿意让其他参与者知道其存在。
