The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is xDSL, Fiber or Ethernet.
A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the fixed-broadband access network to provide packet-mode communication between the UE and the IM CN subsystem.
Requirements for the IP Edge node, defined in ETSI ES 282 001  in support of this communication are outside the scope of this document and specified elsewhere.
From the UEs perspective, it is assumed that one or more IP-CAN bearer(s) are provided, in the form of connection(s) managed by the layer 2 (e.g. DSL modem supporting the UE).
In the first instance, it is assumed that the IP-CAN bearer(s) is (are) statically provisioned between the UE and the IP Edge node, defined in ETSI ES 282 001 , according to the user's subscription.
It is out of the scope of the current Release to specify whether a single IP-CAN bearer is used to convey both signalling and media flows, or whether several PVC connections are used to isolate various types of IP flows (signalling flows, conversational media, non conversational media…).
The end-to-end characteristics of the fixed-broadband IP-CAN bearer depend on the type of access network, and on network configuration. The description of the network PVC termination (e.g., located in the DSLAM, in the BRAS…) is out of the scope of this annex.
Fixed-broadband bearer(s) is (are) statically provisioned in the current Release.
Unless a static IP address is allocated to the UE, prior to communication with the IM CN subsystem, the UE shall perform a Network Attachment procedure depending on the used fixed-broadband access type. When using a fixed-broadband access, both IPv4 and IPv6 UEs may access the IM CN subsystem. The UE may request a DNS Server IPv4 address(es) via RFC 2132 or a DNS Server IPv6 address(es) via RFC 3315.
The methods for P-CSCF discovery are:
When using IPv4, employ the Dynamic Host Configuration Protocol (DHCP) RFC 2132, the DHCPv4 options for SIP servers RFC 3361, and RFC 3263 as described in subclause 9.2.1. When using IPv6, employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP servers RFC 3319 and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 as described in subclause 9.2.1. In case the DHCP server provides several P-CSCF addresses or FQDNs to the UE, the UE shall select the P-CSCF address or FQDN as indicated in RFC 3319. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.
The UE selects a P-CSCF from the list in the IMS management object as specified in TS 24.167.
The UE shall use method II to select a P-CSCF if the IMS management object contains the P-CSCF list. Otherwise, the UE shall use method I to select a P-CSCF.
A UE supporting the P-CSCF restoration procedure uses the keep-alive procedures described in RFC 6223.
If the P-CSCF fails to respond to keep-alive requests the UE shall acquire a different P-CSCF address using any of the methods described in the subclause E.2.2.1 and perform an initial registration as specified in subclause 5.1.
If the UE receives indication within the SDP according to RFC 3524 that media stream(s) belong to group(s), and if several fixed-broadband bearers are available to the UE for the session, the media stream(s) may be sent on separate fixed-broadband bearers according to the indication of grouping. The UE may freely group media streams to fixed-broadband bearers in case no indication of grouping is received from the P-CSCF.
If the UE receives media grouping attributes in accordance with RFC 3524 that it cannot provide within the available fixed-broadband bearer(s), then the UE shall handle such SDP offers in accordance with RFC 3388.
The UE can receive a media authorization token in the P-Media-Authorization header field from the P-CSCF according to RFC 3313. If a media authorization token is received in the P-Media-Authorization header field when a SIP session is initiated, the UE shall reuse the existing fixed-broadband bearer(s) and ignore the media authorization token.
In order to reach IMS in some access networks, the UE may support:
address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in Annex F and Annex K; and
UE requested FTT-IMS establishment procedure specified in TS 24.322.
If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IMS. Use of these capabilities shall have the following priority order:
UE uses neither capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.
UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either Annex F or Annex K.
UE may use the UE requested FTT-IMS establishment procedure specified in TS 24.322. If the UE uses the UE-requested FTT-IMS establishment procedure specified in TS 24.322, the UE considers itself to:
be configured to send keep-alives;
be directly connected to an IP-CAN for which usage of NAT is defined; and
be behind a NAT.
Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
the mechanisms specified in this Annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
the UE shall establish the TLS connection to the P-CSCF on port 443 as defined in TS 33.203. The UE shall use SIP digest with TLS for registration as specified in subclause 5.1. If the TLS connection is established successfully, the UE sends SIP signalling over the TLS connection to the P-CSCF;
the UE shall support the keep-alive procedures described in RFC 6223;
the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;
when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 and TURN TCP as specified in RFC 6062.
if the UE is configured to use TURN over TCP on port 80, the UE shall establish the TCP connection to TURN server on port 80. If the UE is configured to use TURN over TLS on port 443, the UE shall establish the TLS connection to the TURN server on port 443 as defined in TS 33.203. If the UE is configured to use both, the UE should prefer to use TURN over TCP on port 80 to avoid TLS overhead;
if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766.
The P-CSCF may support UEs connected via restrictive non-3GPP access network.
If the P-CSCF supports UEs connected via restrictive non-3GPP access network, when the P-CSCF receives a 200 (OK) response to a REGISTER request, if the contact address of REGISTER request contains an IP address assigned by the EFTF, and the UE's Via header field contains a "keep" header field parameter, then the P-CSCF shall add a value to the "keep" header field parameter of the UE's Via header field of the 200 (OK) response as defined in RFC 6223.
Optional procedures apply when the P-CSCF is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
the P-CSCF supporting these additional procedures should use SIP digest with TLS as defined in subclause 5 and the P-CSCF should inserts an IMS-ALG on the media plane;
the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
the P-CSCF shall support the procedures defined in subclause 5.2, with the exception that the P-CSCF shall use SIP over TLS on port 443 as defined in TS 33.203;
when the UE has indicated support of the keep-alive mechanism defined in RFC 6223, the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and
the IMS-ALG in the P-CSCF shall support ICE procedures, as defined in subclause 126.96.36.199.
In order to determine from which network the request was originated the P-CSCF shall check if the location information received in the network provided and/or UE provided "dsl-location", "eth-location" or "fiber-location" parameter in the P-Access-Network-Info header field(s) belongs to a location in the same country.
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.The value of the "dsl-location", "eth-location" or "fiber-location" parameter shall be the value as received in the Location-Information header in the User-Data Answer command as specified in ETSI ES 283 035 .