The UE can establish media streams that belong to different SIP sessions on the same PDP context. During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data stream(s) may result in activation of additional PDP context(s). Such additional PDP context(s) shall be established as secondary PDP contexts associated to the PDP context used for signalling. Such secondary PDP contexts for media can be established either by the UE or the core network. If the bearer establishment is controlled by the UE, the UE starts reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available as specified in TS 24.008.

If the UE is configured not to initiate resource allocation for media according to TS 24.167 and both UE and the core network are allowed to establish the secondary PDP contents, then the UE shall refrain from establishing the secondary PDP context(s) for media and from modifying existing PDP contexts for media until the UE considers that the network did not initiate resource allocation for the media. If the UE receives indication within the SDP according to RFC 3524 that media stream(s) belong to group(s), the media stream(s) shall be set up on separate PDP contexts according to the indication of grouping of media streams. The UE may freely group media streams to PDP context(s) in case no indication of grouping of media streams is received from the P-CSCF. If the capabilities of the originating UE prevents it from establishment of additional PDP contexts according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the originating UE shall negotiate media parameters for the session according to RFC 3264. If the capabilities of the terminating UE prevents it from establishment of additional PDP contexts according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the terminating UE shall 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:

• either use existing PDP context(s) where another media authorization token is already in use and no indication of grouping of media streams is required; or
• establish separate PDP context(s) for the media; or
• use an existing PDP context where media authorization token is not in use and no indication of grouping of media streams is required.

When a UE modifies a PDP context to indicate a new media authorization token:

• either as a result of establishment of an additional SIP session; or
• modification of media streams for an ongoing SIP session;

the UE shall include all media authorization tokens and all flow identifiers for all ongoing SIP sessions that use this particular PDP context. If a media authorization token is received in subsequent messages for the same SIP session, the UE shall:

• use the existing PDP context(s) for media;
• modify the existing PDP context(s) for media; or
• establish additional PDP context(s) for media.

If either background or interactive QoS class is needed for the media, then the UE does not need to use the authorization token even if it receives one. In this case the UE may reuse an existing PDP context and it does not need to request PDP context modification unless it needs to modify the QoS. If existing PDP context(s) where another media authorization token is already in use is re-used for the media, or separate PDP context(s) is established for the media, the UE shall proceed as follows:

• when a SIP session is terminated, the media authorization token is no longer valid and the UE shall not include it in future GPRS session management messages. The UE shall send a MODIFY PDP CONTEXT REQUEST message updating the binding information by deleting the media authorization token and the corresponding flow identifiers that are no longer valid. If a SIP session is terminated and no other SIP sessions are using the PDP context, the UE shall either update the binding information as described above or deactivate the PDP context;
• the UE shall transparently pass the media authorization token received from the P-CSCF in a response to an INVITE request at originating setup or in the INVITE request at terminating setup to the core network. The UE shall signal it by inserting it within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message;
• to identify to the core network which flow(s) (identified by m-lines within the SDP) that are transferred within a particular PDP context, the UE shall set the flow identifier(s) within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message. Detailed description of how the flow identifiers are constructed is provided in 3GPP TS 29.207 [12];
• if the UE receives several media authorization tokens from the P-CSCF within the same SIP request or response, the first instance of the media authorization token shall be sent to the core network, and subsequent instances are discarded by the UE; and
• the UE shall not include the IM CN Subsystem Signalling Flag when a PDP context for media is established or modified.

The encoding of the media authorization token and the flow identifiers within the Traffic Flow Template information element is described in TS 24.008.

If the UE receives an activation request for a PDP context which is associated with the PDP context used for signalling, the UE shall, based on the information contained in the Traffic Flow Template information element, correlate the media PDP context with a currently ongoing SIP session establishment or SIP session modification. If the UE receives a modification request for a PDP context that is used for one or more media streams in an ongoing SIP session, the UE shall:

1. modify the related PDP context in accordance with the received modification request.

When a data stream for media related to a session is released, if the PDP context transporting the data stream is no longer needed and if the PDP context has been activated by the UE, then the UE deactivates the PDP context.

Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE sets up the PDP context(s) as required by the initial response received. If a subsequent provisional response is received, different alternative actions may be performed depending on the requirements in the SDP answer:

1. the bearer requirements of the subsequent SDP can be accommodated by the existing PDP context(s). The UE performs no activation or modification of PDP contexts.
2. the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the existing PDP context(s), if necessary, according to subclause B.2.2.5.1A.
3. the subsequent SDP introduces one or more additional IP flows. The UE establishes additional PDP context(s) according to subclause B.2.2.5.1A.

When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall release all the unneeded radio/bearer resources. Therefore, upon the reception of the first final 200 (OK) response for the INVITE request (in addition to the procedures defined in Section 13.2.2.4 of RFC 3261), the UE shall:

1. in case PDP context(s) were established or modified as a consequence of the INVITE request and forked provisional responses that are not related to the accepted 200 (OK) response, delete the PDP context(s) or modify the delete the PDP context(s) back to their original state.

