会话初始协议ISP技术要求-中国通信行业标准(8)

时间:2008-10-19 来源: 作者: 点击:
接受定制的能力应该由定制者的用户直接进行控制, 因为许多类型的事件都和隐私有关。同样通知者使用标准的SIP 鉴权机制,应该能够根据定制者标识(基于接入控制列表)有选择地拒绝定制。 G.5.2 通知者保密机制 在某
  
接受定制的能力应该由定制者的用户直接进行控制, 因为许多类型的事件都和隐私有关。同样通知者使用标准的SIP 鉴权机制,应该能够根据定制者标识(基于接入控制列表)有选择地拒绝定制。
G.5.2 通知者保密机制
在某些情况下, 对SUBSCRIBE 请求仅返回200 或某些4xx 和6xx 类响应,可能会暴露策略信息。在这些情况下,通知者应总是回送响应202 。虽然后续的NOTIFY 消息可能不会传送真正的状态,但是它必须包含定制者可以隐含获取的正确的数据, 该数据不能从有效的响应中区分出。在这种情况下,关于用户是否有权定制请求状态的信息永远不会回送到发送SUBSCRIBE 的用户。
能够实现该操作模式的事件包及相关文档可以进一步描述如何和为什么产生隐蔽的正确数据。
G.5.3 拒绝业务攻击
当前模式对于增强的节点来说是一个可在smurf 攻击中使用的典型模式(一个SUBSCRIBE 请求触发一个SUBSCRIBE 响应和一个或多个NOTIFY 请求)。
当收到SUBSCRIBE 请求时攻击者可能使用创建的状态来消除受害者机器上的资源,使资源看来不可用。
要减少这样的功绩,通知者应要求鉴权。
G.5.4 重发攻击
重发SUBSCRIBE 或NOTIFY 可能产生有害的影响。
使用SUBSCRIBE 消息, 攻击者可能设置任意多个它以前曾经设置过的定制。重发NOTIFY 消息可用于伪造过时的状态信息(虽然NOTIFY 消息体的版本号可以帮助减轻这类攻击)。禁止发送NOTIFY 消息到没有定制事件的节点也可以帮助减轻这类攻击。
要防止这类攻击,实现时应利用反重发保护机制进行鉴权。
G.5.5 定制设置后的攻击
即使有鉴权机制,使用SUBSCRIBE 在定制设置之后的攻击可用来设置任意多个定制、冒充现有的定制、终止现有的定制、或修改定制作用的资源。要防止这种类型的攻击, 实现时至少应通过SUBSCRIBE 消息中的"Contact" 、 "Route" 、"Expires" 、"Event" 、和 "To" 头部字段提供一套完整的保护机制。如果SUBSCRIBE 体用于进一步定义和呼叫状态有关的信息,那么该消息体应包括在完整的保护机制中。
定制设置后的攻击也可以使用NOTIFY 消息冒充任意的状态信息或/和终止现有的连接。要防止这类攻击,实现时应通过"Call-ID" 、 "CSeq" 、和"Subscription-State" 头部字段以及NOTIFY 消息体提供一套完整的保护机制。
G.5.6 保密性
NOTIFY 消息中的状态信息很可能包含敏感信息。实现时可以对这些信息进行加密。
虽然很少发生,但是SUBSCRIBE 消息也可能包含用户不希望暴露的信息。实现时可以对这些信息进行加密。
为了允许远端用户隐藏它认为敏感的信息,所有的实现应能够处理加密的SUBSCRIBE 消息和NOTIFY 消息。
G.6 语法
本节描述事件通知要求的语法扩展。形式语法定义使用ABNF 格式。
G.6.1 新方法
本文定义了两个新的SIP 方法:SUBSCRIBE 和NOTIF 。
下表是对SIP 中表2 和表3 的扩展:
头部字段 位置 SUBSCRIBE NOTIFY
Accept R o o
Accept 2xx - -
Accept 415 o o
Accept-Encoding R o o
Accept-Encoding 2xx - -
Accept-Encoding 415 o o
Accept-Language R o o
Accept-Language 2xx - -
Accept-Language 415 o o
Alert-Info R - -
Alert-Info 180 - -
Allow R o o
Allow 2xx o o
Allow r o o
Allow 405 m m
Authentication-Info 2xx o o
Authorization R o o
Call-ID c m m
Contact R m m
Contact 1xx o o
Contact 2xx m o
Contact 3xx m m
Contact 485 o o
Content-Disposition o o

