|
|
|
|
3GPP TS 24.228 -- IMS Signalling flows for Register
|
|
|
|
|
|
|
| Session Initiation: Non Hiding |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| Session Initiation: Hiding |
| |
|
| |
|
| |
|
| |
|
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
UE1 is located in a visited network, and determines the P-CSCF via the CSCF discovery procedure.
|
|
|
|
|
|
|
|
| - |
The purpose of this request is to register the user's SIP URI with a S-CSCF in the home network. This
request is routed to P-CSCF1 because it is the only SIP server known to UE1.
| |
| - |
Request-URI:
The Request-URI (the URI that follows the method name, "REGISTER", in the first line)
indicates the destination domain of this REGISTER request. The rules for routing a SIP
request describe how to use DNS to resolve this domain name ("registrar.home1.net") into an
address or entry point into the home operator's network (the I-CSCF). This information is
stored in the USIM.
| |
| - |
Via:
IPv6 address of the UE allocated during the PDP Context Activation process.
| |
| - |
P-Access-Network-Info:
UE1 provides the access-type and access-info, related to the serving access network.
| |
| - |
From:
This indicates the public user identity originating the REGISTER request. The public user
identity may be obtained from the USIM.
| |
| - |
To:
This indicates the public user identity being registered. This is the identity by which other
parties know this subscriber. It may be obtained from the USIM.
| |
| - |
Contact:
This indicates the point-of-presence for the subscriber - the IP address of UE1. This is the
temporary point of contact for the subscriber that is being registered. Subsequent requests
destined for this subscriber will be sent to this address. This information is stored in the S-CSCF.
| |
| - |
Authorization:
It carries authentication information. The private user identity (user1_private@home1.net) is
carried in the username field of the Digest AKA protocol. The uri parameter (directive)
contains the same value as the Request-URI. The realm parameter (directive) contains the
network name where the username is authenticated. The Request-URI and the realm
parameter (directive) value are obtained from the same field in the USIM and therefore, are
identical. In this example, it is assumed that a new UICC card was just inserted into the
terminal, and there is no other cached information to send. Therefore, nonce and response
parameters (directives) are empty.
| |
| - |
Security-Client:
Lists the supported algorithm(s) by UE1.
| |
| - |
Supported:
This header is included to indicate to the recipient that UE1 supports the Path header.
|
|
|
|
|
|
|
|
| - |
Based on the user's URI, P-CSCF1 determines that UE1 is registering from a visiting domain and
performs the DNS queries to locate the I-CSCF in the home network.
When forwarding the REGISTER request P-CSCF1 needs to specify the protocol, port
number and IP address of the I-CSCF server in the home network to which to send the REGISTER
request. The DNS records are retrieved according to RFC 3263.
| |
| - |
P-CSCF1 performs an NAPTR query for the domain specified in the Request-URI.
| |
| - |
Based on the order and preference of the NAPTR record and the local preference, UDP is preferred and
P-CSCF1 finds the I-CSCF by a DNS SRV lookup according to RFC 2782.
| |
| - |
In the Answer field of the query-response each I-CSCF is identified by its host domain name. The
returned SRV Resource Records (RRs) are merged and ordered, and the selection technique (employing
the Priority and Weight parameters returned in the RRs) as specified in RFC 2782 is used to select
the I-CSCF (i.e. "icscf1_p.home1.net"). Since the Additional Data field of the query-response also
contains the IP address of the selected I-CSCF (i.e. "5555::aba:dab:aaa:daa"), a new query to the DNS is
not required.
P-CSCF1 will forward the REGISTER request to the IP
address "5555::aba:dab:aaa:daa" using the UDP protocol and port number 5060.
|
|
|
|
|
|
|
|
| - |
P-CSCF1 needs to be in the path for all mobile terminated requests for this user. To ensure this,
P-CSCF1 adds itself to the Path header value for future requests.
| |
| - |
P-CSCF1 adds the P-Visited-Network-ID header with the contents of the identifier of P-CSCF1
network. This may be the visited network domain name or any other identifier that identifies the
visited network at the home network.
| |
| - |
P-CSCF1 removes the Security-Client header and associated "sec-agree" option-tags prior to
forwarding the request. As the Proxy-Require header is empty, it removes this header completely.
| |
| - |
Path:
This is the address of P-CSCF1 and is included to inform S-CSCF1 where to route
terminating requests.
| |
| - |
Require:
This header is included to ensure that the recipient correctly handles the Path header. If the
recipient does not support the path header, a response will be received with a status code of
420 and an Unsupported header indicating "path". Such a response indicates a
misconfiguration of the routing tables and the request has been routed outside the IM CN
subsystem.
| |
| - |
P-Visited-Network-ID:
It contains the identifier of P-CSCF1 network at the home network.
| |
| - |
P-Charging-Vector:
P-CSCF1 inserts this header and populates the icid parameters with a globally
unique value.
|
|
|
|
|
|
|
|
|
| - |
Cx-Query, or Diameter UAR: User-Authorization-Request:
I-CSCF1 makes a request for information related to the Subscriber registration status by sending the
private user identity ("user1_private@home1.net"), public user identity ("user1_public1@home1.net")
and visited domain identifier ("Visited Network Number 1") to the HSS.
| |
| - |
Cx-Query response, or Diameter UAA: User-Authorization-Answer:
The HSS returns S-CSCF
required capabilities and I-CSCF1 uses this information to select a suitable S-CSCF.
|
|
|
|
|
|
|
|
| - |
I-CSCF1 does not modify the Path header.
| |
| - |
P-Access-Network-Info:
This header contains information from UE1.
| |
| - |
Path:
S-CSCF1 stores the contents of the Path header and uses the URI for routing mobile
terminated requests.
|
|
|
|
|
|
|
|
|
| - |
As the REGISTER request arrived without integrity protection to P-CSCF1, S-CSCF1 shall
challenge it. For this, S-CSCF1 requires at least one authentication vector (AV) to be used in the challenge
to the user. If a valid AV is not available, then S-CSCF1 requests at least one AV from the HSS.
| |
| - |
S-CSCF1 indicates to the HSS that it has been assigned to serve this user.
|
|
|
|
|
|
|
|
|
|
| - |
S-CSCF1 selects an authentication vector for use in the authentication challenge. For detailed
description of the authentication vector, see 3GPP TS 33.203.
NOTE: The authentication vector may be of the form as in 3GPP TS 33.203 (if IMS AKA is the selected
authentication scheme): AV = RANDn||AUTNn||XRESn||CKn||IKn where:
| - |
RAND: random number used to generate the XRES, CK, IK, and part of the AUTN.
It is also used to generate the RES at the UE.
|
| - |
AUTN: Authentication token (including MAC and SQN).
|
| - |
XRES: Expected (correct) result from the UE.
|
| - |
CK: Cipher key (optional).
|
| - |
IK: Integrity key.
|
| |
|
|
|
|
|
|
|
| - |
WWW-Authenticate:
S-CSCF1 challenges the user. The nonce includes the quoted string, base64 encoded
value of the concatenation of the AKA RAND, AKA AUTN and server specific data. S-CSCF1
appends also the Integrity Key (IK) and the Cyphering key (CK).
NOTE: The actual nonce value in the WWW-Authenticate header field is encoded in base64, and it may
look like: nonce="A34Cm+Fva37UYWpGNB34JP"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
P-CSCF1 removes any keys received in the 401 Unauthorized response and forwards the rest of the
response to UE1.
| |
| - |
WWW-Authenticate:
P-CSCF1 removes the ik and ck parameters (directives) from the header.
| |
| - |
Security-Server:
q is the preference value, 0.1 means IPsec is the first preferred choice. The q value
represents only relative degradation of all mechanisms listed here. The lower value, the
higher prority.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
Authorization:
This carries the response to the authentication challenge received in step 11 along with the
private user identity, the realm, the nonce, the URI and the algorithm.
This message is protected by the IPsec SA negotiated.
| |
| - |
Security-Verify:
Contains the security agreement as represented by the received Security-Server header.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
I-CSCF1 requests information related to the Subscriber registration status by sending the private user
identity, public user identity and visited domain name to the HSS. The HSS returns the S-CSCF name
which was previously selected in step 1d.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
Authentication:
Upon receiving an integrity protected REGISTER request carrying the authentication challenge
response, S-CSCF1 checks that the expected response (calculated by S-CSCF1 using XRES and
other parameter as defined in RFC 3310) matches the received challenge response. If the check is
successful then the user has been authenticated and the public user identity is registered in the S-CSCF.
| |
| - |
Cx-Put, or Diameter SAR: Server-Assignment-Request:
On registering a user, S-CSCF1 informs the HSS that the user has been registered at this instance.
| |
| - |
Cx-Put response, or Diameter SAA: Server-Assignment-Answer:
Upon being requested by S-CSCF1, the HSS will also include the user profile in the response sent to
the S-CSCF.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
S-CSCF1 sends a 200 (OK) response to I-CSCF1 indicating that Registration was successful.
| |
| - |
Service-Route:
S-CSCF1 inserts the Service-Route header that includes its own URI including a character
string in the user part to differentiate mobile originating requests from mobile terminating
requests.
|
|
|
|
|
|
|
|
| - |
I-CSCF1 forwards the 200 (OK) response from S-CSCF1 to P-CSCF1 indicating that the
registration was successful.
| |
| - |
P-CSCF1 saves the value of the Service-Route header and associates it with UE1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
