SIP协议中的一些基本概念

这篇主要看下SIP协议中的一些 基本概念，以下内容主要来自RFC 3261。

首先了解下UA、UAC、UAS。

UA即user agent，可以分为user agent client（UAC）和user agent server(UAS)。UAC是一个逻辑实体，会创建新request并使用client transaction state machinery发送request。UAC仅在该transaction的持续时间内起作用。换句话说，如果某个软件发起request，它会在该transaction期间充当UAC。如果稍后收到request，就会转换为UAS 来处理该transaction，UAS会对SIP request产生response，例如可以接受相应、拒绝或重定向请求。同样UAS只在该transaction的持续时间内起作用。

简单的说，UAC是产生和发出SIP request的UA，而UAS就是对request产生response的UA。所以在transaction期间一个UA既是UAC，也是UAS。

dialog是两个UA之间持续一段时间的点对点 SIP关系。 dialog通过SIP消息建立，例如对 INVITE request的 2xx response。dialog 由Call-ID、local tag和remote tag来区分，也就是 Call-ID 、from-tag和to-tag就可以确定一个dialog ID，用于区分不同的dialog 。在不同的协议中，dialog有不同的叫法，例如在RFC 2543中dialog又被称为leg。

在特定methods(例如INVITE) 收到non-failure response(例如 200 ok) 时，dialog就被创建，但是 只有带有“To” tag的 2xx 和 101-199 响应（请求为 INVITE）才会建立dialog。 而对于之前的non-final response，这个期间的dialog 叫做early dialog，而什么是final response，在介绍transaction时会提到。

举例来说，dialog ID 由 Call-ID 、from-tag、和to-tag确定， UAC在生成INVITE时，会生成Call-ID及From tag，在收到183?SESSION PROGRESS时就收到了UAS 的To tag，此时就可以确定 dialog ID，根据这段描述，此时对应的是early dialog，而在收到final response即200 ok时，才算是final dialog。

如果dialog外部的request生成non-2xx的final response，那基于该request 的provisional resposne创建的任何early dialog都会终止，而 BYE方法会终止session以及与其关联的dialog。

由此可见dialog的的生命周期是由 INVITE到BYE的 200 OK为止。

这里就先看下Final response和 Provisional response的定义。

Final response指 终止SIP transaction的response，而 所有2xx、3xx、4xx、5xx 和 6xx response均为final responses。

Provisional response: 服务器用来指示进度的响应，但不会终止 SIP transaction。 1xx response就是 Provisional response ，其他回复被视为final resposne。

SIP transaction发生在client和server之间，包含从 client 发送到server的第一个请求到从server发送到 client 的final（non-1xx）response的所有消息。 例如MO发出INVTE到收到200 OK for INVITE，就建立了一个transaction。

如果请求是INVITE并且final response是non-2xx，则transaction还包括对响应的ACK。

对 INVITE request的2xx response的ACK则是一个单独的事务，也就是2xx的ACK 对应的就是另一个transaction。

SIP 是基于transaction的协议： 具体来说，一个SIP transaction由单个request和对该reuqest的任何response组成，其中包括零个或多个 Provisional responses 以及一个或多个 Final responses 。

在request是INVITE的transaction（即INVITE transaction）的情况下，仅当final response不是2xx response时，transaction才会包含 ACK。 如果response是2xx，则ACK 就不会被当作transaction的一部分，也就是2xx的ACK 就会当作另一个transaction。

上述讲2xx的ACK 作为另外 transaction的原因就是体现了INVITE的地位的重要性， 也体现了将INVITE的所有200 (OK) response传递给UAC的重要性， 为了将所有200 ok全部传送给UAC，UAS会单独负责重传200 ok，然后UAC也要单独用ACK确认200 ok。 由于这时的ACK仅由UAC重传，因此ACK就被当作UAC的transaction。

值得注意的是，CSeq header field是用作识别和排序transaction的一种方式， 它由序列号和方法组成，这里的方法必须与request的method匹配。

对于dialog之外的non-REGISTER请求，序列号值是任意的，但是 序列号值必须可表示为32位无符号整数，并且必须小于2**31。

简单总结下， 对于INVITE transaction， final response是non-2xx，则transaction还包括对响应的ACK；如果是2xx response，则其ACK 就是一个单独的transaction。

通过CSeq header 就可以区分transaction，具体是结合序列号和request的method确定，序列号和method相同的就是同一个transaction。

例如一通call，首先会有INVITE transaction，那CSeq可以是CSeq:?1 INVITE；期间会有其他non-invite transaction ，例如SIP PRACK，此时CSeq: 2?PRACK；之后又有SIP UPFATE发送，那CSeq: 3 UPDATE；最后有SIP BYE，那CSeq: 4 BYE。? ?而transaction的终结就是通过收到 final（non-1xx）response来确定，例如 MO发出INVTE到收到200 OK for INVITE，此时就对应一个transaction。

进一步的可以看出一个dialog会包含多个transaction。

根据 SDP spec：“多媒体session是一组多媒体senders和receivers以及从senders流向receivers的数据流。 多媒体会议是多媒体session的一个示例。”SDP 定义的一个session可以包含一个或多个 RTP sessions。

根据定义，被叫者可以被不同的呼叫多次邀请到同一session。 如果使用SDP，则session由SDP用户名、sesssion ID、网络类型、地址类型和origin field中的address element来定义。由此可以看出Session是和SDP 多媒体 flow有关系的。

terminating 一个session的过程：其实session的状态和dialog的状态是息息相关的， 当使用 INVITE 发起session时，来自不同 UAS 的每个 1xx 或 2xx 响应都会创建一个dialog，如果该response完成SDP offer 和SDP answer协商过程，那就会创建一个session。所以说， a session是与导致其创建的dialog相关联的。

如果intial INVITE 生成了non-2xx final response，那就则会终止这期间创建的所有session(有的话)和所有dialog(有的话)。 通过完成transaction，non-2xx final resposne 还可以阻止由于INVITE而进一步创建的session。

BYE可以用于终止特定session或尝试的session。 在这种情况下，特定session是与dialog另一方对等UA之间的session。 当在dialog中收到 BYE 时，与该dialog关联的任何session都应该终止，这样也就决定了 UA必须在dialog 内发送BYE，不然也没什么意义。 这里还有一点需要注意，MO的UA可以为已确认 dialog或 early dialog发送 BYE，MT的UA只能在已确认dialog中发送BYE，但不能在early dialog中发送BYE。

而MT UA发送BYE也是有条件限制的，MT的UA只能在收到2xx 响应的ACK 或服务器transaction超时，才能 在已确认dialog上发送BYE。

在dialog和session中，对 INVITE的non-2xx final response ，CANCEL也会起到一定作用。 CANCEL会尝试强制对INVITE做出non-2xx response(特别是 487)。

因此，如果 UAC 希望完全放弃其呼叫尝试，那就可以发送 CANCEL。 如果UAC发送了CANCEL后，却收到了 INVITE request的 2xx final response ，就意味着UAS在CANCEL 正在进行时接受了invitation，那 UAC可以继续由 2xx response建立的session，也可以用 BYE 终止sessions。

session的详细信息，例如媒体类型、codec或采样率等会使用SDP进行描述。? SDP消息由SIP消息承载，其方式类似于由电子邮件消息承载的文档附件或者由HTTP消息承载的网页，SDP在通话建立session参数 协商时用到，相信大家也都比较熟悉。

这里贴出RFC 3261中的一张图，由此整理的dialog ，transaction和session之间的关系如上图示。