One of the Go, Gq, Rx and Gx interface related error codes can be received by the UE in the ACTIVATE SECONDARY PDP CONTEXT REJECT message or the MODIFY PDP CONTEXT REJECT message. If the UE receives a Go, Gq, Rx and Gx interface related error code, the UE shall either handle the resource reservation failure as described in subclause 6.1.1 or retransmit the message up to three times. The Go, Gq, Rx and Gx interface related error codes are further specified in 3GPP TS 29.207 [12], 3GPP TS 29.209 [13A], TS 29.214 and TS 29.212.

Emergency bearers are defined for use in emergency calls in GPRS IP-CAN and core network support of these bearers is indicated to the UE in NAS signalling. Where the UE recognises that a call request is an emergency call and the core network supports emergency bearers, the UE shall use these bearers for both signalling and media on emergency calls made using the IM CN subsystem. Some jurisdictions allow emergency calls to be made when the UE does not contain an ISIM or USIM, or where the credentials are not accepted. Additionally, where the UE is in state GMM-REGISTERED.LIMITED-SERVICE and GMM-REGISTERED.PLMN-SEARCH, a normal ATTACH has been attempted but it can also be assumed that a registration in the IM CN subsystem will also fail. In such cases, subject to the lower layers indicating that the network does support emergency bearer services in limited service state (see TS 25.331), the procedures for emergency calls without registration can be applied, as defined in subclause 5.1.6.8.2. If the GPRS authentication procedure has already succeeded during the latest normal or emergency ATTACH procedure, the UE shall perform an initial emergency registration, as described in subclause 5.1.6.2 before attempting an emergency call as described in subclause 5.1.6.8.3. When activating a PDP context to perform emergency registration, the UE shall request a PDP context for emergency bearer services as defined in TS 24.008. The procedures for PDP context activation and P-CSCF discovery, as described in subclause B.2.2.1 of this specification apply accordingly. In order to find out whether the UE is attached to the home PLMN or to the visited PLMN, the UE shall compare the MCC and MNC values derived from its IMSI with the MCC and MNC of the PLMN the UE is attached to. If the MCC and MNC of the PLMN the UE is attached to donot match with the MCC and MNC derived from the IMSI, then for the purpose of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN. If the dialled number is equal to an emergency number stored in the ME, in the USIM or in the Local Emergency Number List (as defined in TS 24.008), then the UE shall recognize a number as for an emergency call and performs the procedures in subclause B.2.2.6.1A. Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, if:

• the 380 (Alternate Service) response contains a Contact header field;
• the value of the Contact header field is a service URN; and
• the service URN has a top-level service type of "sos";

then the UE determines that "emergency service information is included" as described TS 23.167. Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.3.1 if the 380 (Alternate Service) response does not contain a Contact header field with service URN that has a top-level service type of "sos", then the UE determines that "no emergency service information is included" as described TS 23.167. If the "emergency service information is included" as described TS 23.167:

1. if the URN in the Contact header field matches an emergency service URN in Table B.2.2.6.1, then the type of emergency service is the value corresponding to the matching entry in Table B.2.2.6.1; and
2. if the URN in the Contact header field does not match any emergency service URN in Table B.2.2.6.1, then the type of emergency service is not identified.

When the emergency registration expires, the UE should disconnect the PDP context for emergency bearer services as defined in TS 24.008. Upon receiving a 3xx other than 380 (Alternative service), 4xx, 5xx or 6xx response to an INVITE request for a UE detectable emergency call, the UE shall perform domain selection as specified in TS 23.167 Annex H, to re-attempt the emergency call.

The type of emergency service for an emergency number is derived from the settings of the emergency service category value (bits 1 to 5 of the emergency service category value as specified in subclause 10.5.4.33 of TS 24.008). Table B.2.2.6.1 below specifies mappings between a type of emergency service and an emergency service URN. The UE shall use the mapping to match an emergency service URN and a type of emergency service. If a dialled number is an emergency number but does not map to a type of emergency service the service URN shall be "urn:service:sos".

If an IP-CAN, capable of providing local emergency numbers, did not provide a local emergency number that matches the dialled number (see subclause 5.1.6.1) and multiple types of emergency service can be derived for a dialled number from the information configured on the USIM then:

• if the UE is in the HPLMN, the UE shall map any one of these types of emergency service to an emergency service URN as specified in Table B.2.2.6.1; and
• if the UE is in the VPLMN, the UE shall select "urn:service:sos".

If an IP-CAN, capable of providing local emergency numbers, provided a local emergency number that matches the dialled number (see subclause 5.1.6.1), and:

• if the UE can derive one or more types of emergency service from the information received from the IP-CAN for the dialled number and the UE cannot derive types of emergency service from the information configured on the USIM for the dialled number; or
• if the UE is able to derive identical types of emergency service from both the information received from the IP-CAN for the dialled number and from the information configured on the USIM for the dialled number,

then the UE shall map any one of these emergency service types to an emergency service URN as specified in Table B.2.2.6.1.

Void

The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

Void.