H.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

H.3.1 Procedures at the UE

H.3.1.0 Void

H.3.1.0a IMS_Registration_handling policy

Not applicable.

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

If the UE is aware of the access technology, the UE shall include the P-Access-Network-Info header field where indicated in subclause 5.1.

H.3.1.1A Cellular-Network-Info header field

Not applicable.

H.3.1.2 Availability for calls

Not applicable.

H.3.1.2A Availability for SMS

Void.

H.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.

H.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.

H.3.1.5 3GPP PS data off

Not applicable.

H.3.1.6 Transport mechanisms

No additional requirements are defined.

H.3.1.7 RLOS

Not applicable.

H.3.2 Procedures at the P-CSCF

H.3.2.0 Registration and authentication

Void.

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

If the access-type field in the P-Access-Network-Info header field indicated DOCSIS access the P-CSCF shall assume that the initial request for a dialog or standalone transaction or an unknown method destined for a PSAP is initiated in the same country.

NOTE 1: If local policy does not require the insertion of P-Access-Network-Info header field in the P-CSCF even if it is missing in the received initial request, the P-CSCF can assume that the request is initiated by fixed broadband UE in the same country.

NOTE 2: If the network provided and UE provided P-Access-Network-Info header fields indicate different access types the P-CSCF ignores the information in either the network provided or the UE provided P-Access-Network-Info header field according to operator policy.

H.3.2.2 Location information handling

Upon receipt of an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF based on local policy may include a P-Access-Network-Info header field.

NOTE: The way the P-CSCF deduces that the request comes from a UE connected through DOCSIS access is implementation dependent.

H.3.2.3 Void

H.3.2.4 Void

H.3.2.5 Void

H.3.2.6 Resource sharing

Not applicable.

H.3.2.7 RLOS

Not applicable.

H.3.3 Procedures at the S-CSCF

H.3.3.1 Notification of AS about registration status

Not applicable.

H.3.3.2 RLOS

Not applicable.