O.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
O.3.1 Procedures at the UE
O.3.1.0 Void
O.3.1.0a IMS_Registration_handling policy
Not applicable.
O.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.
O.3.1.1A Cellular-Network-Info header field
Not applicable.
O.3.1.2 Availability for calls
Not applicable.
O.3.1.2A Availability for SMS
Void.
O.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.
O.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.
O.3.1.5 3GPP PS data off
Not applicable.
O.3.1.6 Transport mechanisms
No additional requirements are defined.
O.3.1.7 RLOS
Not applicable.
O.3.2 Procedures at the P-CSCF
O.3.2.0 Registration and authentication
Void.
O.3.2.1 Determining network to which the originating user is attached
The P-CSCF handling is as defined in subclause M.3.2.
NOTE: Emergency call support for the EPC IP-CAN is not specified in this release. A common P-Access-Network-Info header field value is used for both cdma2000® HRPD based IP-CANs (i.e. HRPD access specified by 3GPP2 X.S0011‑E [127], and HRPD access as specified by 3GPP2 X.P0057 [86C]). The result of this is that in both cases the handling in the P-CSCF will be identical. If an operator deploys an IM CN subsystem with both cdma2000® HRPD based IP‑CANs, the P-CSCF has no means of distinguishing one from the other. The emergency call handling for the EPC IP‑CAN using cdma2000® HRPD access as specified by 3GPP2 X.P0057 [86C] is out of scope for this release of this specification, and therefore all identified emergency calls with a P-Access-Network-Info header field value of "3GPP2‑1X‑HRPD" will be handled with a 380 (Alternative Service) response when HRPD IP-CAN emergency support is not active.
O.3.2.2 Location information handling
Void.
O.3.2.3 Void
O.3.2.4 Void
O.3.2.5 Void
O.3.2.6 Resource sharing
If the P-CSCF supports resource sharing, PCC is supported for this access technology and if according to local policy, the P-CSCF shall apply the procedures in subclause L.3.2.6.
O.3.2.7 Priority sharing
If the P-CSCF supports priority sharing, PCC is supported for this access technology and if according to operator policy, the P-CSCF shall apply the procedures in subclause L.3.2.7.
O.3.2.8 RLOS
Not applicable.
O.3.3 Procedures at the S-CSCF
O.3.3.1 Notification of AS about registration status
The S-CSCF handling is as defined in subclause M.3.3.1.
O.3.3.2 RLOS
Not applicable.