6 IMS-ALG procedures

29.0793GPPOptimal media routeing within the IP Multimedia Subsystem (IMS)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 IMS-ALG handling of initial SDP offer

6.1.1 General

Upon receiving an initial SDP offer, the IMS-ALG supporting OMR shall apply the procedures in the following clauses for each media line with non-zero port value.

Upon receiving a second SDP offer that includes OMR attributes for some media lines, the IMS-ALG supporting OMR shall apply the procedures in the following clauses for each media line with non-zero port value and OMR attributes.

NOTE: An example of a second SDP offer/answer transaction is when any of the IMS-ALGs performs proactive transcoding without resource reservation or removes media resources when transcoding is no longer required. See clauses 6.2.2 and 6.2.3.

After the completion of an initial SDP offer/answer transaction and when receiving an SDP offer without OMR attributes for a media line, the IMS-ALG supporting OMR shall apply the procedures for subsequent SDP offer/answer transaction in clause 8 for that media line.

6.1.2 Validating the received SDP offer

If any of the following conditions are true:

1) the received 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 conditions 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 IMS-ALG shall remove all OMR attributes associated with the media line from the received SDP offer and use the modified SDP offer as the received SDP offer in the procedures in the following clauses.

6.1.3 Deciding whether to allocate a primary local MR and if any previous MR can be bypassed

The IMS-ALG considers information in the received SDP offer and applies local policy to decide whether to allocate a primary local MR and if it is to bypass any previous MRs.

NOTE: An IMS-ALG can revise these decisions when receiving the SDP answer, applying procedures in clause 6.2.

The IMS ALG shall perform the following steps:

0) If the connection address for the media line in the received SDP offer is the unspecified address, then the IMS-ALG should:

a) select to not allocate a primary local MR (regardless of local policy), and to not bypass any previous MRs;

b) convert the unspecified address in the connection address for the media line in the received SDP offer to the addrtype of the outgoing IP realm, if necessary;

c) if subsequently choosing to perform proactive transcoding in clause 6.1.7, then select to perform proactive transcoding without resource reservation (regardless of local policy);

d) select to not add secondary-realm instances to the modified SDP offer when performing the procedure in clause 6.1.8 (regardless of local policy); and

e) skip to step 6),

1) If all of the following conditions apply:

a) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT traversal on the incoming signalling path, or for legal interception; and

b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and addrtype associated with a visited-realm or secondary-realm instance for the media line

– such that the instance has an instance-number value i that is less than the highest instance-number value n associated with the media line in the received SDP offer; and

– such that the instance i is associated with a codec list, determined using the procedures in clause 5.3, which includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing codecs proactively without reserving an MR,

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and shall store the realm instances with instance-number greater than i, which are associated with MRs that can be bypassed without allocating a primary local MR.

2) If the following condition applies:

a) the IMS-ALG controls an MR with access to an IP realm or connected IP realm, nettype and addrtype associated with a visited-realm or secondary-realm instance for the media line

– such that the instance has an instance-number value j that is less than the highest instance-number value n associated with the media line in the received SDP offer; and

– such that the instance j is associated with a codec list, determined using the procedures in clause 5.3, which includes all codecs required by local policy, unless such codecs are provided at a local MR via transcoding,

then the IMS-ALG shall store the realm instances with instance-number greater than j, which are associated with MRs that can be bypassed when allocating a primary local MR.

3) If all of the following conditions apply:

a) the condition in step 1) does not apply;

b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and addrtype for the incoming signalling path;

c) the codec list in the received SDP offer, determined from the SDP m-line and associated non-OMR attribute lines, includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing codecs proactively without reserving an MR; and

d) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT traversal on the incoming signalling path, or for legal interception),

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and that no MRs can be bypassed when no primary local MR is allocated.

4) If an indication that the allocation of a primary local MR is not required has been stored in steps 1) or 3),

– then the IMS-ALG shall compare the realm instances (and MRs) that can be bypassed with or without allocation of a primary local MR, as determined in steps 1), 2) and 3), and shall use local policy to select whether to allocate a primary local MR,

– else the IMS-ALG shall select to allocate a primary local MR,

NOTE: Usually the decision is made based on which choice retains the smallest total number of MRs in the media path, but local policy may apply other criteria.

