乱翻 之 RFC3262文档格式.docx
《乱翻 之 RFC3262文档格式.docx》由会员分享,可在线阅读,更多相关《乱翻 之 RFC3262文档格式.docx(11页珍藏版)》请在冰豆网上搜索。
PRACK包含一个RAck头字段,表明了它所确认的临时响应的序列号。
该确认不是累积
的,本说明建议一次只发一个明显临时响应,以控制拥塞。
3UAS行为
当初始INVITE包含一个支持(Supported)头字段带有可选标签100rel。
UAS可能发
送任何非100临时响应来可靠地回应INVITE,本说明不允许除对应INVITE之外的临时
可靠响应,扩展定义了新的方法来建立对话可能会使用这种机制。
当初始INVITE包换一个必须(Required)头字段带有可选标签100rel。
如果UAS不愿
意接受,它必须使用420(错误的扩展)携带不支持的带有可选标签100Rel的头字段
拒绝初始请求。
UAS不允许对100临时响应进行可靠传输。
只有101到199可以可靠传输。
如果请求既
没有Supported或Require头字段来表明这个特性,UAS不允许可靠地发送临时响应
100Trying响应只能逐跳传输。
因为这个原因,我们描述地端到端地可靠机制不能使
用。
?
可以作为代理的成员(element)也能发送可靠的临时响应。
这种情况下,它在这个
事务中作为UAS。
但是,它不能对带有一个标签的To头字段的任何请求做可靠临时响
应。
这意味着一个代理不能对对话中发送的请求生成可靠临时响应。
不同于UAS,当
代理成员(element)收到一个不匹配可靠临时响应的PRACK,该PRACK必须被代理。
为什么UAS可能想发送一个可靠的临时响应,有如下几个理由:
第一,如果INVITE事务
可能需要时间来产生最终响应。
如3261中13.3.1.1章节谈论的,UAS将需要发送定期的
临时响应来向代理请求一个事务的“扩展”。
需求是一个代理会每隔3分钟收到请求,但
是因为丢包地可能性UAS需要更频繁地发送请求(建议间隔一分钟)。
作为一个更有效
率的解决方案UAS可以可靠地发送响应。
这样UAS应该每隔2.5分钟发送一个临时响应。
在扩展事务中使用可靠临时响应是建议性地。
剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个
临时响应被可靠的传输。
临时响应被可靠传输是有UAScore根据32618.2.6章节的程序来构造的。
另外,它必须
包含Require头字段带有可选标签100rel和Rseq头字段。
UAS可能发送任何非100临时响应来可靠地回应INVITE,事务中第一个可靠临时响应的头
字段的值必须在1和2**31-1之间。
建议从这个范围内均一地选择。
Rseq编号空间用于
一个单独地事务。
这个意味着对于不同请求的临时响应可能使用相同的Rseq值。
可靠临时响应可能包含一个包体。
会话描述的用途在第五章介绍。
可靠临时响应被定期地传输到事务层。
间隔从T1妙开始,然后每隔双倍地时间重传
一次(T1在3261中17章节定义)。
一旦传输到服务层事务,它将被加到一个内部未确认
可靠临时响应列表。
事务层将转发每个从UAScore中传过来的重传。
这个和2xx响应的重传不同,2xx的间隔时间是T2秒。
这是因为ACK的重传是由一个2xx接
收来触发的,但PRACK的重传独立于1xx的接收。
当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。
PRACK就像对话中
的其他请求一样,UAScore根据3261的8.2,12.2.2章节程序来处理。
一个匹配的
PRACK定义类似为在同一会话里的响应,它的方法,Cseq-num和响应号在Rack头字段匹配,
分别的对应于可靠临时响应的Cseq的方法,序列号和可靠临时响应中的Rseq中的序列号。
如果UAcore收到一个PRACK请求不匹配任何未确认可靠临时响应,UAS必须给PRACK返回一
个481响应。
如果PRACK匹配一个未确认可靠临时响应,那么它必须回复一个2xx响应。
UAS
可以通过这点来取人临时响应已被有序接收。
它应当停止可靠临时响应的重传,并且必须
将它从未确认临时响应列表中去掉。
如果一个可靠临时响应重传了64×
T1秒仍未接收到匹配的PRACK,UAS应当用5xx响应拒绝初
始请求。
如PRACK包含一个会话描述,它将如5章节中所描述的进行处理。
如果PRACk包含其他类型的
消息体,这个消息体会按ACK中的消息体的方式进行处理。
在请求的第一个可靠临时响应被确认后,UAS可能会发送额外的可靠临时响应。
UAS必须在
在第一个被确认后才能发送第二个可靠临时响应。
第一个可靠临时响应会有特别的处理因
为它负责传递初始序列号。
如果额外的可靠在第一个被确认之前发送,UAS不能确定他们
是否被顺序收到。
接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。
Rseq序
号不允许循环。
因为初始第一个选择小于2**31-1,但是最大地值是2**32-1,每个请
求可以有超过2**31个临时可靠响应,这个值绰绰有余。
UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应,除非
最终响应是2xx并且所有的未确认可靠临时响应都包含一个会话描述。
在这种情况下,它
必须在所有临时响应都被确认后才能发送最终响应。
如果UAS在所有可靠响应仍未确认前
发送最终响应,那么它不应当继续重传未确认可靠临时响应,但是它必须准备处理针对于
这些响应的PRACK请求。
UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临
时响应(与未确认响应的的重传相对立)。
4.UAC行为
当UAC建立了一个新的请求,它可以坚持对该请求进行临时响应的可靠传送。
为了实现该能
力,它在请求中插入了一个带100rel可选标签的Require头字段。
带100rel可选标签的
Require头字段只能在INVITE请求中使用,尽管SIP的扩展可能允许其他的请求方法使用它。
Headerfield
where
PRACK
___________________________________
Accept
R
o
2xx
-
415
c
Accept-Encoding
Accept-Language
Alert-Info
180
Allow
r
405
m
Authentication-Info
Authorization
Call-ID
c
Call-Info
Contact
1xx
3xx
485
Content-Disposition
Content-Encoding
Content-Language
Content-Length
t
Content-Type
*
CSeq
Date
Error-Info
300-699
Expires
From
In-Reply-To
Max-Forwards
Min-Expires
423
MIME-Version
Organization
Table1:
Summaryofheaderfields,A--O
__________________________________________
Priority
Proxy-Authenticate
407
401
Proxy-Authorization
Proxy-Require
Record-Route
2xx,18x
Reply-To
Require
Retry-After
404,413,480,486
500,503
600,603
Route
Server
Subject
Supported
Timestamp
To
Unsupported
420
User-Agent
Via
Warning
WWW-Authenticate
Table2:
Summaryofheaderfields,P--Z
如果UAC不一定要求使用可靠临时响应,但只是表明如果UAS需要发送那么它会支持,
带100rel可选标签的Supported头字段必须出现在请求当中。
UAC应该在所有的INVITE
请求中加入该字段。
如果收到了一个初始请求的临时响应,并且响应包含带100rel可选标签的Require
头字段,那么响应会被可靠地传送。
如果响应是一个100(trying)(非101~199)
,那么这个可选标签必须忽略,如下的过程将不会用到。
如果对话还没建立那么临时响应必须建立一个对话。
假设响应被可靠地传输,UAC必须建立一个PRACK的新请求。
这个请求与之前的临时
响应是处于同一对话中的。
(事实上,这个临时响应可能已经建立了这个对话)。
PRACK请求可能包含消息体,根据他们的类型和部署来说明该消息体。
请注意PRACK就如对话中其他的非INVITE请求。
特殊的是,一个UAC在它收到已确认
的临时响应的重传是不会重传PRACK请求,尽管这样做不会产生一个协议错误。
一旦收到一个可靠的临时响应,对应该响应的重传必须遗弃。
当它的会话ID,Cseq
和Rseq和原始的响应匹配时我们认为这个响应是个重传。
UAC必须包含一个序列号来
表明最近接收到的针对初始请求的顺序可靠临时响应。
这个序列号将一直维持直到
接收到初始请求的最终响应。
它的值必须用对初始请求的第一个可靠临时响应中Rseq
头字段值来进行初始化。
处理对于同一个初始请求的后续可靠临时响应遵循以上的规则,区别在于:
可靠
临时响应保证是顺序的。
结果是,如果UAC接收到同一另外一个可靠临时响应,并且
它的Rseq值不比前一个序列号的值高(大),那么该响应不能够用PRACK来确认。
目
前的实现是可能是抛弃这个响应,或者缓存该响应以期收到丢失的响应。
UAC在最终响应后可能确认接收到的可靠临时响应也可能丢弃。
5.Offer/Answer模型和PRACK
3261描述了在哪些消息中可以出现请求和应答。
基于那些模型,本扩展提供了offer和
answer模型的新交互方式。
如果INVITE包含一个offer,那么UAS可能在一个可靠临时响应中产生一个answer(假设
UAC支持这些方法)。
那么导致在完成这个电话之前就已经建立一个会话。
类似的,如果
一个可靠临时响应是第一个发回给UAC的可靠消息,并且INVITE不带有offer,那么offer
必须在那个可靠临时响应中出现。
如果UAC接收到一个可靠临时响应带了offer(发生在当UAC发送了一个不带offer的INVITE
情况下,这导致第一个可靠临时响应将包含offer),它必须在PRACK中生成一个answer。
如果UAC接收到了一个带有answer的可靠临时响应,它将可能在PRACK中生成一个附加的
offer。
如果UAS收到带offer的PRACK,它必须在PRACK对应的2xx中携带answer。
一旦收到或者发出一个answer,UA应当根据offer和answer中的参数来建立会话,就算初始
的INVITE还没有被响应。
如果UAS将一个会话描述放在了任何一个当INVITE接收时还没有被确认的可靠临时响应中时,
UAS必须延迟发送2xx直到该临时响应被确认。
否则,1xx响应的可靠性没有办法得到保证,
在offer和answer交互的正常操作中需要可靠性保证。
所有支持这个扩展的用户代理必须支持3261中13.2章节所描述的offer/answer交互的所有可能
的规则。
如基于INVITE和PRACK作为请求,2xx和可靠的1XX作为非失败的可靠响应。
6.PRACK方法的定义
本说明定义了一个新的SIP方法,PRACK。
语意如上表述。
表1,2是从3261的表2和3中针对这个
新方法扩展出来的。
7.头字段定义
本说明定义了两个新的头字段,RAck和RSeq。
表3是从3261的表2和3中针对这俩个新头字段
扩展出来的。
7.1RSeq
Rseq头字段是用于临时响应的可靠传输。
它包含一个单一数值:
1到2**32-1.关于它的用途请
参照第三章。
例:
RSeq:
988789
Headerfield
proxyACKBYECANINVOPTREGPRA
______________________________________________________
RAck
-
RSeq
o
Table3:
RAckandRSeqHeaderFields
7.2RAck
RAck头字段在PRACK请求中发送以支持临时响应的可靠性。
它包含两个数字和
一个方法标签。
第一个数字是从被确认的临时响应中的RSeq头字段中获得的。
第二个数字和方法是从被确认的响应中的CSeq中获取的。
RAck头字段中的方法
名是区分大小写的。
例:
RAck:
7766561INVITE
8IANA考虑事项
本说明注册了一个单一的可选标签100rel。
100rel
描述:
本可选标签是为了保证临时响应的可靠传输。
当它出现在Supported头字段
的时候,表明UA可以发送或接收可靠临时响应,当出现在请求的Require头字段时
,表明UAS必须可靠地发送所有地临时响应。
当出现在一个可靠临时响应的Require
头字段时,表明该响应将被可靠地传输。
9安全考虑
攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。
因为这些响应可以传达
重要的信息,PRACK消息应该可以像其他的请求那样接收认证。
认证过程定义参见
3261。
10.收集的BNF
RACKm
=
%x50.52.41.43.4B;
PRACKincaps
Method
INVITEm/ACKm/OPTIONSm/BYEm
/CANCELm/REGISTERm/PRACKm
/extension-method
"
RAck"
HCOLONresponse-numLWSCSeq-numLWSMethod
response-num
1*DIGIT
CSeq-num
RSeq"
HCOLONresponse-num