IMS学习笔记Word文档下载推荐.docx

IMS学习笔记Word文档下载推荐.docx

《IMS学习笔记Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《IMS学习笔记Word文档下载推荐.docx（12页珍藏版）》请在冰豆网上搜索。

2）DHCP+DNS查询方式

通过IP接入网中的DHCP转发代理服务器在UE和DHCP服务器之间转发消息，获得SBC的地址，如果返回的是SBC的域名，则通过DNS查询得到SBC的地址。

该方式要求对IP接入网的DHCP服务器进行改造。

CM-IMS采用的SBC发现机制

CM-IMS采用终端静态配置网元标识和DNS解析的方式：

终端中配置SBC/P-CSCF的统一标识，如sip:

。

接入网通过DHCP和公网DNS将SBC/P-CSCF标识映射为用户拜访地的SBC/P-CSCF的IP地址，提供给用户。

SIP事件通告机制

Subscription-State：

指示创建订阅的状态。

Active订阅已被接受且授权成功。

Pending：

订阅已经收到，但还没有足够的信息决定接受和拒绝此次订阅。

Terminated:

订阅未激活或是创建的订阅关系已经终止。

　　所谓事件通告机制是指网络中的一些实体可以订阅网络中某些资源或呼叫的状态信息，当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通报当前资源状态的变化情况。

　　为了实现这一机制，因特网工程任务组（IETF）的SIP工作组对基本的会话启动协议进行了扩充，提出了基于会话启动协议的事件通告机制规范：

RFC3265[1]。

在规范中定义了两个扩展方法：

订阅（SUBSCRIBE）和通告（NOTIFY）。

SUBSCRIBE方法用于发起订阅请求，NOTIFY方法用于通告当前资源状态。

　　会话启动协议事件通告机制涉及以下几个概念：

（1）订阅者

　　订阅者负责接收NOTIFY消息的会话启动协议用户代理（SIPUA）[2]。

这些NOTIFY消息中包含订阅者订阅的资源信息。

订阅者典型的动作是向通告者发送SUBSCRIBE消息以请求创建一次订阅关系。

（2）通告者

　　通告者负责产生NOTIFY请求的SIPUA。

通告者在NOTIFY消息中向订阅者回馈当前资源的状态。

通告者典型的动作是接收SUBSCRIBE消息并创建相应的订阅关系。

　　（3）订阅

　　所谓订阅就是一组与某个对话相关联的应用状态的集合。

订阅关系既存在于订阅者中，又存在于通告者中。

　　（4）事件包

事件包是通告者向订阅者发送的一组资源的状态信息。

RFC3265中给出了抽象的事件包模板定义，对应具体业务可定义相应的事件包类型，例如：

在席事件包、对话事件包等，这些事件包可使用不同的语法并具有各自的语义。

这种框架赋予会话启动协议事件通告机制极大的生命力和灵活性，有助于快速提供新的业务。

事件通告机制的流程

典型的会话启动协议事件通告机制流程如图所示。

　　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）200OK表示订阅已被接受且用户已被授权订阅请求的资源。

（2）202Accepted（接受）是事件通知机制扩展的响应码，表示订阅请求已被理解，但是否授权给订阅者未确定。

　　2XX响应中必须包含expires头部，这个值指明通告者确定的此次订阅的有效时长，且必须满足：

expires200OK<

=expiresSUBSCRIBE，即禁止通告者延长订阅时长。

如果返回非2XX响应，则表示订阅失败，将没有后继的NOTIFY消息。

　　通告者收到SUBSCRIBE请求时，首先判定是否理解消息中的Event头部，如果不理解，则通告者返回扩展的“489BadEvent”（错误事件）响应。

通告者还会检查消息中的expires头部，如果其值满足：

（0<

expiresSUBSCRIBE<

1hour）&

&

（0<

Min通告者-config），其中，Min通告者-config为通告者最小配置订阅时长，则通告者向订阅者返回“423Intervaltoosmall”（时间间隔太短）响应，表示提出的订阅时长太短。

此外，通告者还应根据本地策略对提出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:

userB@foo.barSIP/2.0

……

Event:

dialog

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头部为：

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字母编码表

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

E

12

M

20

U

28

c

36

k

44

s

52

60

F

13

N

21

V

29

d

37

l

45

t

53

61

G

14

O

22

W

30

e

38

m

46

u

54

62

/

H

15

P

23

X

31

f

39

n

47

v

55

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：

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="

"