5) If the IMS-ALG selected in step 4) to allocate a primary local MR, then the IMS-ALG shall:

– if one or more realm instances can be bypassed when allocating a primary local MR, then store instance-number value k=j and apply the procedures in clause 6.1.4 to bypass previous MRs, else apply the procedures in clause 6.1.5 to not bypass previous MRs; and

– apply the procedures in clause 6.1.6 to allocate a primary local MR.

6) If the IMS-ALG selected in step 4) to not allocate a primary local MR, then the IMS-ALG shall:

– if one or more realm instances can be bypassed when not allocating a primary local MR, then store instance-number value k=i and apply the procedures in clause 6.1.4 to bypass previous MRs, else apply the procedures in clause 6.1.5 to not bypass previous MRs; and

– apply the procedures in clause 6.1.7 to not allocate a primary local MR.

6.1.4 Bypassing previous MRs

If the IMS-ALG decides (applying the criteria in clauses 6.1.3, 6.2.2, 6.2.3 or 6.2.8) to bypass a previous MR, the IMS-ALG shall:

1) use the connection address and port information from the selected instance k for the media line in the received SDP offer as incoming connection address and incoming port information for the media line in the subsequent steps;

2) reconstruct the associated codec information for the media line in the received SDP offer from the selected instance k as described in clause 5.3, and use that codec information as incoming codec information in the subsequent steps; and

3) delete every OMR attribute for the media line with instance-number value higher than k.

6.1.5 Bypassing no previous MRs

If the IMS-ALG decides (applying the criteria in clauses 6.1.3, 6.2.2 or 6.2.3) not to bypass any previous MR, the IMS-ALG shall:

1) use the connection-address from the SDP c-line in the received SDP offer as incoming connection-address in subsequent steps;

2) use the port information from the SDP m-line in the received SDP offer as incoming port information in subsequent steps; and

3) use the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP offer as incoming codec information in the subsequent steps.

6.1.6 Allocating a primary local MR

If the IMS-ALG decides (applying the criteria in clauses 6.1.3 or 6.2.3) to allocate a local MR, the IMS-ALG shall:

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming connection address and port information determined in clause 6.1.4 or 6.1.5, and the outgoing signalling path, respectively applying procedures as described in clause 6.3;

2) if the IMS-ALG is not performing hosted NAPT traversal on the incoming side, then insert the incoming connection address and incoming port information for the media line, as determined in clause 6.1.4 or 6.1.5, into the remote connection address and port information for the incoming termination on the MR;

3) if the IMS-ALG is performing hosted NAPT traversal on the incoming side, then discover the remote connection address and port information for the incoming termination on the MR using latching or other unspecified technique;

4) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR the incoming codec information as determined in clause 6.1.4 or 6.1.5;

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related procedures in steps 1) to 4) until it processes the SDP answer.

5) if the IMS-ALG requires according to local policy that its MR remain in the media path for reasons unrelated to OMR, remove all OMR specific attributes from the modified SDP offer;

6) if there is no visited-realm instance associated with the connection address and port information for the media line in the received (and possibly modified) SDP offer, and there is no local policy prohibiting removal of the allocated MR, then construct and add this visited-realm instance to the modified SDP offer;

7) replace the connection address and port information for the media line in the modified SDP offer with the connection address and port information from the MR termination on the outgoing side;

8) make any codec changes to incoming codec information, as determined in clause 6.1.4 or 6.1.5, according to local policy, taking into account the procedures in clause 5.4, and insert the changed codec information into the SDP m-line and associated attribute lines of the modified SDP offer;

9) if codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR the modified codec information derived in step 8); and

10) add to the modified SDP offer a visited-realm instance for the IP realm associated with the connection address and port information for the media line in the modified SDP offer, including the incoming codec information encoded according to clause 5.2 if any codec changes were inserted in step 8).

6.1.7 Allocating no primary local MR

If the IMS-ALG decides (applying the criteria in clauses 6.1.3 or 6.2.2) not to allocate a primary local MR, the IMS-ALG shall:

1) decide according to local policy if the IMS-ALG performs any codec changes to the incoming codec information, as determined in clause 6.1.4 or 6.1.5, without allocating an MR (i.e., for proactive transcoding without resource reservation);

