|
如果你对Sip协议中Call, Dialog, Transaction和Message之间的关系感觉到迷惑,那么,那么我可以告诉你,你并不孤单,因为大多数初学者对于这些名词之间的关系都会感到疑惑.
Messages(消息) 消息是在服务器和客户端之间交换的独立文本,
有两种类型的消息,分别是请求(Requests)和响应(Responses).
Transaction(事务)
事务发生于客户端和服务器端之间,包含从客户端发出请求给服务器,到服务器响应给客户端的最终消息(non-1xx message)之间的所有消息. 如果请求是一个"Invite"消息,并且最终的响应是一个non-2xx消息,那么该事务包含一个"Ack"响应消息.如果服务器的响应是一个2xx消息,那么,随后的ACK是一个单独的事务.
A sip transaction consists of a single request and any responses to that request, which
includes zero or more provisional responses and one or more final responses.The branch parameter value in the VIA header is used to identify the transaction created by that request
Dialog(对话)对话是两个UAs(user
agent) 之间持续一段时间的端到端(peer-to-peer)的SIP 关系. 一个对话由一个Call-ID, 一个local tag 和 一个remote tag来标识.对话过去也叫做 "call leg".dialog的建立是收到UAS的响应（To tag）时开始建立的。收到180响应时建立dialog叫做早期对话（early dialog）,收到2XX的应答开始才是真正的dialog建立。
A
dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time, as a call-leg.It is identified at each UA with a dialog ID, which consists of a Call-ID, From tag and To tag. We can call a dialog is established when three
values are all generated
Session(会话)
session
是媒体交换之后才建立的。具体而言就是通过offer/answer方式交换sdp的媒体。 session的建立可以使INVITE-200 也可以是200-ACK。这要看媒体的交换发生的时间。 具体来说，INVITE 中的消息体用sdp语言来描述自己可处理的媒体类型，200OK中 带回UAS端可处理的媒体类型。这个时候媒体交换就算是完成了。也就是session建立起来了。
In
the SDP specification, a multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A session is defined by the SDP user name, session id, network type, address type, and address elements in the
origin field.
A session can have multiple RTP sessions corresponding to the UDP ports define in the line of the SDP.
Call(呼叫) ：一个呼叫是由一个会议中被同一个发起者邀请加入的所有成员组成的。一个
SIP 呼叫用全局唯一呼叫标识（CALL_ID）来识别。因此，如果一个用户被不同的人邀请参加同一个多点会议，每个邀请都有一个唯一的呼叫。
注:
Dialog和Session都翻译成了会话,但两者显然不同.
下面的示意图清晰的显示了它们之间的关系
(RINGING
是 1xx 响应, OK是 2xx 响应)
caller呼叫callee的号码来建立一系列的对话(Dialogs),这些对话组成了一个呼叫(Call).
1.对话和事务处于信令层，而会话处于媒体传输层。SIP使用SDP来通知传输层（RTP）来创建、增加、移除和修改会话。
2.一般来说，在会议应用中SIP可以通过请求来让另一方加入已有会话中。在这种情况下，新的对话会被创建。 3.对话是end-point对end-point的关系，即真实的通信双方，
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
呼叫（call）： 呼叫是一个非正式的术语，用来表示一个多媒体会话，用Call-ID来标识；不论两方通话还是在多方通话中，在每个UA中是使用同一个Call-ID； 事务(transaction)： 请求（UAC）+最终响应（相邻的UAS），SIP基于事务。所谓相邻就是说transaction存在于相邻的SIP实体，而不是存在于两个UA之间。CSeq标识。一个事务中包含一个请求消息、0个或多个临时响应消息、1个或多个最终响应消息（2xx~6xx）。SIP是事务性的协议。事务的区分通过Via字段栈顶的Branch的值来确定，这是由于对于请求消息每经过一个有事务状态的Proxy的时候，该Proxy需要为这个事务创建一个服务器端事务和一个客户端事务，并且将自己的URI添加到Via的栈顶，并生成一个Global ID做为Branch的值，以此值来表示一个与之相对应的事务。SIP在事务层面定义了状态机和定时器来实现重传。
下图是一个回复200 OK的成功的INVITE事务：是不是INVITE事务区别在于 UAC需要为每个INVITE最终请求（2xx～6xx）生成ACK响应，而其他的请求消息（INFO,OPTION,etc）则不必如此。因为INVITE的地位比较重要， 所以需要这样一个三次握手的机制来保证会话的双方都能够确保事务的完整性，这一点和TCP连接建立的三次握手比较像。
注意在上图这两个UA中，每一个代理服务器都将自己的地址加入返回的ACK的Via头域中，而非成功的transaction则不会加入，见RFC 3261 (p.24)。CSeq头域的值必须与INVITE相同，并且CSeq的方法必须是ACK。中间响应消息 1xx 的使用则是为了节省网络开销设计的，一旦 UC 收到任何一个中间响应消息，则 UC 必须停止消息重发定时器，不再从发这个请求消息，反之则直到收到最终响应消息或重发定时器超时。一旦客户端UAC的事务在Calling状态收到任何中间响应消息1xx，事务则自动切换到Processing状态，停止请求消息的重发。并且需要将中间响应消息传送给TU事务用户。在呼叫业务中，TU以及上层应用可以根据中间响应消息在用户界面上提示用户。一旦事务切换到Processing状态，任何其他中间响应消息也都要传送给TU。
而非INVITE事务则如下：
当UAC发出非INVITE请求时，它就会在事务管理子层上开启定时器F（TCP）或者是E（UDP），确保超时的时候进行重传。这适用于除了 ACK请求外的其他非INVITE请求。每次超时重传时E的时间都被翻倍，直到最大的4秒。而F超时时，UAC就会认为是Timeout，这个事务将被删除。
对话(dialog/leg）： 代表着两个SIP UA之间持续一段时间的端到端的联系（如：一段通话）。也就说仅仅存在于端到端的信令关系。当一个UAS发出对于INVITE（或者REFER）的非失败最终响应<=>200OK（BYE），则Dialog建立，同时这也是session的开始。UA和SIP代理服务器之间不会有对话。在SIP中呼叫中包含一个或多个Dialog（这仅仅存在于多方通话中）。Dialog终结于任意一端发出 BYE。Early Dialog可以通过UAC发出的CANCEL进行终结，更确切的说，所有早期对话在接收到非2XX最终响应时就被终结了。 Call-ID-value、To、From进行标识。Forking时体现明显。
在这个Forking的例子中，这个用户注册了三个设备，在用户被呼叫时，INVITE的Contact头域就被转换为三个INVITE发往三个设备。后边的q指的是优先级，q越小，优先级越高。其中的SIP注册服务器相当于一个Forking代理，尽管这个实体接收到两个ACK，但是除了这些ACK外，它与主叫方的信令交互都是属于一个transaction的，而与被叫方则分别建立了Transaction。另外，被叫方收到的两个ACK由分别建立了Transaction。注意Device3返回了488这样的非成功响应，SIP注册服务器（Forking代理服务器）没有将该响应发回主叫方，这是SIP代理一个重要的特征，SIP代理还能自行发出Request:CANCEL消息。
UAS对话层接收到一个新的对话请求INVITE消息后，在建立会话的响应消息2xx中，将请求消息里面的所有Route-Record字段拷贝到2xx消息中，并且UAS的对话层必须添加一个Contact字段使得对话中后续的响应（INVITE在2xx响应的情况下也包括ACK消息）、请求消息可以直接和本UA联系。当UAC收到UAS的INVITE的2xx响应消息后，如果2xx中不包含任何Route-Record字段的，则UAC可以选择直接发送ACK到Contact中地址&端口。
会话(session)： 多方用户的媒体关系，在对话的控制下建立。
下图是Early dialog、Session、Dialog、Transaction等的在一个UA-UA的呼叫中的体现：
在这个例子中，通过INVITE事务而成功建立起来的dialog必须有一个ACK进行回应，这是第二个transaction的开始，尽管ACK并没有回复，但是由于新的 branch-value被填入，所以这个ACK代表了一个新的Transaction的开始。注意，此时 transaction number (CSeq) 并没有根据INVITE而增加--也就是说若收到的最终响应不是2XX（是3XX--6XX），则该transaction中包含ACK，若最终响应是2XX，则ACK属于一个新的transaction(此处存疑，国外有资料将其视为一个新的transaction，但是RFC3261中的意思却是ACK不属于INVITE Transaction，也不创建新的Transaction，但会重新计算Transaction参数--branchID)。早期对话是UAS以一个1XX响应作为回应时建立的。这样做的好处是在UAC可能在早期对话中发出诸如UPDATE这样的SIP请求。 |
|
|
