用户标识

10.11注册过程中与计费有关的信息

3.10节介绍了计费的概念和相关的网络实体。本节仅解释在注册过程中与计费有关的SIP消息头的内容及其处理。IMS会话的计费过程在11.7.7节中介绍。

当P-CSCF收到初始REGISTER请求时，它生成IMS计费ID(ICID),只要用户处于注册状态，该ID对于所有的IMS有关的信令就是有效的。该ICID值通过P-Charging-Vector消息头从P-CSCF传送到S-CSCF。

REGISTERsip:homel.frSIP/2.0

P-Charging-Vector:icid-value=”AyretyU0dm4-6O2IrT5tAFrbHLso=023551024”

当收到这个消息头后，S-CSCF会保存ICID,并执行11.7.7节中介绍的计费过程。P-Charging-Vector消息头在［RFC3455］中定义，该消息头的扩展和在IMS中的用法在［3GPP TS 24.229］中描述。

10.12用户标识

10.12.1概述

Tobias需要向他的归属网络进行注册才能发起对他姐姐的呼叫。在本例中,目前他使用SIP URIsip:tobias@homel.fr来进行注册。当Tobias使用与工作无关的服务时他使用这个用户标识。然而，Tobias在其法国的运营商处注册了一整套用户标识，见表10-3。

在首次注册过程中，Tobias只能明确地注册这些URI的其中之一，在我们的例子中就是sip:tobias@homel.fr。然而，IMS允许隐性地和明确地注册更多的公共用户标识：

