此外，通告者还应根据本地策略对提出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请求回送200OK响应，如图中的4所示。
如果匹配失败，则发送“481Subscriptiondoesnotexist”（订阅不存在）响应。
在订阅有效期内，如果资源状态发生变化，则通告者使用NOTIFY请求及时将变化信息通告订阅者，如图中的5和6所示。
扩展的SUBSCRIBE方法和基本的INVITE方法都可以创建对话。
在某一对话中，SUBSCRIBE请求将创建和该对话关联的订阅，而该对话有可能是由INVITE建立起来的。
因此，如果订阅终止，且当前无其他应用状态（如由INVITE请求建立起来的应用状态）和该对话关联，则该对话结束。
如果仍有订阅和该对话关联，虽然其他的应用状态已结束，但该对话并没有结束。
换句话说，由INVITE创建的对话并不会因为收到或发送了再见请求而结束，因为仍有订阅关系和此对话相关联。
与此类似，当多个订阅和同一对话关联时，必须当与此对话相关联的所有订阅都结束时，该对话才结束。
这一概念非常类似于程序设计里对文件描述符的引用，其中文件描述符相当于对话，对文件描述符引用的进程相当于建立的订阅关系。
SUBSCRIBE请求可以触发通告者对其资源状态的立即回送，因此，订阅者可以利用这一特性实现对资源状态的轮询。
当订阅处于激活状态时，订阅者在SUBSCRIBE请求的expires头部写入当前剩下的订阅有效时长的秒数，这样，能够立即触发通告者产生NOTIFY消息，将当前资源的状态通告给订阅者。
需要指出的是，这种对资源的轮询会导致网络、通告者和订阅者负荷的增加。
在如移动通信这样的特定应用中，订阅者一般是数据处理能力较慢、需要额外供电的移动终端设备，随着事件通告频度的增加和通告事件包的增大，将消耗很多宝贵的带宽资源，造成网络拥塞和订阅者的过载。
因此，订阅者需要对通告者的状态通告频率作出限制[6]。
另外，订阅者还可以在SUBSCRIBE消息中指定一些事件包的过滤规则，使得通告者能够根据这一过滤规则产生通告事件，而不是任何状态发生变化时都发起通告。
一般说来，订阅者使用SUBSCRIBE请求建立一次订阅，称为显式订阅创建，与此相对应的还有一种隐式的订阅创建，即订阅者不是通过SUBSCRIBE请求来创建订阅。
而是通过转交（REFER）方法[3]，一种由RFC3515定义的用于实现呼叫转交等业务的方法。
REFER请求隐式地在被转交用户处创建订阅，所要观察的资源是转交请求的状态。
自动回叫业务示例
如前所述，会话启动协议的事件通告机制非常灵活，针对不同的应用可以定义不同的事件包，事件包被封装在NOTIFY消息中通告资源状态，这一机制为实现各种功能强大的业务提供了坚实的基础。
现给出使用这一机制实现的自动回叫业务流程。
（1）业务描述
用户A呼叫用户B，而B正在会话，A希望B在通话结束后能够立刻通知他，这样A就能够及时地和B建立会话了。
这里，A使用事件通告机制来获取B的会话状态。
（2）业务流程
如图3所示，用户A向用户B发起呼叫请求INVITE（F1），此时B正在通话，因此返回“486BusyHere”（现在正忙）响应（F2）。
A希望B能够在通话结束后通知他，于是A向B发起SUBSCRIBE请求（F4），其Event头部指明事件类型为dialog，即订阅B正在进行中的对话状态；Accept头部指明A支持使用XML语言封装的dialog事件包。
SUBSCRIBE的消息片断如下：
SUBSCRIBEsip:
*************SIP/2.0
……
Event:
dialog
Accept:
application/dialog-info+xml
……
B的通告者根据本地策略对A进行鉴权后授权A订阅这一资源，返回200OK（F5），并立即回送通告当前对话状态的NOTIFY消息。
当B结束通话时，A订阅的对话资源状态发生了变化，从确认状态迁移至了终结状态，B的通告者生成NOTIFY消息，向A通告当前B的对话状态（F8）。
A得到这一信息后，立即向B发起INVITE请求，与B建立新的会话。
事件通告机制的安全性考虑
（1）接纳控制
在事件通告机制中，通告者需要将资源的状态信息通告给订阅者，然而在通告的事件包中，有些信息对于用户来说是敏感的或者是隐私，因此，通告者应能够根据订阅者的身份，选择性地拒绝某些用户的订阅请求，并使用标准的会话启动协议鉴权机制[2]对用户进行鉴权。
订阅请求的最终决定权应该由用户（自然人）作出。
（2）通告者的策略安全
在某些情况下，对SUBSCRIBE请求回应200OK或4XX、6XX响应可能会导致通告者某些敏感策略信息的泄漏。
因此，在这些情况下，通告者应总是对SUBSCRIBE请求回送202Accepted响应。
后继的NOTIFY中可能并不携带真正的资源状态，但从订阅者的角度来看，这并无任何异常。
例如，在“在席”应用中，用户A向用户B发送SUBSCRIBE请求获取用户B是否在席的信息，B在席，但他拒绝了A的订阅请求，因为B并不想让A知道他正在网上。
如果B直接使用4XX或6XX响应拒绝，则会泄漏B的策略。
为此，B可对SUBSCRIBE回送202Acceptted响应，在随后的NOTIFY消息的Subscription-State头部指明订阅终结，原因为没有资源，即A想订阅的资源不存在，其Subscription-State头部为：
Subscription-State：
terminated；reason=noresource，这样既拒绝订阅请求又不会暴露通告者的策略信息。
（3）防止恶意攻击
随着事件通告机制的进一步应用，要逐步考虑应对各种Internet上惯用的恶意攻击。
比如，拒绝服务（DoS）攻击，在当前的基于会话启动协议的事件通告模型中，一个SUBSCRIBE请求将触发一个或多个通告资源状态的NOTIFY消息，通告者接收到SUBSCRIBE请求，要创建相应的状态，消耗一定的系统资源。
有恶意的订阅者会利用这一点发起过多的订阅请求，就有可能使通告者因创建过多的订阅而资源耗尽。
为了减少这种攻击的机会，通告者的实现必须包含鉴权，以过滤恶意的订阅请求。
IMS媒体协商
SDP语法语意
ApplicationSpecific（AS）
IMSSDP媒体协商
IMS可以支持包括语音和视频在内的多种多媒体类型业务，而不同接入方式的终端支持不同的媒体类型和编解码。
为保证正常会话，需要主被叫之间进行媒体协商，选择双方都支持的编码方式。
SIP协议只完成IMS会话建立基本流程，本身不支持媒体协商，需要在SIP消息中携带SDP描述来完成媒体参数的协商。
媒体协商采用offer/answer机制，媒体协商又分为一次协商和二次协商。
一次协商是指只用一组offer/answer进行SDP的协商，主叫发送INVTE消息携带SDP（offer），SDP中指定了自己支持的所有媒体和编码，被叫从主叫支持的媒体和编码当中选择一种自己支持的媒体类型和编码格式，通过SIP响应（183sessionprogress）回复给主叫（answer），因此，一次协商中，会话采用的媒体类型和编码是由被叫决定的。
二次协商则是采用两组offer/answer进行SDP协商，同样主叫发起INVITE消息（offer），其携带的SDP指定自己支持的所有媒体类型和编码格式，被叫利用183消息返回首个应答（answer），其会携带主被叫能力集的交集。
之后，主叫根据自身资源现状，选择唯一一组合适的编码方案，利用PRACK消息（offer）再次发送请求给被叫。
被叫将返回200OK应答（answer），完成二次协商。
SDP媒体二次协商
注意途中两次发送200OK的意义不同，第二个200OK没有携带SDP参数，是INVITE消息的被叫摘机应答，即被叫发送这个应答消息后可以随时摘机。
IMSprecondition资源预留
IMS系统中，建立媒体传输通道的过程属于资源预留。
假设用户附着在GPRS网络上，那么资源预留就是建立媒体PDP上下文的过程，这个过程会花费一些时间，甚至会失败。
为了保证被叫摘机之前会话双方资源预留完成，IETF提出一种保障机制--precondition。
Precondition机制的重要标志就是在主叫发送第一个INVITE消息时，添加了字段：
Require：
sec-agree,precondition，表示如果不支持该机制，则拒绝本次会话。
反之，在后续媒体协商过程中，双方每种媒体描述都会携带一组独立的precondition字段。
每组precondition字段都可以说明与本次消息相关的资源预留情况。
在二次协商原理基础上，使用precondition机制的基本流程如下所述。
主叫第一次发送INVITE消息时会首先说明会话双方没有完成任何与QoS有关的precondition，且主叫需要进行资源预留。
当被叫返回183消息时也没有在本地预留任何与Qos有关的资源，但被叫根据主叫要求会强制同意进行本地预留资源。
183中的a=conf：
qosremotesendrecv字段可以保证资源预留完成前，被叫用户不会振铃或者摘机。
当PRACK消息确认了最终要预留资源的媒体类型后，主叫已经知道被叫当前状态，且开始资源预留，这就是PRACK携带的precondition字段与INVITE中的主要区别在于。
最后，被叫在发送200（OK）时开始预留资源。
资源预留过程图
IMS短消息
IMS鉴权认证
标准的Base64字母编码表
0
A
8
I
16
Q
24
Y
32
g
40
o
48
w
56
4
1
B
9
J
17
R
25
Z
33
h
41
p
49
x
57
5
2
C
10
K
18
S
26
a
34
i
42
q
50
y
58
6
3
D
11
L
19
T
27
b
35
j
43
r
51
z
59
7
4
E
12
M
20
U
28
c
36
k
44
s
52
0
60
8
5
F
13
N
21
V
29
d
37
l
45
t
53
1
61
9
6
G
14
O
22
W
30
e
38
m
46
u
54
2
62
/
7
H
15
P
23
X
31
f
39
n
47
v
55
3
63
+
但是标准的base64编码并不适合直接放在URL里传输，因为URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式，而这些“%”号在存入数据库时还需要进行转换，因为ANSISQL中已将“%”号用作通配符。
为解决此问题，可采用用于URL的改进的Base64编码，它不仅在末尾填充“=”号，并将标准base64中的“+”和“/”分别改成了“-”和“_”。
Base64编码过程：
首先将每个字符转换成对应的ascii码值，并用二进制表示，将二进制串分成6bit一组，高位补0，组成一个字节，不够6bit也需要在高位补0。
例：
abcd对应的ascii为979899100，转换成二进制为01100001011000100110001101100100，进行6bit分组并补齐000110000001011000001001001000110001100100000000，对照base64编码表对应编码为YWJjZA。
对应解码过程是编码过程的逆过程。
鉴权参数
AUTN：
AuthenticationToken。
128bit长，由鉴权中心AuC产生，用于客户端对服务器进行认证是否有效。
通过AUTN得出MAC值，客户端与本地的计算得出的XMAC值进行比较。
AUTS：
AuthenticationToken。
112bit长，当SQN同步失败时，由客户端产生。
RAND：
随机序列，由AuC使用SQN生成。
RES：
鉴权响应，由ISIM生成。
XRES：
期待的鉴权响应。
www-Authenticate头域参数
Nonce：
由服务器生成，其组成为RAND（16bytes）、AUTN（16bytes）和特定serverdata组成，一般只有RAND和AUTN，末尾添加=结尾，采用base64编码。
Opaque：
特定的值，由UE后续的register消息返回。
对于鉴权的两种情况：
一种是MAC参数无效，此时终端应当发起新的注册请求；一种是SQN无效，此时终端应当重发register注册请求，在Authorization中携带AUTS参数，服务器端会使用AUTS和RAND参数进行重新同步，然后下发401消息。
a） WWW-Authenticate/Proxy-Authenticate头域
这个头域值包含了至少一个表明认证方式和适用realm的参数的拒绝原因。
如：
WWW-Authenticate:
Digest
realm="",
升级会员 