NOTE: The IMS-ALG can only make codec changes if the available SIP signalling allows the IMS-ALG to initiate a 2^nd SDP offer/answer transaction if necessary to allocate a transcoding MR after receipt of the SDP answer, as described in clause 6.2.3.

2) if the IMS-ALG decided in step 1) to perform any codec changes, then

a) if there is no visited-realm instance associated with the connection address and port information for the media line in the received SDP offer, then construct and add this visited-realm instance;

b) make the codec changes to incoming codec information according to local policy, taking into account the procedures in clause 5.4, and insert the changed codec information into the SDP m-line and associated attribute lines of the modified SDP offer; and

c) add to the modified SDP offer a visited-realm instance with the same IP realm, connection address and port information as the previous visited-realm instance (after a possible execution of step 3 in clause 6.1.4 for the media line, including the incoming codec information encoded according to clause 5.2),

3) if the IMS-ALG decided in step 1) not to perform any codec changes, then

a) insert the incoming codec information, determined in clause 6.1.4 or 6.1.5 into the SDP m-line and associated attribute lines of the modified SDP offer.

4) use the incoming connection address, determined in clause 6.1.4 or 6.1.5, as the connection address in the SDP c-line of the modified SDP offer; and

5) use the incoming port information as determined in previous steps as port information in the SDP m-line of the modified SDP offer.

6.1.8 Allocating secondary local MRs

According to local policy, the IMS-ALG may allocate a secondary MR for each combination of IP realm, nettype and addrtype on the outgoing side for which the IMS-ALG can allocate an MR context. However, if the IMS-ALG does not require a local MR for non-OMR reasons, the IMS ALG should only allocate a secondary MR for a combination of IP realm, nettype and addrtype if the IP realm, nettype and addrtype are not represented by a visited-realm or secondary-realm instance for the media line in the SDP offer. To allocate a secondary MR, the IMS-ALG shall:

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context for the IP realm, nettype and addrtype on the outgoing side, using the incoming connection address and incoming port information for the media line, determined in clause 6.1.4 or 6.1.5, as the remote connection address and port information for the incoming termination;

2) if codec information is to be provided to the allocated MR for the incoming termination, provide to the MR the incoming codec information, as determined in clause 6.1.4 or 6.1.5;

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related procedures in steps 1) and 2) until it processes the SDP answer.

3) if any codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR the codec information from the SDP m-line and associated attribute lines of the modified SDP offer;

4) if the IMS-ALG did not yet add a visited-realm instance for the outgoing side (the IMS-ALG did not allocate a primary MR and did not perform any codec changes, see clause 6.1.7); then

a) if there is no visited-realm instance associated with the connection address and port information for the media line in the received SDP offer, then construct and add this visited-realm instance; and

b) add to the SDP offer a visited-realm instance with the same IP realm, connection address and port information as the previous visited-realm instance (after a possible execution of step 3 in clause 6.1.4 for the media line),

5) add to the modified SDP offer a secondary-realm instance for the context allocated in step 1).

6.1.9 Forwarding SDP offer

The IMS-ALG shall:

1) if local policy forbids sending of OMR related attributes to the outgoing IP realm, the IMS-ALG shall delete all OMR related attributes from the modified SDP offer; and

2) if the IMS-ALG has made any modifications to the received SDP offer before forwarding and the modified SDP offer includes OMR related attributes, the IMS-ALG shall compute checksum values as described in clause 5.6.3 and replace or add the "omr-s-cksum" and "omr-m-cksum" attributes for the media line.

The IMS-ALG forwards the SDP offer according to TS 24.229 [4].

6.2 IMS-ALG handling of initial SDP answer

6.2.1 General

Upon receiving the initial or second SDP answer corresponding to the initial or second SDP offer sent in clause 6.1, the IMS-ALG supporting OMR shall perform the procedures in the following clauses for each media line in the initial or second SDP answer.

6.2.2 IMS-ALG bypasses an allocated transcoding MR

The IMS-ALG uses the following conditions to determine that a previously allocated primary local MR or upstream MR is to be bypassed and that a second SDP offer/answer transaction is needed to update the connection information on the outgoing side. Two examples of this procedure are given in Annex Q of TS 23.228 [3]: steps 5) and 6) of Figure Q.5, and steps 7) and 8) of Figure Q.7.

If the following conditions are true:

1) the received initial SDP answer includes connection address information for the media line that is a valid IP address other than the unspecified address (i.e., IPv4: “0.0.0.0”, IPv6: “invalid.invalid”); and

2) it is possible to immediately initiate a second SDP offer/answer transaction towards the initial SDP answerer with the available SIP signalling,

then the IMS-ALG should re-evaluate the conditions in clause 6.1.3, steps 1) to 4), taking into account the information from the originally received initial SDP offer, as well as the codecs received in the initial SDP answer as additional information (using the procedure in clause 5.5 if the initial SDP answer includes an actual configuration), to select again whether to allocate a primary local MR and to recompute how many realm instances can be bypassed. The IMS-ALG should select to modify the previous decision if a higher number of realm instances can be bypassed.

If the IMS-ALG selected in the previous step to modify the previous decision and

– to not allocate a primary local MR that has previously been allocated; or

– to not allocate a primary local MR and to bypass other previous realm instances than decided when previously evaluating clause 6.1.3,

then the IMS-ALG shall:

1) apply the procedures in clause 6.1.4 to bypass previous MRs or the procedures in clause 6.1.5 to not bypass previous MRs (using information from the originally received initial SDP offer), depending on its corresponding decision;

2) apply the procedures in clause 6.1.7 to not allocate a primary local MR without making any codec changes;

3) after clauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in clause 6.1.9 for each media line to send a second SDP offer within available SIP signalling, initiating a new second SDP offer/answer transaction towards the initial SDP answerer; and

4) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the initial SDP answer, and reference the most recent data associated with the forwarding of the (modified) second SDP offer (i.e., incoming SDP information, allocated MRs and modified second SDP offer) as if it occurred the first time.

6.2.3 IMS-ALG allocates a local transcoding MR when performing proactive transcoding without resource reservation

The IMS-ALG uses the procedures in this clause if it receives an initial SDP answer without a realm instance, performed proactive transcoding without resource reservation when forwarding the initial SDP offer, as in step 2) of clause 6.1.7, and then determines that it needs to allocate an MR for proactive transcoding.

If all the following conditions are true:

2) the IMS-ALG performed proactive transcoding without resource reservation when previously forwarding the initial SDP offer, as in step 2) of clause 6.1.7;

3) the selected codec in the received initial SDP answer is not supported by the incoming media path and incoming codec information, as previously determined in clause 6.1.4 or 6.1.5 (using information from the originally received initial SDP offer), indicating that an MR must be allocated to provide transcoding; and

4) it is possible to immediately initiate a second SDP offer/answer transaction towards the SDP answerer with the available SIP signalling,

NOTE: If a second SDP offer/answer transaction cannot be initiated with available SIP signalling, the OMR algorithm will fail to allocate a functioning end-to-end media path.

then the IMS-ALG shall:

1) if when previously handling the initial SDP offer it was determined in step 2) of clause 6.1.3 that one or more realm instances can be bypassed when allocating a primary local MR (using information from the originally received initial SDP offer), then store instance-number value k=j and apply the procedures in clause 6.1.4 to bypass previous MRs, else apply the procedures in clause 6.1.5 to not bypass previous MRs (using information from the originally received initial SDP offer);

2) apply the procedures in clause 6.1.6 to allocate a primary local MR;

3) apply the procedures in clause 6.1.8 to update allocation of any secondary MRs, if necessary;

4) after clauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in clause 6.1.9 for each media line, to send a second SDP offer within available SIP signalling, and to initiate a new SDP offer/answer transaction towards the initial SDP answerer; and

5) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the initial SDP answer, and reference the most recent data associated with the forwarding of the (modified) second SDP offer (i.e., incoming information, allocated MRs and modified second SDP offer) as if it occurred the first time.

6.2.4 IMS-ALG determines steps required to complete the handling of the SDP answer

The IMS-ALG performs the following steps to determine the disposition of any allocated MRs and to complete the handling of the SDP answer:

1) if the received SDP answer for the media line includes a connection address with unspecified address and a visited-realm instance, then the IMS-ALG shall apply the procedures in clause 6.2.5;

2) if the received SDP answer for the media line includes a connection address with unspecified address and a secondary-realm instance, then the IMS-ALG shall apply the procedures in clause 6.2.6;

2a) If the received SDP answer for the media line includes a connection address with unspecified address and no visited-realm or secondary-realm instance, then the IMS-ALG shall:

a) if necessary, update the unspecified 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");

3) if all the following conditions are true:

a) the connection address for the media line in the received SDP answer is a valid (not unspecified) address; and

b) the IMS-ALG did not allocate a primary local MR (i.e., executed clause 6.1.7) when forwarding the SDP offer,

then the IMS-ALG shall apply the procedures in clause 6.2.7, and

4) if all the following conditions are true:

a) the connection address for the media line in the received SDP answer is a valid (not unspecified) address; and

b) the IMS-ALG allocated a primary local MR (i.e., executed clause 6.1.6) when forwarding the SDP offer,

then the IMS-ALG shall apply the procedures in clause 6.2.8 to retain a primary local MR.

6.2.5 Receiving an unspecified connection address and a visited-realm instance

If the IMS-ALG receives a connection address with unspecified address and a visited-realm instance, then the IMS-ALG shall:

1) If the visited-realm instance for the media line in the SDP answer has an instance-number that matches the visited-realm instance associated with the incoming SDP offer information,

NOTE 1: The visited-realm instance associated with the incoming SDP offer information is either the one in the received SDP offer with highest instance-number (before any bypass decision is made), if one is present, or the one added in clause 6.1.6 step 6) or in clause 6.1.7 step 2a).

NOTE 2: The IP realms in the two visited-realm instances either have the same name or are connected.

then the IMS-ALG shall:

– replace the connection address and port information for the media line in the SDP answer with the connection address and port information from the visited-realm instance in the received SDP answer, and

– retain the visited-realm instance in the SDP answer,

2) else the IMS-ALG shall:

– if necessary, update the unspecified 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").

6.2.6 Receiving an unspecified connection address and a secondary-realm instance

If the IMS-ALG receives a connection address with unspecified address and a secondary-realm instance, then the IMS-ALG shall:

1) if the secondary-realm instance for the media line in the SDP answer has an instance-number that matches a secondary-realm instance added by the IMS-ALG when applying procedures in clause 6.1.8 then the IMS-ALG shall apply the procedures in clause 6.2.8 to retain a secondary local MR,

NOTE: The IP realms in the two secondary-realm instances either have the same name or are connected.

2) else the IMS-ALG shall:

6.2.7 Other handling when no primary local MR allocated

If the IMS-ALG receives (as determined in clause 6.2.4) an SDP answer with a valid connection address after forwarding an SDP offer without allocating a primary local MR, then the IMS-ALG shall:

1) If the IMS-ALG applied clause 6.1.4 to bypass previous MRs when handling the forwarding of the SDP offer, then the IMS-ALG shall:

a) copy into the media line of the SDP answer the visited-realm or secondary-realm instance from the media line of the received SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, replacing the connection-address and port information in the instance with the connection address and port information from the received SDP answer, 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

b) 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"),

2) else the IMS-ALG did not bypass previous MRs when forwarding the SDP offer and the IMS-ALG shall not modify the SDP answer.

NOTE: In step 1) the received SDP answer never includes a realm instance. In step 2) the SDP answer can but does not necessarily include a realm instance.

6.2.8 Retaining a primary or secondary local MR

If the IMS-ALG decides (applying the criteria in clause 6.2.4 and clause 6.2.6) to retain a primary or secondary local MR, the IMS-ALG shall:

1) if the IMS-ALG received an SDP answer with no secondary-realm instance for the media line, then the IMS-ALG shall:

NOTE: The IMS-ALG retains a primary local MR in this case. The IMS-ALG can but does not necessarily receive a visited-realm instance in an SDP answer when retaining a primary local MR. If present, the visited-realm instance can be used to identify the connected IP realm for the outgoing termination, if different from the IP realm of the outgoing termination.

a) update the remote connection address and port information for the outgoing termination on the selected primary local MR context with the connection address and port information for the media line in the received SDP answer,

b) delete the visited-realm instance from the SDP answer, if present,

2) if the IMS-ALG received an SDP answer with a secondary-realm instance for the media line,

then the IMS-ALG shall:

a) update the remote connection address and port information for the outgoing termination on the selected secondary local MR context with the connection-address and port information from the secondary-realm instance in the received SDP answer; and

b) delete the secondary-realm instance from the SDP answer,