Content-Encoding o o
Content-Language o o
Content-Length t t
Content-Type * *
CSeq c m m
Date o o
Error-Info 300-699 o o
Expires o -
Expires 2xx m -
From c m m
In-Reply-To R - -
Max-Forwards R m m
Min-Expires 423 m -
MIME-Version o o
Organization o -
Priority R o -
Proxy-Authenticate 407 m m
Proxy-Authorization R o o
Proxy-Require R o o
RAck R - -
Record-Route R o o
Record-Route 2xx,401,484 o o
Reply-To - -
Require o o
Retry-After 404,413,480,486 500,503 600,603 o o
Route R c c
RSeq 1xx o o
Server r o o
Subject R - -
Supported R o o
Supported 2xx o o
Timestamp o o
To c(1) m m
Unsupported 420 o o
User-Agent o o
Via c m m
Warning R - o
Warning r o o
WWW-Authenticate 401 m m

G.6.1.1 SUBSCRIBE 方法

SUBSCRIBE 是SIP 中新增加的方法。
和所有的SIP 方法名相同,SUBSCRIBE 方法名区分大小写。SUBSCRIBE 方法用于请求随后一个事件或一组事件的异步通知。
G.6.1.2 NOTIFY 方法
NOTIFY 是SIP 中新增加的方法。
NOTIFY 方法用于通知SIP 节点先前由SUBSCRIBE 请求的事件已经发生。该方法也可以提供与该事件有关的更进步的详细信息。
G.6.2 新的头部字段
下面的表是对SIP 中表2 和表3 的扩展,并增加了上节中描述的变化:
头部字段 位置 代理 ACK BYE CAN INV OPT REG PRA SUB NOT
Allow-Events R o o - o o o o o o
Allow-Events 2xx - o - o o o o o o
Allow-Events 489 - - - - - - - m m
Event R - - - - - - - m m
Subscription -State R - - - - - - - - m

G.6.2.1 "Event" 头部字段
"Event" 是新增加在sip 消息头部中的定义。
为了将响应消息和NOTIFY 消息与SUBSCRIBE 消息进行匹配,需要逐字节地比较"Event" 头部字段中的事件类型部分,并且需要逐字节地比较"id" 参数标记(如果消息中包含该参数)。包含"id"参数的"Event" 头部字段永远不会和未包含"id" 参数的"Event" 头部字段相匹配。但进行比较时不需要考虑其他参数。
例如:"Event: foo; id=1234" 和"Event: foo; param=abcd; id=1234" 相匹配,但是"Event: foo"
(未包含"id" 参数)和"Event: Foo; id=1234" 不匹配。本文没有定义事件类型的值。这些值将在单独的事件包种定义,但必须使用IANA 注册。事件头部字段中只能列出一个事件类型,不允许在消息中列出多个事件。
G.6.2.2 "Allow-Events" 头部字段
"Allow-Events" 头部字段是SIP 协议中新定义的字段。
G.6.2.3 "Subscription-State" 头部字段
"Subscription-State" 头部字段是SIP 协议请求头部中新定义的字段。
.G.6.3 新的响应代码
.G.6.3.1 "202 接受"响应代码

202 响应增加到"Success" 头部字段定义中。"202 接受"的含义和HTTP/1.1 中定义的含义相同。
G.6.3.2 "489 错误事件"响应代码
489 事件响应增加到"Client-Error" 头部字段定义中。"489 错误事件"用于指示服务器不能理解"Event" 头部字段中定义的事件包。
G.6.4 ABNF 定义
158
对各种新的和修改过的语法单元的ABNF 定义如下所示。
SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps extension-method = SUBSCRIBEm / NOTIFYm / token Event = ( "Event" / "o" ) HCOLON event-type
*( SEMI event-param ) event-type = event-package *( "." event-template ) event-package = token-nodot event-template = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" ) event-param = generic-param / ( "id" EQUAL token )
Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type *(COMMA event-type)
Subscription-State = "Subscription-State" HCOLON substate-value
*( SEMI subexp-params )
substate-value = "active" / "pending" / "terminated"
/ extension-substate
extension-substate = token
subexp-params = ("reason" EQUAL event-reason-value)
/ ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds)
/ generic-param
event-reason-value = "deactivated"
/ "probation"
/ "rejected"
/ "timeout"
/ "giveup"
/ "noresource"
/ event-reason-extension

