IMS学习笔记
IMS网络结构 SIP协议
SIP头域字段的含义和作用
Request-URI、To、Contact区别 SIP头域中参数
Route字段中的lr参数指示的实现的路由机制，lr表示losing route松散路由机制。 Record-route为了给该请求消息之后的请求消息留后路。而在一个请求消息的传输过程中，Proxy也可能（纯粹自愿，如果它希望还能接收到本次会话的后续请求消息的话）会添加一个Record-Route头域，这样当消息到达被叫后里面就有会有0个或若干个
Record-Route头域。被叫会将这些Record-Route头域并入路由集，并并入自己的路由集，随后被叫在发送请求消息时就会使用该路由集构造一系列Route头域，以便对消息进行路由。然后，被叫会像上面对待Via头域一样，将Record-Route头域全部原样copy到响应消息中返回给主叫。主叫收到响应消息后也会将这些Record-Route头域并入路由集，只是它会将其反序。该会话中的后续请求消息的Route头域就会通过路由集构造。
【注意】Record-Route头域不用来路由，而只是起到传递信息的作用。Record-Route头域不是路由集的唯一来源，路由集还可以通过手工配置等方式得到。
Via被服务器插入request中，用来检查路由环的，并且可以使response根据via找到返回的路。它不会对未来的request 或者是response造成影响。
Route记录路由节点。
SIP编码
头域编码：头域+冒号+头域值，头域名是不分大小写的，冒号后、头域值前可以有若干个空格，但是最好是一个空格。头域值是区分大小写的。
举例Accept: application/sdp;level=1, application/x-private, text/html
IMS入口点发送机制
静态机制
静态机制是指在IMS终端上配置SBC的IP地址或域名。这种方式的缺点是无法很好地
支持用户的漫游。当用户漫游到其他省的IMS网络时，由于用户无法获知漫游地的SBC地址和域名信息，因此无法对SBC的配置进行修改，信令和媒体仍然会从归属省的SBC接入，这样会造成媒体面的迂回，占用网络资源，降低承载的传输服务质量。
动态机制
3GPP定义了两种动态入口点的发现机制： 1）IP-CAN IMS信令承载建立方式
该方式是针对移动终端通过PS域接入IMS的场景。GGSN在建立IMS信令承载的PDP context时，在PDP相关信令中携带SBC的地址给终端，该方式对PS域的GGSN有特殊要求，需要对GGSN进行升级改造。 2）DHCP+DNS查询方式
通过IP接入网中的DHCP转发代理服务器在UE和DHCP服务器之间转发消息，获得SBC的地址，如果返回的是SBC的域名，则通过DNS查询得到SBC的地址。该方式要求对IP接入网的DHCP服务器进行改造。
CM-IMS采用的SBC发现机制
CM-IMS采用终端静态配置网元标识和DNS解析的方式： 终端中配置SBC/P-CSCF的统一标识，如sip:abc.chinamobile.com。接入网通过DHCP和公网DNS将SBC/P-CSCF标识映射为用户拜访地的SBC/P-CSCF的IP地址，提供给用户。
SIP事件通告机制
Subscription-State：指示创建订阅的状态。 Active订阅已被接受且授权成功。
Pending：订阅已经收到，但还没有足够的信息决定接受和拒绝此次订阅。 Terminated:订阅未激活或是创建的订阅关系已经终止。
所谓事件通告机制是指网络中的一些实体可以订阅网络中某些资源或呼叫的状态信息，当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通报当前资源状态的变化情况。
为了实现这一机制，因特网工程任务组(IETF)的SIP工作组对基本的会话启动协议进行了扩充，提出了基于会话启动协议的事件通告机制规范：RFC 3265[1]。 在规范中定义了两个扩展方法：订阅(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于发起订阅请求，NOTIFY方法用于通告当前资源状态。
会话启动协议事件通告机制涉及以下几个概念： (1)订阅者
订阅者负责接收NOTIFY消息的会话启动协议用户代理(SIP UA)[2]。这些NOTIFY消息中包含订阅者订阅的资源信息。订阅者典型的动作是向通告者发送SUBSCRIBE消息以请求创建一次订阅关系。 (2)通告者
通告者负责产生NOTIFY请求的SIP UA。通告者在NOTIFY消息中向订阅者回馈当前资源的状态。通告者典型的动作是接收SUBSCRIBE消息并创建相应的订阅关系。 (3)订阅
所谓订阅就是一组与某个对话相关联的应用状态的集合。订阅关系既存在于订阅者中，又存在于通告者中。 (4)事件包
事件包是通告者向订阅者发送的一组资源的状态信息。RFC 3265中给出了抽象的事件包模板定义，对应具体业务可定义相应的事件包类型，例如：在席事件包、对话事件包等，这些事件包可使用不同的语法并具有各自的语义。这种框架赋予会话启动协议事件通告机制极大的生命力和灵活性，有助于快速提供新的业务。
事件通告机制的流程
典型的会话启动协议事件通告机制流程如图所示。
SUBSCRIBE方法和会话启动协议基本规范[3-4]中定义的邀请(INVITE)方法都可以创建一个对话。当订阅者想得到网络中某一资源的状态时，便向负责这一资源的会话启动协议实体发起SUBSCRIBE请求。SUBSCRIBE消息中的请求统一资源标识符(Request-URI)就是所要请求的资源的统一资源标识符(URI)，这一URI同时还为会话启动协议代理服务器路由请求提供线索。SUBSCRIBE请求中必须包含一个扩展的Event头部，其中注明要订阅的事件类型，即事件包标记，如，dialog(用于代答业务)、refer(用于呼叫转交)等。还可包含扩展的Allowed-Event头部，指示本节点能够支持的事件包类型。如果在一个对话中有多次订阅，在Event头部还要增设标识参数id予以区分。
对于订阅者来说，它总是在一定的时间段内对它感兴趣的某一资源进行观察，因此，SUBSCRIBE消息中应包含expires头部，这一头部表明订阅者期望的有效订阅时长。为了延长某一订阅的时间，订阅者可以在有效期内再次发送SUBSCRIBE消息来刷新这一订阅。具体某次订阅的有效时长，最终是由对SUBSCRIBE请求的2XX响应中的expires头部值或NOTIFY
消息中的Subscription-State头部的expires参数决定的。expires头部值等于0的SUBSCRIBE请求表示撤消订阅。如果订阅关系能够建立，SUBSCRIBE消息将会触发通告资源状态的NOTIFY消息立即回送。订阅者想要获得的资源状态信息封装在后继通告消息NOTIFY的消息体中，为了能够正确地解释这部分信息，订阅者应该向通告者指明自己支持的消息体格式，因此，在SUBSCRIBE消息中应携带Accept头部，比如：Accept: application/dialog-info+xml，这表明订阅者支持用可扩展标识语言(XML)描述的对话事件包，实际上就是一种通用Internet邮件扩展(MIME)格式消息体。如果SUBSCRIBE消息中没有携带Accept头部，则通告者根据SUBSCRIBE消息中Event头部指明的事件包标记选择默认的格式传送资源状态信息。 SUBSCRIBE请求通过2XX响应确认。不同的2XX响应具有不同的语义： (1)200 OK表示订阅已被接受且用户已被授权订阅请求的资源。
(2)202 Accepted(接受)是事件通知机制扩展的响应码，表示订阅请求已被理解，但是否授权给订阅者未确定。
2XX响应中必须包含expires头部，这个值指明通告者确定的此次订阅的有效时长，且必须满足：expires 200 OK <= expires SUBSCRIBE，即禁止通告者延长订阅时长。如果返回非2XX响应，则表示订阅失败，将没有后继的NOTIFY消息。
通告者收到SUBSCRIBE请求时，首先判定是否理解消息中的Event头部，如果不理解，则通告者返回扩展的“489 Bad Event”(错误事件)响应。通告者还会检查消息中的expires头部，如果其值满足：(0 < expires SUBSCRIBE < 1 hour) && ( 0 < expires SUBSCRIBE < Min 通告者- config)，其中，Min通告者- config为通告者最小配置订阅时长，则通告者向订阅者返回“423 Interval too small”(时间间隔太短)响应，表示提出的订阅时长太短。此外，通告者还应根据本地策略对提出SUBSCRIBE请求的用户进行鉴权。
与订阅相关的信息由NOTIFY消息传送。通告者在成功创建订阅关系后，必须立即发送NOTIFY消息，向订阅者通告当前订阅资源的状态，如图中的3所示。通告者使用SUBSCRIBE消息中Accept头部明确允许的或者Event头部隐含指明的消息体格式将资源的状态信息或指向该资源状态的URI封装在消息中。消息也可包含扩展的Allowed-Events头部，指示本节点能够支持的事件包类型。NOTIFY消息中必须包含扩展的Subscription-State头部，指示创建的订阅的状态。共有3种订阅状态，分别是： (1)active：订阅已被接受且授权成功。
(2)pending：SUBSCRIBE请求已收到，但还没有足够的信息决定接受或拒绝此次订阅。 (3)terminated：订阅未激活，或创建的订阅关系终止。
对应active状态或pending状态，该头部还带有expires参数指示此次订阅的有效时长。对应terminated状态，该头部应包含reason参数指示订阅被终止的原因，或者包含Retry-After参数，指示订阅者过一段时间后重新发起订阅请求。 订阅者收到通告者NOTIFY请求后，将进行匹配检查。
如果找到相应的匹配，且NOTIFY消息中的Subscription-State头部指示的订阅状态是active或pending，订阅者创建新的订阅或对话，并对NOTIFY请求回送200 OK响应，如图中的4所示。如果匹配失败，则发送“481 Subscription does not exist”(订阅不存在)响应。 在订阅有效期内，如果资源状态发生变化，则通告者使用NOTIFY请求及时将变化信息
通告订阅者，如图中的5和6所示。
扩展的SUBSCRIBE方法和基本的INVITE方法都可以创建对话。在某一对话中，SUBSCRIBE请求将创建和该对话关联的订阅，而该对话有可能是由INVITE建立起来的。因此，如果订阅终止，且当前无其他应用状态(如由INVITE请求建立起来的应用状态)和该对话关联，则该对话结束。如果仍有订阅和该对话关联，虽然其他的应用状态已结束，但该对话并没有结束。换句话说，由INVITE创建的对话并不会因为收到或发送了再见请求而结束，因为仍有订阅关系和此对话相关联。与此类似，当多个订阅和同一对话关联时，必须当与此对话相关联的所有订阅都结束时，该对话才结束。这一概念非常类似于程序设计里对文件描述符的引用，其中文件描述符相当于对话，对文件描述符引用的进程相当于建立的订阅关系。
SUBSCRIBE请求可以触发通告者对其资源状态的立即回送，因此，订阅者可以利用这一特性实现对资源状态的轮询。当订阅处于激活状态时，订阅者在SUBSCRIBE请求的expires头部写入当前剩下的订阅有效时长的秒数，这样，能够立即触发通告者产生NOTIFY消息，将当前资源的状态通告给订阅者。需要指出的是，这种对资源的轮询会导致网络、通告者和订阅者负荷的增加。在如移动通信这样的特定应用中，订阅者一般是数据处理能力较慢、需要额外供电的移动终端设备，随着事件通告频度的增加和通告事件包的增大，将消耗很多宝贵的带宽资源，造成网络拥塞和订阅者的过载。因此，订阅者需要对通告者的状态通告频率作出限制[6]。另外，订阅者还可以在SUBSCRIBE消息中指定一些事件包的过滤规则，使得通告者能够根据这一过滤规则产生通告事件，而不是任何状态发生变化时都发起通告。 一般说来，订阅者使用SUBSCRIBE请求建立一次订阅，称为显式订阅创建，与此相对应的还有一种隐式的订阅创建，即订阅者不是通过SUBSCRIBE请求来创建订阅。而是通过转交(REFER)方法[3]，一种由RFC 3515定义的用于实现呼叫转交等业务的方法。REFER请求隐式地在被转交用户处创建订阅，所要观察的资源是转交请求的状态。
自动回叫业务示例
如前所述，会话启动协议的事件通告机制非常灵活，针对不同的应用可以定义不同的事件包，事件包被封装在NOTIFY消息中通告资源状态，这一机制为实现各种功能强大的业务提供了坚实的基础。现给出使用这一机制实现的自动回叫业务流程。 (1)业务描述
用户A呼叫用户B，而B正在会话，A希望B在通话结束后能够立刻通知他，这样A就能够及时地和B建立会话了。这里，A使用事件通告机制来获取B的会话状态。 (2)业务流程
如图3所示，用户A向用户B发起呼叫请求INVITE(F1)，此时B正在通话，因此返回“486 Busy Here”(现在正忙)响应(F2)。A希望B能够在通话结束后通知他，于是A向B发起SUBSCRIBE请求(F4)，其Event头部指明事件类型为dialog，即订阅B正在进行中的对话状态；Accept头部指明A支持使用XML语言封装的dialog事件包。SUBSCRIBE的消息片断如下：
SUBSCRIBE sip: userB@foo.bar SIP/2.0 …… Event: dialog