• 在初始注册阶段，上面列出的部分标识可以被网络自动(隐性地）注册。

• 其他的标识可以保持未注册状态，直到Tobias明确地请求注册它们。

当接收到对第二个REGISTER请求的200(OK）响应时，Tobias的终端和P-CSCF都会发现Tobias的缺省公共用户标识，这是就是P-Associated-URI消息头中第一个URI。

为了发现分配给Tobias的其他公共用户标识的更多的注册状态,UE自动订阅归属网络S-CSCF所提供的注册状态事件信息。在首次注册成功后，要求UE必须立刻执行这个订阅，这是由于：

• UE需要了解关联URI的注册状态；

• 该订阅使得网络(S-CSCF）能够强制UE进行重认证(见10.13.2节）；

• 该订阅使得网络(S-CSCF）能够解除用户的注册(见10.14.3节）。

与此同时，P-CSCF也订阅了用户注册状态信息，主要是为了获知网络发起注册解除(见10.14.3节）。

10.12.2注册的公共和私有用户标识

初始REGISTER请求中所携带的标识是从ISIM中读出的,ISIM是UE的UICC卡(通用集成电路）上的应用之一。ISIM中读出的数据包括：

• 用户的私有用户标识；

• 用于注册的公共用户标识；

• 用户的SIP注册服务器的地址。

私有用户标识仅用于认证，这在10.6节中已介绍；公共用户标识就是Tobias将要首次注册的SIPURI=Tobias可以有其他多个公共用户标识，其中一些甚至可以存储在ISIM中，但是在开始只有一个可以显式注册。

如果UE中没有配备ISIM,它可以从同样存在于UICC中的USIM应用中得到用户标识和注册服务器地址。USIM应用包含了所有与用户电路交换(CS）域和分组交换(PS）域的注册和认证有关的数据，在10.12.3中会对此进行详细解释。

拥有了这些参数，UE可以填写初始REGISTER请求中的如下字段：

REGISTERsip:homel.frSIP2.0

From:<sip:tobias@home1.fr>;tag=pohja

To:<sip:tobias@homel.fr>

Authorization:Digestusername="tobiasjprivate@homel.fr",

realm="homel.fr",

nonce="",

uri=,'sip:homel.fr”，

response=""

从ISIM中读出的公共用户标识，写入To和From消息头。Authorization消息头中username字段取值为私有用户标识，而注册服务器的地址则放入请求URI中以及Authorization消息头的realm和uri字段中。

10.12.3 没有ISIM时获得标识

当Tobias注册时，其UE从UICC上运行的ISIM应用中读出SIPURI“sip:tobias@homel.fr”,该UICC是从运营商处得到并置于UE中。ISIM总是保存至少一个有效的公共用户标识。

然而，IMS服务也可以提供给UICC卡上没有ISIM应用的用户，于是也就没有有效的公共用户标识。因此，UE需要依据USIM应用内的数据来创建一个临时的公共用户标识(见3.5节），并使用这个临时标识进行注册。

由于临时公共用户标识是依据USIM中与安全相关的数据生成的，因此不允许暴露给IMS以外的任何网元。因此，它被视为“被隔离的标识(BarredIdentity来处理：也就是说，强烈建议网络拒绝除用户注册以外的情况下以任何形式使用这个标识。

在这种情况下，私有用户标识也从USIM数据中生成。其用户部分遵照IMSI(国际移动用户标识符）的形式；继之以一个宿主部分，包括IMSI中的MCC(移动国家代码）和MNC(移动网络代码）。例如，Tobias的私有用户标识可能是类似如下的内容：222330999999999@ims.mnc33.mcc222.3gppnetwork.org。

Tobias的归属网络的域名也可以从USIM中得到，看上去类似于私有用户标识的域名部分，即ims.mnc33.mcc222.3gppnetwork.org。

10.12.4  默认的公共用户标识/P-Associated-URI消息头

如果Tobias在首次注册中使用了临时公共用户标识，他将遇到这样的问题：虽然已经注册过，但是不能进行任何其他操作(例如呼叫他的姐姐或者定购服务），因为他注册中所使用的标识不能再继续使用(被隔离的标识）。他的终端需要知道另一个隐性注册的标识。

任何时候一旦用户成功地进行了认证和注册，S-CSCF于是就会对REGISTER请求发出一个200(OK）响应，在该响应中发送P-Associated-URI消息头。该消息头列出了该用户的所有SIPURI和telURL(即公共用户标识），这些都与用户关联，但并非必须注册。消息头中只有第一个列出的URI总是有效的和已注册的公共用户标识，可被UE和P-CSCF用来实施进一步操作。

对应于TobiasREGISTER请求的200(OK）响应中，其中的P-Associated-URI如下所示：

SIP/2.0 200 OK

P-Associated-URI:<sip:tobias@home1.fr>,<sip:tobi@homel.fr>,

<sip:gameMaster@homel.fr>,

<sip:+44-123-456-789@homel.fr;user=phone>,

<sip:+44-123-456-l1l@homel.fr;user=phone>

通过这些信息，Tobias可以知道至少有一个公共用户标识"sip:tobias@home1.fr”是巳经注册的。他还可以得知还可使用其他两个SIPURI和两个telURL，但他并不知道这些标识现在是否已经注册。

由于P-Associated-URI只定义为传递SIP URI,因此它用SIP URI的格式来表示所包含的与Tobias关联的两个telURL(tel:+44-123-456-789和tel:+44-123-456-111）。

10.12.5UE订阅注册状态信息

在成功进行初始注册和认证之后，Tobias的终端发送一个SUBSCRIBE请求,包含如下信息：

SUBSCRIBEsip:tobias@homel.frSIP/2.0

Via:SIP/2.0/UDP[5555::1:2:3:4]:1357;comp=sigcomp;branch=4uetb

Route:<sip:[5555::a:b:c:d]:7531;lr>

Route:<sip:orig@scscfl.homel.fr;lr>

From:"Tobias”<sip:tobias@homel.fr>;tag=sipuli

To:^Tobias11<sip:tobias@homel.fr>

P-Preferred-Identity:nTobiasH<sip:tobias@homel.fr>

Event:reg

Expires:600000

Accept:application/reginfb+xml

Contact:<sip:[5555::1:2:3:4]:1357>

Content-Length:0

与以前的例子一样，这里也没有显示SUBSCRIBE请求的所有信息，以上只列出了必须的消息头，以便理解注册状态事件订阅的实质和请求消息的路由。

该订阅仅针对名为“reg”的事件，就是注册状态事件包；在请求消息的Event消息头中指示。

请求URI指示了要订阅哪个用户的注册状态信息，因此，需要设置为Tobias已注册的公共用户标识，并在To消息头中明示。

为了标识他自己，TobiasUE将To和P-Preferred-Identity消息头设置为据他所知目前已注册的SIPURI0这可以是：

• 收到的P-Associated-URI消息头中缺省公共用户标识(见10.12.4节）。

• 在初次注册时所显式注册的公共用户标识，只要它不是一个临时的公共用户标识(见10.12.3节）。如果没有使用临时公共用户标识，那么有可能这个显式注册的公共用户标识与缺省公共用户标识相同。

11.2节介绍了P-Preferred-Identity消息头、P-Asserted-Identity消息头和To消息头之间的关系。由于SUBSCRIBE是初始请求，因此To消息头中并不包含标签，因此这个标签需要由远端(本例中即S-CSCF）来指定。

Expires消息头要设置为与初始注册中超时时间相同的值(即600000s,大约7天）。

Accept消息头指示在本次订阅中，UE只能处理“reginfb+xml”类型的信息，即XML(扩展标记语言）格式的注册状态信息。

Contact消息头设置的联系信息与注册过程中的联系信息相同：即由接入网分配的UE的IP地址(见10.2节），和由IPsecSA使用的受保护的服务器端口(见10.7节）。

最后，有必要看看Route消息头：它包含了REGISTER请求的200(OK）响应中Service-Route头中的路由集合(见10.5.8节）；其中最顶端的就是P-CSCF的地址，它用作出站代理。这使得SUBSCRIBE请求首先被传送到P-CSCF,而后直接继续转发到注册过程中指派的S-CSCF.

P-CSCF接到UE发来的SUBSCRIBE请求后，将检查P-Preferred-Identiy头中的信息集合是否是Tobias的有效的公共用户标识。如果是,它将P-Preferred-Identiy头换成P-Asserted-Identiy头。

SUBSCRIBEsip:tobias@homel.frSIP/2.0

P-Asserted-Identity:"Tobias"<sip:tobias@homel.fir>

S-CSCF在接收到SUBSCRIBE请求后，会检查P-Asserted-Identity头中的用户标识是否已经在S-CSCF上注册。随后，它会检查它是否可以向订阅者用户提供Tobias的注册状态信息(见图10-11）。由于本例中Tobias订阅的是他自己的注册状态信息，是允许的。因此，S-CSCF会立即：

图l0-11   Tobias订阅自己的注册状态信息

• 对SUBSCRIBE请求返回一个200(OK)响应，指示该订阅已经成功；

• 生成一个reginfb类型的XML文件，包含Tobias关联的URI的当前的注册状态信息；

• 通过一个NOTIFY消息将所生成的XML文件发送给订阅者(本例中即TobiasUE)O

由于200(OK)响应和NOTIFY请求几乎是同时发送的，NOTIFY请求有可能在200(OK)响应之前到达。在这种异常情况下，UE必须能够根据NOTIFY请求创建相关的订阅对话：也就是说，不能够由于事先没有收到SUBSCRIBE请求的200(OK)响应，而丢弃NOTIFY请求中的信息。

10.12.6  P-CSCF订阅注册状态信息

P-CSCF也需要订阅Tobias的注册状态信息，因此它也创建一个SUBSCRIBE请求，看上去与终端创建的请求类似。

SUBSCRIBEsip:tobias@homel.frSIP/2.0

Via:SIP/2.0/UDPpcscfl.visitedl.fi

From:<sip:pcscfl.visitedl.fi>;tag=retiisi

To:nTobiasH<sip:tobias@homel.fr>

P-Asserted-Identity:<sip:pcscfl.visitedl.fr>

Event:reg

Expires:600000

Accept:application/reginfb+xml

Contact:<sip:pcscfl.visitedl.fr>

Content-Length:0

二者主要的区别在于这次是P-CSCF要订阅Tobias的注册状态信息(见图10-12)；因此它要在From消息头和P-Asserted-Identity消息头中标识自己。由于P-CSCF是可信任的实体(见3.642节)，它直接在请求中加入P-Asserted-Identity消息头。

由于初次注册阶段，P-CSCF并没有出于自身路由的目的而保存任何路由信息，因此它不知道为用户指定了哪个S-CSCF,因此也就无法包含Route消息头。所以，它只能根据请求URI的主机部分(即“homel.fr”)来进行该请求消息的传送；可以通过DNS解析找到Tobias归属网络中一个或多个I-CSCF.的地址。然后I-CSCF查询HSS得到分配给URIsip：tobias@homel.fr的S-CSCF地址，并将请求发给S-CSCF.

图10-12  P-CSCF订阅Tobias的注册状态信息

请注意通过这个SUBSCRIBE请求也建立起一个新的对话，这次是在P-CSCF和S-CSCF之间。这个对话与UE是否订阅了同样的注册状态信息完全没有关系，因此S-CSCF要分别针对UE的订阅和P-CSCF的订阅，生成包含Tobias注册状态信息的、单独的NOTIFY请求。

10.12.7注册状态信息的元素

在收到一个新的订阅后，无论何时注册状态信息发生变化(例如注册了一个新的公共用户标识）,S-CSCF都会立刻用Tobias的注册状态信息创建一个NOTIFY消息。

本节中我们仅仅看一下Tobias的终端在订阅之后立刻收到的NOTIFY请求和注册状态信息，这些信息与P-CSCF收到的完全一样，而且基本上是同时收到的。

TobiasUE收到的NOTIFY请求中包含以下消息头(还有其他的消息头）：

NOTIFYsip:[5555::l:2:3:4]:1357;comp=sigcompSDP/2.0

Via:SIP/2.0/UDPscscfl.homel.fr;branch=nosctb

Via:SIP/2.0/UDPpcscf1.visited1.fr:7531;branch=nopctb

From:,,TobiasH<sip:tobias@homel.fr>;tag==peruna

To:HTobiasH<sip:tobias@homel.fr>;tag=sipuli

Subscription-State:active;expires=599999

Event:reg

Content-Tye:application/reginfo+xml

Contact:<sip:scscfl.homel.fr>

Content-Length:(...）

对上述NOTIFY请求需要说明的是：

•  由于这个请求是从通知者(S-CSCF）发往订阅者(Tobias的UE）的，To和From发生了改变。尽管这两个消息头的内容几乎完全相同，但是它们的标签不同。S-CSCF又增加了一个“To”标签("peruna”），但现在出现在From头中。

•  增加了Subscription-State头，指示该订阅是活跃的，并将在599999s后超时。

10.12.8 NOTIFY请求正文中的注册状态信息

NOTIFY请求消息的正文部分包含了Tobias的关联URI的注册状态信息，将在10.12.9节中详细介绍。注册状态信息是一个分级的列表，包含：

•  根元素“reginfb”，包含与一个用户关联的注册状态信息；

• "reginfo”根元素的一个或多个子元素"registration每个“registrationw子元素仅包含与一个URI(即一个公共用户标识）的信息；

• 每个“registration”子元素包括零个或多个“contact”子元素。每个"contact”子元素包含了关于地址的信息，该地址已经用于为“registration"子元素中的URI进行注册(或解除注册）。

每个registration子元素中可以包含以下属性：

• (记录的地址）属性，后面是公共用户标识的URI。

• ID属性，惟一标识了每个registration子元素，将它们相互区别开。

• registration子元素的state属性，指示相应的URI处于以下哪种状态：

■“活跃(Active）"(即已注册）；

■“已终结(Terminated）"(即已解除注册）；

■“初始化(Init）"(即处于正在注册的过程中，例如已经接到一个初始的REGISTER请求，但还没有完成认证过程）。

每个contact子元素包含了注册的contact地址，并可以包含以下属性：

• ID属性，惟一标识每个contact子元素，将它们相互区别开。

• contact子元素的state属性，指示相应的contact地址处于以下哪种状态,该状态与registration子元素URI的状态相关联：

■“活跃(Active）”(即URI使用本contact地址进行了注册）:

■“已结束(Terminated）"(即刚刚解除了URI和本contact信息之间的绑定关系）。

•contact子元素的event属性，指示导致contact的state属性发生最后一次变化的事件。这些事件可以是：

■已注册(Registered）该事件将contact地址状态从“初始化”变成“活跃”，并指示AOR已经被显式注册了(即收到了一个针对本AOR的有效的REGISTER请求，并且已经绑定了相关的contact信息）；

■已生成(Created）——该事件与“已注册"事件的含义相同，但它指示了AOR是隐性注册的(即绑定是自动创建的，例如当收到一个对其他AOR的REGISTER请求时）；

■已刷新(Refreshed）——该事件发生在对一个AOR进行重新注册时，也可能是隐性的(即对关联的AOR进行了重新注册）；

■已缩短(Shortened）——该事件发生在网络缩短了AOR的超时时间时(例如要触发网络发起的重认证，见10.13.2节）；

■去激活(Deactived）——该事件发生在网络删除绑定关系时(例如由于网络发起的解除注册），使用户能够以后再尝试进行新的初始注册；

■探测(Probation）——通过本事件，网络可以解除用户的注册，并要求一定时间(取决于retry-after值）后再发送一个新的初始注册；

■注册解除(Unregistered）该事件发生在用户明确地解除该contact

信息的注册状态时；

■拒绝(Rejected）——该事件发生在网络不允许用户注册某特定的contact时。

•附加的属性，例如：

■expire属性指示某特定contact地址的已注册状态的剩余超时时

间(在“已缩短”事件中必须设置，在其他事件中为可选）；

■retry-after属性——仅为“探测”事件设置，指示UE应等候多长时间后再次尝试进行注册。

10.12.9 注册状态信息的例子

Tobias的注册状态信息包含在NOTIFY请求消息的正文部分中，这个NOTIFY请求是S-CSCF发往UE和P-CSCF的。它首先包含一个XML文件的头部：

<?xmlversion="1.0"?>

<reginfoxmlns="um:ietf:params:xml:ns:reginfo"version=M0Hstate=“fUll”>

该头部指示所使用的XML版本(1.0）.注册信息总是从根元素“reginfb”开始，它包括很多属性：

• xmlns属性指向统一资源名称(URN）,它定义了XML文件和XML命名空间的。

• version属性总是从“0”开始，并且在每次有新版本(即更新后）的注册状态信息发往同一接收者时，该属性的值就递增1。

• state属性指示下面的注册状态信息是与Tobias有关的所有AOR的完整列表。第一个版本(“0”）的reginfb文件总是要作为完整(“fiill”）列表来发送，后续信息(从“1"开始）可以是“部分”的，可以仅包含上一次通知之后发生的改变。

和Tobias有关的所有公共用户标识及其注册状态在如下文档中列出：

〈registrationaor=”sip:tobias@homel.fr”id="al”state="active">

〈contactid="15”state=Hactivenevent="registered">

sip:[5555::l:2:3:4]

</contact>

</registration>

第一个AOR或URI是“sip:tobias@homel.fir”，在前面的例子中已经了解。它现在的状态是已注册(state="active”）。这个registration子元素的内容是一个contact子元素，它指示S-CSCF创建了在sip:tobias@homel.fr和联系信息sip[55551234].之间的绑定。event属性设置为“registered表示该AOR显式注册为卷个contact地址：这一点可以得到证实，因为本章描述的注册过程显示了To消息头中的AOR和Contact头中的IP地址。

<egistrationaor="tel:+44-123-456-789"id=”a2"state=Hactive">

<contactid=“16“state=”active“event=vcreated">

sip:[5555::l:2:3:4]

</contact>

</registration>

下一个AOR是一个telURL,它是隐性注册的(event="created”），与第一个AOR使用相同的IP地址。这个隐性注册是由S-CSCF根据Tobias的用户配置数据而实施的。在这种情况下，电话号码直接关联到SIPURIsip:tobias@homel.fr。

<egistrationaor="sip:tobi@homel.frHid="bi"state="terminated">

</registration>

Registrationaor=”tel:+44-123-456-111”id=”b2"state="terminated">

</registration>

这两个AOR目前都还是未注册的(state="terminated”)，因此registration子元素并不包含任何信息。最后，Tobias还是一个在线角色扮演游戏(RPG)的游戏管理员，他非常重视游戏管理员的工作，因此他总是通过一个游戏控制台保持注册状态，控制台地址是sip[55551OHO21O31O4]。控制台的联系地址是显式注册的(event="registered”)，但是，Tobias还希望在他通过IMSUE在线时也能获知游戏的进展状态；因此接收到对sip:tobias@homel.fr的REGISTER请求时，这个AOR也被S-CSCF所隐性注册(event="created”)了。

〈registration aor="sip:gameMaster@home1.fr"id=”cl'state=nactive">

<contactid=,,45nstate="active"event="registered">

sip:[5555::101:102:103:104]

</contact>

〈contactid="19”state="active"event="created">

sip:[5555::l:2:3:4]

</contact>

</registration>

</reginfb>

注册状态信息的最后一行的标签标志本XML文件结束。

10.12.10多个终端和注册状态信息

可以通过不同的终端(即不同的UE)注册一个或多个公共用户标识。在我们的例子中，Tobias还可能拥有一个简单的寻呼设备，也使用他的公共用户标识sip:tobias@home1.fro在使用IMS服务之前，这个设备也需要执行注册过程。这个注册过程可以通过另一个不同的P-CSCF进行，但是最终必须与第一个注册使用同一个S.CSCF。

在寻呼设备注册之后，Tobias的UE和他的P-CSCF会接收到另一个NOTIFY

消息，指示关于其公共用户标识出现了另一个contact信息：也就是说，与NOTIFY消息正文中首个AOR有关的信息应包含以下内容：

<?xmlversion=“1.0“?>

<reginfbxmlns="um:ietf:params:xml:ns:regmfo"version="l"state="partial”>

<registrationaor=nsip:tobias@home1.fr"id="al"state="active">

<contactid=n15Hstate=''active''event=Hregistered,,>

sip:[5555::l:2:3:4]

</contact>

<contactid="20”state="active"event=”registered''>

sip:[5555::171:171:172:173]

〈/contact〉

</registration>

</reginfb>

以上注册信息中的第二组联系信息是属于寻呼设备的。注意这是UE所收到的第二组注册状态信息。为了确保不丢失任何注册状态信息,"version"参数设置为"1"(第一组信息的"version"参数设置为"0"）。第一个NOTIFY己经包含了完整的注册状态信息，因此这次UE只收到了发生改变的注册元素的信息，本例中即为AOR sip:tobias@homel.fr的信息。因此，state参数设置为"partial"(在第一组信息中它设置为"fiill"）。

10.12.11相关标准

与10.12节有关的规范有：