event-reason-extension = token
附录 H (标准性附录)
OPEN ISSUE
E.1 概述 RFC3261 种定义了用reINVTE 来修改会话属性的过程。但是它只针对已经建立的会话。在某些应
用场合下,需要在会话建立之前对相关属性进行修改。例如:SIP-PSTN 互通时,主被叫之间在通话之,间需要建立放音的媒体流通道(我们称之为Early Media)真正通话时有需要修改为实际通话的媒体流。这就要求协议提供一种在会话建立之前修改相关属性的机制。RFC3311 提出了用UPDATE 消息来修改会话属性的扩展功能。
E.2 UPDATE 能力支持的协商 RFC3311 定义了一个新的消息UPDATE 。支持本扩展的UAC 在发送INVITE 请求时,应该在Allow 头域中包含UPDATE ,表示能够接受
UPDATE 消息。UAS 在返回的1XX 或者2XX 响应中也可以包含UPDATE,表示UAS 能够接受UPDATE 消息。
.E.3 UPDATE 消息的处理
.E.3.1 发送UPDATE 请求会话中的任意一方都可以发送UPDATE 请求。改消息的构造遵循通用的Dialog 中的请求消息规范(参见RFC3261 规范第12 章)。

UPDATE 消息中可以包含更新的SDP 请求。交互过程中的SDP 协商规范必须遵循:在一次SDP 协商过程(请求/应答)完成之前,不能发起新的协商过程。
E.3.2 接收UPDATE 请求
UAS 收到UPDATE 消息后, 必须检查其中的SDP 是否更改, 并对相应的会话参数做出调整。如果新的媒体描述不可接受,UAS 可以返回488 拒绝响应。UAS 根据具体的处理情况返回成功或者失败响应。如果UPDATE 中携带了SDP 请求,在2XX 响应中必须包含SDP 应答。
.E.3.3 处理UPDATE 响应对于2XX 响应,UAS 需要检查其中的SDP 是否修改,并对相应的会话参数做出调整。对于非2XX 响应,UAS 应该保证会话状态与发起UPDATE 之前相同。
.E.3.4 典型呼叫流程

Caller Callee | | | (1) INVITE with offer 1 | |-------------------------------------------->| | (2) 180 with answer 1 | |<---------------------------------------------| | (3) PRACK | |--------------------------------------------->| | (4) 200 PRACK | |<---------------------------------------------| | (5) UPDATE with offer 2 | |--------------------------------------------->| | (6) 200 UPDATE with answer 2 | |<----------------------------------------------| | (7) UPDATE with offer 3 | |<-----------------------------------------------| | (8) 200 UPDATE with answer 3 | |----------------------------------------------->| | (9) 200 INVITE | |<-----------------------------------------------| | (10) ACK | |----------------------------------------------->| | |
Figure 1: UPDATE Call Flow
E.4 PSTN/ISDN 基本和补充业务的支持传统PSTN 类业务:基本点对点通信ISDN 类补充业务:
号码显示类
前转类业务

转移类业务呼叫等待呼叫保持呼叫代答三方通话会议电话
162
附录 I (标准性附录) SIP INFO
I.1 简介 SIP 协议定义了用在SIP 控制的会议的建立和拆除阶段的会议控制信息。
另外, SIP 重新INVITE(re-INVITE )能够用于在一个会一种改变会议的特性。这通常是与会议相关的媒体流量的属性或者更新SIP 会议地计时器。然而,没有通用的目标机制来在会话过程中沿着SIP 信令通路承载会话控制信息。
INFO 消息的目的是沿着SIP 信令通路携带应用层消息。
INFO 方法并不是用来改变SIP 呼叫的状态,或会议 SIP 的初始化状态参数。它仅是用于发送通常与会议有关的应用层的可选信息。
会议中的信号信息穿过会议后的SIP 信令通路建立是必要的。这个通路是SIP 的re-INVITEs, BYEs 和其它与一个独立会话联系的SIP 请求所采用的。他允许SIP 代理服务器接收并潜在地对会议中的信号信息起作用。
此文档通过定义新的INFO 方法提供了SIP 的一个扩展。INFO 方法将被用于沿着会议信号通路传送呼叫中信号信息。
. I.1.1 用法举例
以下是一些INFO 消息地可能应用:

.-在PSTN 网关之间传送呼叫中 PSTN 信令消息
.-传送SIP 会议中生成的 DTMF 数字。
.-传送无线信号强度信息以支持无线移动应用。
.-传送计算平衡信息.

