C.2 P-CSCF procedures

29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS

C.2.1 General

The procedures in clause C.2 are only invoked in the case where the local UE (uplink SDP) has utilized the ICE protocol for media traversal of NATs. The P-CSCF can determine this by inspecting the UE provided SDP (uplink) for the "a=candidate" attribute(s). If such attributes are present this is an indication that the UE has invoked the ICE procedures as defined in IETF RFC 8445 [67] and IETF RFC 8839 [68] for media traversal of NATs and the P-CSCF shall follow the requirements in clause C.2.

C.2.2 Deriving the Ues IP address

The P-CSCF shall set the Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP to the source IP address of SIP messages received from the UE.

C.2.3 Deriving flow descriptions

In the case where STUN Relay and ICE are used for NAT traversal, the UE is required to place the STUN Relay provided address in the “m=” and “c=” lines of its SDP. Given that these addresses cannot be used by the P-CSCF for building a valid flow description, the P-CSCF will need to determine if a STUN Relay address has been provided in the “m=” and “c=” lines of the UE provided SDP (uplink only). The P-CSCF shall make this determination by inspecting the uplink SDP for “a=candidate” attributes and compare the candidate address with that contained in the “c=” line. If a match is found, the P-CSCF shall then look at the candidate type. If the candidate type is “relay” then the address in the “c=” line is that of a STUN Relay server. In this case, the P-CSCF shall derive the Flow-Description AVP within the service information from the SDP candidate type of “relay” as follows:

Uplink Flow-Description

– Destination Address and Port: If the P-CSCF knows the destination address and port of the STUN Relay allocation that the UE is sending media to, it should use that information. If the P-CSCF does not know this address and port, it shall wildcard the uplink destination address and port.

– Source Address and Port: The P-CSCF shall populate the uplink source address with the “rel-addr” address and the uplink source port with the “rel-port” port contained within the “a=candidate” attribute.

Downlink Flow-Description

– Destination Address and Port: The P-CSCF shall populate the downlink destination address with the “rel-addr” address and the downlink destination port with the “rel-port” port contained within the “a=candidate” attribute.

– Source Address and Port: If the P-CSCF knows the source address and port of the STUN Relay allocation that the UE is receiving media from, it should use that information. If the P-CSCF does not know this address and port, it shall wildcard the downlink source address and port.

For the other candidate types, the address in the “c=” and “m=” SDP attributes can be used for building the flow descriptor and the P-CSCF shall follow the rules to derive the Flow-Description AVP as described in table 6.2.2 of clause 6.2 of this TS.

C.2.4 Gating control

If both endpoints have indicated support for ICE (both the SDP offer and answer contain SDP attributes of type “a=candidate”) ICE connectivity checks will take place between the two Ues. In order to allow these checks to pass through the PCEF, the P-CSCF shall enable each flow description for each media component upon receipt of the SDP answer.

C.2.5 Bandwidth impacts

ICE has been designed such that connectivity checks are paced inline with RTP data (sent no faster than 20ms) and thus consumes a lesser or equal amount of bandwidth compared to the media itself (given the small packet size of a STUN connectivity check it is expected that the STUN connectivity checks will always have a smaller payload than the media stream itself). Thus, there are no additional requirements on the P-CSCF for bandwidth calculations for a given media flow.