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所示。
如果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支持多代理 的多媒体会议。
在由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 筒介
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,则认为该用户不愿意让其他参与者知道其存在。
相关阅读:
来源:科能云通讯 联系电话:02883110277