.- 在会议的参加者之间传送影像或其它的非流信息这些只是可能的应用;本文档并不指定这些应用,也不一定必须介绍它们。也可以想象还有INFO 方法的其它电话和非电话的应用。
.I.2 INFO 方法 INFO 方法被用于沿着呼叫的信令通路进行会议中信令消息间的通讯。 INFO 方法并不是用于改变SIP 呼叫的状态,也不是用于改变被SIP 初始化地会议状态。

然而,它提供增加的选项信息可以进一步加强用SIP 的应用程序功能。
INFO 方法的信令通路是呼叫建立之后建立的信令通路。这可以是呼叫方和被呼叫方用户代理之间的直接信令,也可以包括是牵涉到呼叫建立和自己增加到初始INVITE 信息记录路由头部的SIP 代理服务器的信令通路。
会议中信息能够在INFO 信息头部或作为一个消息体的一部分来进行通讯。消息体和/或消息头部的定义被用来传送会议中信息在本文档讨论范围之外。没有与INFO 相关的特别语法语义。语义是从定义给INFO 用的头部或协议体那里继承来的。
I.2.1 INFO 方法的头域支持
表1 和表2 给【1】中的表3 和表4 增加了一列。请参考【1】中的第6 节对表中内容的描述。请注意在附录里定义的规则和【1】中表3 和表4 的e-e 列同样应用了在INFO 请求和回应INFO 请求中的头部的应用。
.I.2.2 INFO 请求方法的响应如果服务器收到一个INFO 请求,他必须发出一个最后的回应。

如果INFO 请求被现有的呼叫成功的接收到,UAS 必须发送一个 200 OK 没有消息体的回应给一个INFO 请求。在此之外,不需要其他的操作。
头部Header 地方Where 信息 INFO
接收Accept
接收-编码Accept-Encoding
接收-语言Accept-Language
允许Allow
允许Allow
认可Authorization
呼叫号Call-ID
连接Contact
连接Contact
连接Contact
连接Contact
连接Contact
连接-编码Content-Encoding
内容-长度Content-Length
内容-类型Content-Type
CSeq
数据Date
加密Encryption
期满Expires
From
隐藏Hide
最大-向前流Max-Forwards
组织Organization

R o R o R o 200
405 o R o gc m R o
1xx - 2xx 3xx 485 e o e o e *
gc m g o g o g o
gc m R o R o g o
表 1 头域的概括, A-0 包括消息体的INFO 消息是在本文档的讨论范围之内。本文档消息体的定义将同样需要SIP 中的那些消息体中的定义。如果INFO 请求与任何现存的呼叫 leg 不匹配,那么一个 481 呼叫 Leg/Transaction 不存在消息必须在一个UAS 中被发送。
如果一个服务器收到一个他能理解消息体的INFO 请求,但是它又对与INFO 过程有关的消息体规则没有一点了解,那么这个消息体可能被翻译并显示给用户。这个INFO 被一个200 OK 说回应了。
如果INFO 请求包括一个服务器那时不能理解的消息体,在INFO 相关的消息体的进程规则缺乏时,服务器必须回应一个 415 不支持的媒体类型消息。
头部地方INFO 信息
优先权 R o
Proxy 验证 407 o

YD ××××—××××
Proxy 验证 R o
Proxy-需求 R o
请求 R o
重试-之后 R -
重试-之后 404,480,486 o
重试-之后 503 o
重试-之后 600,603 o
回应-关键字 R o
记录-路由 R o
记录-路由 2xx o
路由 R o
服务器 r o
主体 R o
时间戳 g o
To 到 gc(1) m
不支持的 420 o
用户代理 g o
Via gc(2) m
告警 r o
WWW-验证 401 o