3) if the selected codecs in the SDP answer are not in the set of codecs associated with the incoming SDP offer information, as determined in clause 6.1.4 or 6.1.5 when handling the SDP offer, then modify the SDP answer to include the codecs selected for the incoming termination of the selected local MR;

4) if the selected MR has access to an IP realm or connected IP realm, nettype and addrtype associated with a visited-realm or secondary-realm instance for the media line

– such that the instance has an instance-number value k that is less than the highest instance-number value n associated with the media line in the incoming SDP offer information, previously determined in clause 6.1.4 or 6.1.5; and

– such that the instance k is associated with a codec list, determined using the procedures in clause 5.3, which includes the codecs selected for the incoming termination of the selected local MR in step 3) (using the procedure in clause 5.5 if the SDP answer includes an actual configuration),

then the IMS-ALG shall:

a) store the realm instances with instance-number greater than k, which are associated with additional MRs that can be bypassed after selecting a codec for the incoming media path when allocating a primary local MR;

b) apply the procedures in clause 6.1.4 to bypass additional previous MRs (using information from the originally received SDP offer);

c) insert the incoming connection address and incoming port information for the media line, as determined in step b), as the remote connection address and port information for the selected IP realm on the incoming termination of the selected MR;

d) if necessary, modify the selected codec information in the SDP answer to be a valid response to the incoming SDP offer codec information determined in step b);

e) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR the incoming codec information as determined in step d),

5) If the IMS-ALG applied clause 6.1.4 to bypass previous MRs when forwarding the SDP offer or in step 4b), then the IMS-ALG shall:

a) copy into the media line of the SDP answer the visited-realm or secondary-realm instance from the media line of the received SDP offer that was used for the remote connection address and port information for the incoming termination on the MR, replacing the connection-address and port information in the instance with the local connection address and port information for the incoming termination on the selected MR, 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

6) If the IMS-ALG applied clause 6.1.5 to not bypass previous MRs when forwarding the SDP offer, and did not bypass previous MRs in step 4b), then the IMS-ALG shall:

a) replace the connection address and port information for the media line in the SDP answer with the local connection address and port information for the incoming termination on the selected MR.

6.2.9 Forwarding the SDP answer

The IMS-ALG forwards the SDP answer according to TS 24.229 [4].

The IMS-ALG shall release each MR for the media line, when it is no longer potentially needed for this and any other forked dialog.

6.3 IMS-ALG OMR media resource operations

6.3.1 General

The IMS-ALG OMR procedures as specified by clauses 6.1 and 6.2 refer to generic MR allocation operation. When no MR was previously allocated, e.g. during the initial SDP offer/answer exchange, this allocation will result in the allocation of one or more local media termination point pairs (ingress and egress) – one for the primary IP realm and possible additional terminations points for secondary IP realms.

Subsequent SDP offer/answer exchanges may result in the decision that a local MR is needed. If a local MR was not previously allocated, then one will now be allocated. If a local MR was previously allocated that matches the resource information needed, then the previously allocated resource 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.

If it is determined that local MR may be by-passed or no longer needed, then any previously allocated local MRs will be deallocated.

6.3.2 IMS-ALG operations

The OMR MR procedures in this document are applicable to the following IMS entities that perform as IMS-ALG using the media resource interface operations as indicated.

– An IBCF acting as an IMS-ALG controlling a TrGW using the Ix interface as defined by TS 29.162 [16] and TS 29.238 [9]:

– Reserve TrGW Connection Point;

– Configure TrGW Connection Point,

– Reserve and Configure TrGW Connection Point; and

– Release TrGW Connection Point.

– A P-CSCF acting as IMS-ALG controlling an IMS-AGW using the Iq interface as defined by TS 23.334 [15] and TS 29.334 [10]:

– Reserve AGW Connection Point;

– Configure AGW Connection Point;

– Reserve and Configure AGW Connection Point; and

– Release AGW Connection Point.

– An AS acting as B2BUA and adapting IMS-ALG procedures to control an MRF shall use one or more of the following:

– IETF RFC 4240 [11] conference service;

– IETF RFC 4117 [19]; and

– IETF RFC 3260 [12] and IETF RFC 6505 [13].

6.4 Handling of connected IP realms

For each IP realm to which a controlled MR has direct access, the IMS-ALG supporting OMR may be provisioned with a list of the names of connected IP realms, if any. The IMS-ALG 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.