7 UA Procedures
29.0793GPPOptimal media routeing within the IP Multimedia Subsystem (IMS)Release 17Stage 3TS
7.1 UA sending an initial SDP offer
Upon preparing an initial SDP offer for sending to begin an initial SDP offer/answer transaction, a UA supporting OMR shall additionally:
1) add to the initial SDP offer a visited-realm instance for the IP realm associated with the connection address and port information for the media line in the initial SDP offer;
2) for each combination of IP realm, nettype and addrtype on the outgoing side for which the UA can allocate an MR termination according to local policy, if the IP realm, nettype and addrtype are not associated with the media line in the initial SDP offer, allocate an MR termination for the IP realm, nettype and addrtype on the outgoing side, using the same codecs associated with the media line;
3) add to the initial SDP offer a secondary-realm instance for each termination allocated in step 2); and
4) compute a checksum values as described in clause 5.6.3 and add the "omr-s-cksum" and "omr-m-cksum" attributes for the media line.
The UA then sends the initial SDP offer according to TS 24.229 [4].
NOTE: A subsequent SDP offer is sent according to procedures in clause 8.
7.2 UA receiving an initial SDP offer
7.2.1 General
Upon receiving an SDP offer that includes OMR attributes and selecting a codec for the media line, a UA supporting OMR shall perform the procedures specified in clauses 7.2.2 and 7.2.3, and then send the initial or second SDP answer according to TS 24.229 [4].
7.2.2 Validating the incoming SDP offer
If any of the following conditions are true:
1) the SDP offer includes any OMR attributes for the media line, but no visited-realm instance;
2) the connection-address and port information in the visited-realm instance with the highest value of instance-number for the media line does not match the connection address and port information for the media line; or
3) one of the following checksum comparison failures are true:
– the "omr-m-cksum" attribute does not match the checksum value computed for the media line as described in clause 5.6.3; or
– based on local policy, if the "omr-m-cksum" attribute matches the computed media line checksum, but the "omr-s-cksum" attribute does not match the checksum value computed for the session level lines as described in clause 5.6.3,
then the UA shall remove all OMR related attributes associated with the media line.
7.2.3 UA may choose an alternate realm instance to bypass an upstream MR
If all the following conditions are true:
1) the UA can make available a media termination in an IP realm, nettype and addrtype such that this IP realm or a connected IP realm, nettype and addrtype match the IP realm, nettype and addrtype of a visited-realm or secondary-realm instance for the media line in the SDP offer;
2) the instance does not match the connection address and port information in the SDP offer; and
3) the instance supports the codec selected by the UA,
then the UA shall:
1) select the visited-realm or secondary-realm instance with the lowest value of instance-number such that the UA can make available a media termination in the IP realm or connected IP realm, nettype and addrtype that matches the IP realm, nettype and addrtype of the instance and the instance supports the codec selected by the UA;
2) allocate a media termination in the selected IP realm, nettype and addrtype;
3) copy into the media line of the SDP answer the selected visited-realm or secondary-realm instance from the media line of the received SDP offer, replacing the connection-address and port information in the instance with the local connection address and port information for the allocated termination, and if the IP realm in the instance is a connected IP realm, replacing the IP realm name with the corresponding local IP realm name; and
4) replace the connection address information in the SDP answer with the unspecified address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid.invalid").
7.3 UA receiving an initial SDP answer
7.3.1 General
Upon receiving the initial SDP answer corresponding to the initial SDP offer sent in clause 7.1, the UA supporting OMR shall perform the procedures specified in either clause 7.3.2 if the initial SDP answer included a realm instance or clause 7.3.3 if the initial SDP answer did not include a realm instance.
7.3.2 Receiving SDP answer with an unspecified connection address
If the received SDP answer for the media line includes an unspecified connection address (i.e., IPv4: "0.0.0.0", IPv6: "invalid.invalid") and a visited-realm or a secondary-realm instance with an instance-number that matches a visited-realm or secondary-realm instance for the media line from the SDP offer, then the UA shall:
NOTE: The IP realms in the two realm instances either have the same name or are connected.
1) update the remote connection address and port information for the selected outgoing termination with the connection-address and port information from the visited-realm or secondary-realm instance in the received SDP answer; and
2) release any other MR apart from the selected MR allocated for the media line, when it is no longer potentially needed for any other forked dialog.
7.3.3 Receiving SDP answer with a valid connection address
If the received SDP answer includes a valid (not unspecified) connection address for the media line, then the UA shall:
1) update the remote connection address and port information for the primary outgoing termination with the connection address and port information from the received SDP answer; and
2) release any secondary MR allocated for the media line, when it is no longer potentially needed for any other forked dialog.
7.4 UA OMR media resource operations
7.4.1 General
The UA OMR procedures as specified by clauses 7.1, 7.2, and 7.3 refer to generic MR allocation operation. This allocation will result in the allocation of a local media termination associated with the selected IP realm.
Subsequent SDP offer/answer exchanges may result in either the exact same local MR being allocated or possibly a different local MR. If the UA is able to determine that the same resource information is being requested, the existing allocated local MR will be used. If the previously allocated local MR does not match the resource information needed, then the local MR will be modified to meet the current need.
7.4.2 UA operations
The OMR MR procedures in this document are applicable to the following IMS entities that perform as UA using the media resource interface operations as indicated.
– An AS acting as B2BUA and adapting UA procedures to control an MRF shall use one or more of the following:
– IETF RFC 4240 [11] conference service and tone/announcement service;
– IETF RFC 5552 [18]; and
– IETF RFC 3260 [12] and IETF RFC 6505 [13].
– An MGCF acting as an UA controlling an IM-MGW using the Mn interface as defined by TS 29.163 [17] and TS 29.332 [14]:
– Reserve IMS Connection Point;
– Configure IMS Connection Point;
– Reserve and Configure IMS Connection Point; and
– Release IMS Connection Point.
7.5 Handling of connected IP realms
For each IP realm to which a controlled MR has direct access, the UA supporting OMR may be provisioned with a list of the names of connected IP realms, if any. The UA shall determine if an IP realm is connected to a local IP realm based only on provisioning.
NOTE 1: The OMR algorithm assumes that a first IMS-ALG or UA sending an SDP offer that offers connectivity via a local IP realm will accept from a second IMS-ALG or UA an SDP answer with an address in a connected IP realm, even if the first IMS-ALG or UA does not have provisioned information about the connected IP realm.
NOTE 2: Connected IP realm lists only need to be provisioned at certain OMR-capable nodes. For example, it is preferred that an IBCF whose TrGW has connectivity to multiple peer networks via bilateral interconnect be provisioned with connected IP realm information.