表 2 头域的概括 P-Z
那些在SIP 呼叫状态中或被SIP 初始化后的会议中完成一个改变的消息体不能被放在一个INFO 消息中发送。其它请求失败(4xx), 服务器失败(5xx) 和全局失败 (6xx)回应将被送给INFO 请求。
.I.2.3 消息体的内容INFO 请求将包含一个消息体。.
.I.2.4 SIP 用户代理的行为
.除非被申明,INFO 请求的协议规则控制了标记(tags )的用法。路由和记录-路由重传和可靠性, CSeq 自增和消息格式遵从【1】中定义给BYE 请求。一个INFO 请求将被取消。如果,一个最终的回应没有被送给INFO 并且行为如同该请求从未被接收,那么, 一个 UAS 接收一个给INFO 请求的取消(CANCEL )将用一个“487 请求已取消”回应给INFO 。然而, INFO 消息决不许改变SIP 呼叫的状态,或SIP 初始化的会议。
.I.2.5 SIP 代理和重定向服务器的的行
.I.2.5.1 代理服务器
.除非被申明,在一个服务器上的INFO 的协议规定与那些在【1】中说明的BYE 请求的协议规定相一致。
.I.2.5.2 分支代理服务器
.除非被申明,在一个服务器上的INFO 的协议规定与那些在【1】中说明的BYE 请求的协议规定相一致。
.I.2.5.3 重定向服务器
.除非被申明,在一个服务器上的INFO 的协议规定与那些在【1】中说明的BYE 请求的协议规定相一致。
.I.3 INFO 消息体 INFO 消息的目的是在SIP 用户代理间传送会议中的信息。这一信息尽管能够在INFO 信息头中传送,它一般地将被放在消息体中传送。对于消息体的定义或其它任何为INFO 方法产生的新头部在本文档讨论范围之外。期望能够产生以定义这些实体为目标的独立文档。
.另外, INFO 方法并不定义确保按顺序传送的附加机制。当 CSeq 头部将在传送新的INFO 消息消息时自增,这就不能被用来决定INFO 信息的顺序,这是由于一个事实,即在用户代理发送有 re-INVITES 或其它SIP 消息时在INFO 消息 CSeq 的计数中将会引起鸿沟。
.I.4 利用 INFO 扩展的指导方针以下是在定义利用INFO 方法的SIP 扩展时必须考虑的方面。 -被INFO 消息传送的消息体的大小必须要考虑。由于消息将可能在UDP 上传送并且可能
.重组一个大的消息,消息体应该保持较小。
. -有一种可能是INFO 消息能被一个SIP 代理服务器创建。完成这一INFO 消息中的信息的创建过程需要被考虑。
. -当定义被INFO 消息传送的消息体时,多部分消息体的应用将会很有用。
. -用INFO 消息的扩展不允许依靠INFO 消息做那些影响SIP 呼叫的状态或相关会议的状态的事。
. -本文档定义的INFO 扩展不依赖于请求或代理请求头部的应用。用INFO 消息的扩展名可能需要应用这些机制。然而,如果有可能请求或代理请求的应用最好能避免,以便在SIP 实体间可以互操作。
.I.5 安全性考虑如果, 消息体的内容是私有的,那么端到端的消息体的加密能够阻止未授权的进入去访问它的内容。

没有其它的安全方法说明给INFO 方法.在SIP 说明中所说明的安全需要同样用于INFO 方法。
会话初始协议技术规范
第二部分基本的会话初始协议

Technical Specification for Session Initiation Protocol Part 2 SIP
(征求意见稿)
编制说明
2003 年7 月14 日
.1.任务来源
.本标准由信息产业部科学技术司下达, 立项文号:xxxx, 项目编号:xxxx, 主要起草单位:信息产业部电信传输研究所,参加单位:华为技术有限公司、深圳中兴通讯股份有限公司、BISC 公司,标准主要起草人:xxx 等。
.2. 编制过程
.本标准为RFC3261 的翻译文稿。并采纳了BISC 公司代表所提出的意见,对S/MIME 和TLS&SIPS-URI 、重写Record-Route 头字段值、无状态代理服务器和无状态UAS 的基本行为等内容暂不作要求。经过以上修改最终形成本标准的征求意见稿。
.3. 编制依据及参考资料
.本标准是主要参考了RFC3261(2002)《SIP: 会话初始协议》、RFC3262(2002 )《SIP 协议临时应答的可靠性》、RFC3263(2002) 《会话初始协议:定位服务器》、RFC2279 和RFC2822 等标准编制而成的。
.4. 标准内容
.本标准规定了会话初始协议的技术要求,包括SIP 消息、用户代理基本行为、请求取消、查询能力、对话、会话发起过程、会话更改过程、代理服务器行为、SIP 事务层、传输、普通消息成分、头字段、响应代码、HTTP 鉴权使用、S/MIME 、SIP 协议的扩展BNF 、安全、IANA 考虑等要求。
2. 5. 对标准发布的建议本标准属于推荐性标准。




------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容
  • VoIP的配置选择

    前面,我们已经围绕Vo I P 讨论了一些问题。现在,让我们讨论几种Vo I P 的配置和拓扑...

  • SIP协议介绍

    介绍 通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP协...

  • IP电话协议H.323协议 MGCP协议 SIP协议比较

    随着IP电话应用的普及,建立终端设备和网关的可扩展网络已成为业界面临的一大技术挑战...