SIP复习.docx
《SIP复习.docx》由会员分享，可在线阅读，更多相关《SIP复习.docx（20页珍藏版）》请在冰点文库上搜索。
SIP复习
一．如何判断消息是不是重发的
17.1.3客户端事务匹配应答
当客户端事务的通讯层收到一个应答，他必须决定是否由客户端事务来处理这个应答，这样17.1.1和17.1.2才能够正确执行。
在Via头域的最上边的branch参数就是用来做这个的。
一个应答和一个客户端事务匹配的话，就有两个条件：
1、如果应答Via最上边的branch参数和创建这个客户端事务的请求的Via最上边的branch参数相同。
2、如果Cseq头域的方法参数和创建事务的请求的方法相同。
这是因为CANCEL方法的事务和源请求的事务不同，但是却有相同的branch参数所决定的。
如果一个请求是广播发送的，他可能从不同的服务器上得到不同的应答。
这些应答的最上边的Via都有相同的branch参数，但是在Totag中是不同的。
当收到了第一个应答，基于上边的规则，将会判定是这个客户端事务的应答，其他的应答将会视同为重发。
这并不是错误的情况；多点传送SIP只是提供了一个根本的”寻找最接近的单点”服务的方法，这样就限定了只需要处理一个单个应答。
17.2.3为服务端事务匹配请求。
当服务端从网络上收到一个请求以后，他必须和现有的事务进行判定
当请求中的Via头域有branch参数
1、请求中的最上的Via头域的branch参数和创建本事务的请求的最上的Via头域的branch参数一样，并且：
2、请求的最上的Via头域的sent－by参数和创建本事务的请求的最上的Via头域的send-by参数一样，并且：
3、请求的方法和创建本事务的方法一样。
这有一个例外，就是ACK,ACK对应的创建本事务的请求方法是INVITE。
这个匹配规则用于INVITE和非INVITE事务。
send-by参数被用于匹配过程，这是因为有可能存在无意/恶意的相同的不同客户端传来的branch参数。
如果最上的Via头域的branch参数不存在，那么就用下列步骤进行判定。
如果是INVITE请求，并且这个INVITE请求的Request-URI,Totag,Fromtag,Call-ID,Cseq,和最上的Via头域都和创建事务的INVITE请求的这些字段匹配，那么这个INVITE请求就是匹配这个事务的INVITE请求。
在这个情况下，INVITE就是创建这个事务的INVITE请求的一个重发。
ACK请求在匹配创建事务的INVITE请求的Request-URI,Fromtag,Call-ID,Cseq序列号（非方法字段），最上的Via头域，并且Totag和服务端事务发出的应答的Totag相同，这个ACK就是这个事务的ACK。
当这些头域比较完成，那么这个匹配也就完成了。
一个匹配INVITE请求事务的ACK请求，如果这个INVITE请求已经被前一个ACK请求所匹配，那么这个ACK请求就是上一个ACK请求的重发。
Via头域必须包含一个branch参数。
这个参数用于区分请求创建的事务。
这个参数客户端和服务器都会使用。
除了CANCEL和给非2xx应答的ACK以外，branch参数对UA发出的所有的请求来说，在时间和空间上必须唯一。
CANCEL请求的branch参数必须和他所取消的请求的branch参数一致。
在17.1.1.3节中讲述了给非2xxx（non－2xx）应答的ACK必须和其对应的的INVITE请求有相同的branchID。
利用branchID参数的唯一性来作为事务的ID（transactionID）。
根据本标准产生的branchID必须用”z9h64bK”开头。
这7个字母是一个乱数cookie（定义成为7位的是为了保证旧版本的RFC2543实现不会产生这样的值），这样服务器收到请求之后，可以很方便的知道这个branchID是否由本规范所产生的（就是说，全局唯一的）。
在这样的要求下，精确的branchID的格式必须事先有实现的定义。
SIP中的扩展BNF：
本协议中所有机制都在以文本形式和RFC2234中定义的扩展Backus-Naur形式语法进行描述。
会话：
参与者构成的集合，在这里的含义是在参与者之间的数据的交换
SIP是一个轻形的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。
SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话
SIP在建立和维持终止多媒体会话协议上，支持5个方面：
用户定位：
检查终端用户的位置，用于通讯。
用户有效性：
检查用户参与会话的意愿程度。
用户能力：
检查媒体和媒体的参数。
建立会话：
”ringing”,建立会话参数在呼叫方和被叫方。
会话管理：
包括发送和终止会话，修改会话参数，激活服务等等。
如何建立会话：
当UAC希望初始化一个会话，它首先构造一个INVITE请求。
这个INVITE请求一个服务器来建立一个会话。
这个请求可能会由proxy层层转发，最后到达一个或者多个可能能够处理这个邀请的UAS。
这些UAS需要看看是否用户接收这个邀请。
然后UAS可以接收这个请求（也就是会话建立了），通过发送2xx应答。
如果邀请被拒绝，根据拒绝的原因，3xx，4xx，5xx或者6xx应答将会发送。
在发送终结应答之前，UAS可以发送一些临时应答（1xx）应答给UAC，以便UAC能够掌握建立会话的进度。
当收到了一个或者多个临时应答，UAC可能收到一个或者多个2xx应答或者一个非2xx终结应答。
由于在INVITE终结应答之前，可能有不少时间，在INVITE事务的可靠性机制和其他的请求不同（比如OPTIONS）。
当UAC收到了终结应答，UAC需要给每一个INVITE的终结应答，发送一个ACK请求。
对于在300到699的终结应答，ACK是在transaction层处理的，并且遵循一系列规则（17节）。
对于2xx应答，ACK是由UAC处理核心产生的。
INVITE的一个2xx应答会建立一个会话，同时也建立了一个基于发送INVITE请求的UA和产生2xx应答的UA之间的对话。
因此，当从多个远程UA收到了多个2xx应答（可能由于INVITE的分支），每一个2xx建立一个不同的对话（dialog）。
所有这些对话都是同一个呼叫的组成部分。
本节介绍了INVITE请求建立会话的详细过程。
支持INVITE的UA也一定同时支持ACK,CANCEL和BYE。
UAC—INVITE—proxy—可能能够处理的UAS
如果用户接受这个请求则通过发送2xx应答，UAS接受并建立会话，
如果拒绝则根据原因发3xx，4xx，5xx或者6xx应答，
在发终结应答前，UAS可以发临时应答1XX给UAC以便UAC能掌握建立会话的进度。
会话作用：
为什么要三次握手：
三次握手可以避免请求和相应出现不同步的部分。
三次握手可以保证没有空连接的资源浪费。
第二次握手干什么用的?
确认收到了最终相应。
SIP分层结构：
最低层是语法和编码层，他的编码使用增强的BNF形式语法来规定。
第二层是传输层。
它定义了一个客户端如何发送请求和接收应答，以及一个服务器如何接收请求和发送应答。
所有的SIP要素都包含一个传输层。
第三层是事务层。
事务是SIP的基本组成部分。
一个事务是客户发送的一个请求事务发送到一个服务器事务，连同服务器事务的所有的该请求的应答发送回客户端事务。
事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。
任何一个用户代理客户端（useragentclientUAC）完成的事情都是由一组事务构成的。
用户代理包含一个事务层，来实现有状态的代理服务器。
无状态的代理服务器并不包含事务层。
事务层包含一个客户元素（可以认为是一个客户事务）和一个服务器元素（可以认为是一个服务器事务），他们都可以用一个有限状态机来处理特定的请求。
对话：
定义：
两个用户代理（UA）之间的持续一段时间的点对点的SIP关系。
作用：
对话（Dialog）使得用户代理之间的消息顺序传递和两个用户代理之间的请求正确路由更加容易。
建立一些状态，方便后续请求。
如何路由更容易：
o=alice28908445262890844526INIP4
会话发起者，会话ID，版本号（Origin）
c=INIP4
联系地址（ConnectionData）
媒体描述（MediaDescriptions）可选
m=audio49170RTP/AVP0897
a=recvonly会话属性（Attributes）可选
a=rtpmap:
8PCMA/8000
a=rtpmap:
97iLBC/8000
对话外：
收到101-199以外的临时应答，
对话内：
事务：
一个成功的INVITE请求（13节）既会创建一个基于两个用户之间的对话，也会基于请求/应答模式（offer－answer）创建一个会话
如何更改已建立对话：
一个多媒体会话是一个由多媒体发送方和接受方组成得集合，并且包括在发送方和接受方之间得数据流。
一个多媒体会议是一个典型得多媒体会
话。
会话协商SIP消息：
INVITE,ACK,UPDATE,PRACK,101-199/2XX
消息体携带会话描述符SDP,Content-Type是application/sdp
INVITE消息的四种形式：
Init-INVITE
reINVITE
HOLD
UNHOLD
INVITE请求用于发起一个会话。
用户通过向服务器发送INVITE请求来发起一个会话，该请求通过网络中的服务器设备转发，最终到达另一个用户
REINVITE用于保持一个会话（keepalive）
UPDATE
与REINVITE类似，用来修改会话属性。
不过REINVITE只能针对已经建立的会话，而UPDATE能够在会话建立之前对相关属性进行修改。
通常用于更新媒体资源，直观地说就是修改SDP的内容。
REINVITE与UPDATE比较
①REINVITE只能在会话建立之后发出，而UPDATE在会话建立前后都能使用；
②REINVITE是INVITE请求，所以有ACK；
③REINVITE只是一种称谓，并非一种实际的请求消息，而UPDATE则是一种实际请求。
PRACK用来确认临时响应，当收到PRACK时停止临时响应的重传。
PRACK与ACK不同，PRACK是一个常规的SIP消息，有对应的响应消息（200）。
PRACKsip:
z30K74a@[fec0:
:
216:
17ff:
fe00:
27a6]:
5065SIP/2.0
Content-Length:
0
Via:
SIP/2.0/UDP[fec0:
:
20b:
dbff:
fe89:
4853]:
5061;branch=z9hG4bK00x4kl5V
f:
0422591001@ntt-east.ne.jp;user=phone>;tag=FYCsLZlTPT7Xp020M
t:
0422591002>;tag=6odSARuG5hgXJ97Ni
i:
2huhOtpjVp3GV6DrWT85r8ck6zSmbqaK
CSeq:
2PRACK
RAck:
11INVITE
Max-Forwards:
70
Route:
[fec0:
:
216:
17ff:
fe00:
27a6]:
5065;lr>
BYE：
切断已经收到最终应答的会话。
CANCEL用来取消UAC发出的一个请求。
对于UAS已经做出最终响应的请求，CANCEL是无效的，所以CANCEL主要用于取消服务器端需要很长时间才能给出响应的请求（例如INVITE），并用一个特定的错误响应（487）来应答INVITE。
代理服务器和UAC都可以产生并发送CANCEL。
有状态的代理服务器会应答收到的CANCEL，而不是简单地转发从下游实体收到的响应。
因此，CANCEL“跳”到每一个有状态的服务器时都会被应答，所以它是“逐跳”（hop-by-hop）的请求。
收到临时应答之后发出
CANCEL消息中的From、To、Call-ID、Via以及CSeq的数字部分，必须和所要切断的INVITE消息的对应部分一致；
CANCEL在收到临时应答（1xx）后才能发出；
如果已经收到最终应答，不能发CANCEL。
①CANCEL只能最终应答之前发出，而BYE在会话建立后发出；
②CANCEL和INVITE的Cseq值相同；BYE有新的Cseq值。
REFER的作用是转送
REFER请求可以是对话内，也可以是对话外
NOTIFY
通知
NOTIFY用来通知用户关于服务器当前状态的信息
Subscription-State:
active;expires=32
后面的第一个参数还可以是pending和terminated
pending:
确认中
terminated:
结束
如果是active或pending，则还可以带expires参数，用来说明订阅的有效期限
如果是terminated，则可以带reason，用来说明结束这个subscription的原因。
SUBSCRIBE
情報通知予約
SUBSCRIBE用来请求远端节点当前状态的信息以及后续更新状态的信息
一个SUBSCRIBE可以触发多个NOTIFY
SUBSCRIBE
Expires:
3600
这里的Expires是一个header，表示SUBSCRIBE的期限，可以用带有Expires:
0的SUBSCRIBE来取消订阅。
PUBLISH
服务器在给每一个成功的PUBLISH的200OK响应中，都会携带一个header:
SIP-ETag
第一个PUBLISH请求没有特殊header，但是当要更新之前的PUBLISH的状态时，PUBLISH请求中必须要携带一个header:
SIP-If-Match
OPTIONS
能力查询
可查询的内容
对方支持的请求方法
支持的内容类型
支持的扩展项
支持的编码
INFO
告知
该方法被用于沿着呼叫的信令通路进行会话中信令消息间的通信。
INFO并不用于改变SIP呼叫的状态，也不是用于改变被SIP初始化的会话状态。
他提供增加的选择信息可以进一步加强SIP的应用程序功能
INFO消息的目的是在SIP用户代理间传送会话中的信息。
100：
Trying表明下一个节点的服务器已经收到请求，并且正在对这一呼请求进行处理
该应答和其他临时应答一样，使UAC停止重发INVITE请求。
与其他临时应答不同的是，该响应不会被有状态服务器转送。
183：
SessionProgress，用来提示对话的进度信息。
180：
Ringing收到INVITE请求的UA需要通知用户有新的呼请求18x应答可以通过Viaheader沿INVITE的相同路由回到呼叫方。
4xx响应：
客户端错误，表示请求消息中包含语法错误或不能被服务器执行。
客户机需修改请求（比如增加合适的认证信息），然后重发请求。
400：
BadRequest,表示请求由于语法错误而不能被理解。
401:
Unauthorized,表示请求消息需要用户鉴权。
其应答由UAS和注册服务器发起。
407：
ProxyAuthenticationRequired
类似于401，不同的是该响应表示它指定的客户端必须首先向代理服务器鉴权自己。
这个返回码用于应用程序访问通讯网关（比如电话网关），而很少用于被叫方要求认证。
403：
Forbidden
表示服务器能理解用户请求，但是拒绝执行请求消息
404：
NotFound
表示服务器发现用户不在Request-URI头字段所指定的域中。
如果Request-URI头字段所指定的域与请求的接收方所能处理的域不一致时，也应该发送该响应。
405：
MethodNotAllowed
表示在Request-URI指定的地址上，请求的方法能够被理解但并不允许使用。
该响应中必须包括一个Allow头字段来列举指定地址上所允许的方法。
408：
RequestTimeout
当一个请求在规定的时间内没有收到响应，服务器会返408，比如无法确定用户位置
413：
RequestEntityTooLarge
表示请求的消息体（SDP）超出服务器能够处理的范围，服务器拒绝处理该请求。
414：
Request-URITooLong
表示Request-URI过长，超出服务器能够处理的范围，服务器拒绝处理该请求。
420：
BadExtension
表示服务器不理解Proxy-Require或Require头字段中协议的扩展规定。
服务器必须在420的Unsupported字段中包含一个不支持的扩展的列表。
422：
SessionInternalTooSmall
表示请求的Session-Expires时间小于服务器指定的Session-Expires时间，服务器拒绝处理该请求。
500：
Serverinternalerror[服务器内部错误]
表示服务器遇到意外的情况而使它不能执行该请求。
客户端可以显示这种特定的出错情况，并且可以在几秒钟后重发该请求。
503：
Serviceunavailable[服务无效]
表示由于服务器过载或正在维护而导致服务器暂时不能处理该请求。
服务器可以在Retry-After头字段中指明何时可重发该请求。
513：
Messagetoolarge[消息过大]
表示消息体的长度超过了服务器的处理能力限制，服务器不能处理该请求。
603：
Decline[丢弃]
表示与被叫已经成功连接，但被叫用户明确表示不能参与此呼叫。
只有当终端知道没有其他任何终端设备能够响应这个呼叫时才能给出这个应答。
该响应的Retry-After头字段可以指定多久后可以重新呼叫。
该应答表示请求成功。
应答的内容由请求本身决定。
同样是消息过长的应答，413与513的区别
同样是认证的应答，401与407的区别
401中，两次REGISTER有什么区别？
407中，两次INVITE有什么区别？
1xx：
临时应答
2xx：
成功应答 200,202
3xx：
重定向
4xx：
客户端错误480,481,482,483,486,487,491
5xx：
服务器错误500,503,513
6xx：
全局错误603
200:
该应答表示请求成功。
应答的内容由请求本身决定。
2xx：
请求是成功的
Ø202（Accepted）：
对REFER的成功应答。
480（TemporarilyUnavailable）
[暂时不可用]
表示请求成功到达被叫方的终端系统，但是被叫目前不可用。
如果服务器知道了Request-URI的用户但目前没有其有效位置时返回该状态码。
Retry-After:
5
Reason-Phrase:
提示详细原因
481（Call/TransactionDoesNotExist）
[呼叫/事务不存在]
表示UAS收到请求，但是没有和现存的对话或者事务匹配。
482LoopDetected
服务器检测到了一个循环
483TooManyHops
服务器接收到了一个请求包含的Max-Forwards
头域是0
486（BusyHere）[正忙]
表示已经成功和被呼叫端连接，但是被叫目前不能在该终端系统执行呼叫。
487（RequestTerminated）[请求终止]
表示请求被CANCEL或者BYE请求终止。
491（RequestPending）[请求挂起]
在同一个对话中，UAS接收到的请求有一个依赖的请求正在处理。
服务器返回491。
①UAS在发送第一个INVITE的终结应答之前，收到第二个INVITE请求时，做出的应答。
②怎样检测请求是否循环？
如何控制？
主要的三种转送方式
无条件转送
无应答转送
话中时转送
事务：
一个SIP事务是在客户端和服务端的事件，包括了从第一个由客户端发送到服务端的请求，到最后一个（非1xx）服务端向客户端发出的终结应答。
如果请求是一个INVITE请求，并且终结应答是一个非2xx的应答，那么事务还包括一个ACK给服务器做应答。
给INVITE请求的2xx应答的ACK回应，是一个独立的事务。
事务会在什么情况下由谁来开始：
1.当TU希望初始化一个新的事务，它创建一个客户端事务把一个SIP请求交给它传送。
然后客户端事务开始执行它自己的状态机。
合乎规格的应答会从客户端事务传送给TU。
2.服务端事务是当请求到达的时候由TU创建的，事务的处理也是主要围绕着对应请求的（也就是说并非全部都是和对应请求相关）。
3.其中又以请求是否INVITE而决定的是否INVIE的客户端事务或者服务端事务
•
对话：
一个对话是持续一段时间的两个UA之间的对等的SIP关系。
对话（Dialog）使得用户代理之间的消息顺序传递和两个用户代理之间的请求正确路由更加容易。
对话（Dialog）可以认为是对SIP消息解释的上下文关系。
一个对话在参与对话的UA中都有一个dialogID作为标记，这个ID由Call-ID，和对话的状态：
一个本地tag和远程tag组成。
一个对话包含一些特定的状态用于以后的对话中的消息传送。
这个状态包含：
dialogID
本地序列号（用来排序UA到对方的请求的序列）
远程序列号（用来排序请求从远端到本UA）
本地URI
远端URI
remotetarget
一个布尔类型的标记”secure”
路由集合（一组有序的URI）。
创建对话：
对话是由对一组特定请求的没有失败的应答来创建的。
一个对话可以处于”early”状态，这是由于当这个对话收到了临时应答而创建，并且当收到了2xx终结应答的时候转换到”confirmed”状态。
对于其他应答，或者没有应答，”early”对话将会终结。
•UAS行为概要
–前提：
当UAS响应一个请求给出一个应答，并且这个应答会建立一个对话。
•UAS必须拷贝所有的请求中的Record-Route头域到应答中去
•UAS必须增加一个Contact头域给应答
•UAS接着创建这个对话的状态
–设置secure标志
–设置路由集
–设置远程序列号
–设置本地序列号
–设置dialogID中的呼叫标志
–设置远程URI
•UAC行为概要
–前提：
当一个UAC发出一个请求，这个请求能够建立一个对话
•它必须在Contact头域中提供一个基于全局的SIP或者SIPSURI
–前提2：
当一个UAC接收到应答，并且这个应答能够建立对话
•构造这个对话的状态
–设置secure标志
–设置路由集
–设置远程序列号（空）
–设置本地序列号
–设置dialogID中的呼叫标志
–设置远程URI
对话中的请求：
•当两个UA之间的对话建立以后，他们都可以在对话中初始化一个新的事务。
如果UA发送请求，将遵循UAC的事务规则。
U
升级会员 