M.3 Application usage of SIP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

M.3.1 Procedures at the UE

M.3.1.0 Void

M.3.1.0a IMS_Registration_handling policy

Not applicable.

M.3.1.1 P-Access-Network-Info header field

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

M.3.1.1A Cellular-Network-Info header field

Not applicable.

M.3.1.2 Availability for calls

Not applicable.

M.3.1.2A Availability for SMS

Void.

M.3.1.3 Authorization header field

When using SIP digest or SIP digest without TLS, the UE need not include an Authorization header field on sending a REGISTER request, as defined in subclause 5.1.1.2.1.

NOTE: In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity. The public user identity is set so that it is possible to derive the private user identity from the public user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters. Therefore, the public user identity used for registration in this case cannot be shared across multiple UEs. Deployment scenarios that require public user identities to be shared across multiple UEs that don’t include an private user identity in the initial REGISTER request can be supported as follows:

– Assign each sharing UE a unique public user identity to be used for registration,

– Assign the shared public user identitiess to the implicit registration set of the unique registering public user identities assigned to each sharing UE.

M.3.1.4 SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE

Not applicable.

M.3.1.5 3GPP PS data off

Not applicable.

M.3.1.6 Transport mechanisms

No additional requirements are defined.

M.3.1.7 RLOS

Not applicable.

M.3.2 Procedures at the P-CSCF

M.3.2.0 Registration and authentication

Void.

M.3.2.1 Determining network to which the originating user is attached

For an HRPD UE, after the initial request for a dialog or standalone transaction or an unknown method is received the P-CSCF shall check the Carrier ID field received in the P-Access-Network-Info header field to determine from which network the request was originated.

NOTE: For 3GPP2-1X and 3GPP2-UMB, no IP-CAN specific support is provided in the current release. No carrier identification is provided for 3GPP2-1X or 3GPP2-UMB in the P-Access-Network-Info header field, and thus there is no IMS specific procedure for identifying that the UE is in the home network.

M.3.2.2 Location information handling

Void

M.3.2.3 Void

M.3.2.4 Void

M.3.2.5 Void

M.3.2.6 Resource sharing

Not applicable.

M.3.2.7 Priority sharing

Not applicable.

M.3.2.8 RLOS

Not applicable.

M.3.3 Procedures at the S-CSCF

M.3.3.1 Notification of AS about registration status

The procedures described in subclause 5.4.1.7 apply with the additional procedures described in the present subclause:

1) in case the received REGISTER request contained a Timestamp header field, the S-CSCF shall insert a Timestamp header field with the value of the Timestamp header field from the received REGISTER request.

M.3.3.2 RLOS

Not applicable.