Q.2 Procedures and flows

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

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

Q.2.1 SDP extension

Each OMR-capable entity on the signalling path of an SDP offer/answer transaction shall be able to manipulate an SDP offer to describe the following information about the IP realm associated with each known media path segment for each media line:

– a unique name for the IP realm on the subsequent media path segment,

– the position of the IP realm instance in the media path,

– connection/port data for the corresponding media resource in the IP realm on the subsequent media path segment,

– sufficient information to reconstruct the codec list for the previous media path segment if the codec list has changed (e.g. to offer transcoding options).

Each instance of such information is called an IP realm instance. Each IP realm instance associated with a media line in an SDP offer is a visited realm instance. If a signalling entity on the path controls a media resource with connection to an alternate IP realm not already associated with a media line, the SDP may also include the same information about the alternate IP realm, called a secondary realm instance.

An OMR-capable entity that forwards an SDP offer with OMR specific attributes for a media line shall ensure that the forwarded SDP offer includes a visited realm instance that matches the connection information for the media line in the forwarded SDP offer. This SDP offer shall also include information that makes it possible for a subsequent OMR-capable entity to detect if an intermediate entity has changed any codec information for the media line without also changing the connection and port information for the media line.

To bypass one or more previous TrGWs for a media line, an IMS-ALG shall include an IP realm instance with valid connection information for the earliest acceptable IP realm in the forwarded SDP answer. It shall be possible to identify the visited or secondary realm instance from the SDP offer that corresponds to the IP realm instance in the SDP answer.

Globally reachable IPv6 addresses shall be associated with a reserved realm name to assure that networks are not artificially isolated. Globally reachable IPv4 addresses shall be associated with another reserved realm name. Networks with private or restricted reachability shall have unique realm names.

Q.2.2 General IMS-ALG procedures

IMS-ALGs supporting OMR shall be able to support the call flows in clauses Q.2.4 and Q.2.5 according to local policy. These call flows describe the simplest scenarios and should be treated as examples. It shall be possible to support the addition of IMS-ALGs and TrGWs in any flow between any of the entities shown whenever such additions are reasonable. It shall be possible to support any interconnection of these flows whenever it is reasonable to do so. Additional information can be present in the forwarded SDP messages to support these more complex scenarios.

The following high level procedures apply to all of the scenarios.

Upon receiving an initial SDP offer, the IMS-ALG in the signalling path shall perform the following for each media line:

– If the SDP offer includes realm instance information for the media line, and the latest visited realm instance is not for the connection information in the incoming SDP offer, then the IMS-ALG shall remove all OMR specific SDP attributes from the SDP offer.

NOTE: A non-OMR-capable IMS-ALG might have inserted a TrGW without removing unrecognized OMR specific SDP attributes.

– If the SDP offer includes realm instance information that corresponds to the connection information in the incoming SDP offer, then the IMS-ALG shall attempt to verify that no intermediate entity has changed the codec information in the SDP offer since it was generated by the previous OMR-capable entity. If the IMS-ALG cannot verify that the codec information is unchanged, it shall remove all OMR specific SDP attributes from the SDP offer.

– Determine according to local policy if a TrGW is required in the user plane path for a purpose unrelated to transcoding or NAT, e.g., lawful intercept. Visited realm and secondary realm instances for previous user plane segments shall be removed to prevent subsequent signalling entities from bypassing the media resource.

– Based on the outgoing IP realm, IP realm accessibility from controlled TrGWs, and information from visited realm and secondary realm instances in the received SDP offer, the IMS-ALG shall determine whether to allocate a TrGW and whether one or more previous TrGWs can be bypassed. If transcoding is also supported, the IMS-ALG may also consider whether to modify the codec set, move the transcoding point, and which transcoding procedure to apply, if any.

– Allocate a TrGW and transcoder as necessary. If the IMS-ALG allocates a transcoder, it shall include information about the transcoding options in the visited realm instance for the outgoing realm.

– Optionally allocate one or more secondary TrGWs according to local policy.

– Forward the SDP offer after modifying the connection, port, codec, visited realm instances, and secondary realm instances as appropriate. If the IMS-ALG added a TrGW it shall:

– Add a visited realm instance with the connection/port and IP realm on the the previous media path segment if no visited realm instances have been received and local policy allows potential bypass of the TrGW by subsequent entities.

– Add a visited realm instance with the connection/port and IP realm on the the subsequent media path segment.

Upon receiving an initial SDP answer, the IMS-ALG in the signalling path shall perform the following for each media line:

– Based on the selected codec, connection information and IP realm instances in the SDP answer, and information from the received SDP offer, the IMS-ALG shall determine whether to deallocate any TrGW(s) and whether a second SDP offer/answer transaction is needed to send updated connection information towards the SDP answerer.

– Initiate and complete the second SDP offer/answer transaction if required.

– Determine how to modify the forwarded SDP answer to signal the bypass of previous TrGWs/transcoders, if any.

– Deallocate any unused TrGW/transcoder as necessary.

– Forward the modified SDP answer to signal other TrGW bypass decisions.

The end-to-end user plane path selected via the OMR procedures during the initial SDP offer-answer exchange should not be modified by subsequent SDP offer-answer exchanges, unless the new SDP offer-answer exchanges requires a new media path (e.g. transcoding, adding media, playing announcements).

NOTE: If the media path is changed, there is a risk of speech gaps and/or media drops during the media path switch.

Q.2.3 Common flows

Q.2.3.1 IMS-ALG allocates a TrGW

When an IMS-ALG allocates a TrGW during forwarding of an SDP offer without performing any media optimisations and is not bypassed during subsequent processing of the SDP answer, OMR has no impact on the standard call flow except for the addition of some SDP extension information to the SDP messages.

If an IMS-ALG does not support OMR then it will treat all OMR extension attributes as unrecognized SDP information.

If an IMS-ALG that does not support OMR inserts a TrGW in the media path and removes unrecognized OMR attributes from the SDP before forwarding, then the IMS-ALG will remove any OMR extension attributes from the forwarded SDP, thus effectively anchoring its TrGW in the media path and preventing further optimisation of the user plane segment prior to this point.

If an IMS-ALG that does not support OMR inserts a TrGW in the path without removing unrecognized OMR attributes, then the subsequent OMR-capable entity in the signalling path shall remove OMR extension attributes from the SDP offer before handling.

Q.2.3.2 IMS-ALG does not allocate a TrGW

When an IMS-ALG does not allocate a TrGW during forwarding of an SDP offer and does not perform any media optimisations during processing of either the SDP offer or SDP answer, it transparently passes any SDP extensions for OMR in forwarded SDP messages. OMR has no impact on the standard call flow except for the addition of some SDP extension information to the SDP messages.

If an IMS-ALG that does not support OMR and does not allocate a TrGW upon receipt of an SDP offer transparently forwards the SDP offer, including unrecognized SDP attributes related to OMR, then it is possible for other OMR-compliant IMS-ALGs to perform user plane optimisations.

If an IMS-ALG that does not support OMR and does not allocate a TrGW upon receipt of an SDP offer removes unrecognized SDP attributes from the forwarded SDP offer, then further optimisation of the user plane segment prior to this point is not possible.

Q.2.3.3 IMS-ALG bypasses its TrGW and one or more prior TrGWs

Figure Q.1 applies when an IMS-ALG (IMS-ALG2) recognizes that it can avoid allocating a TrGW because an address for the outgoing IP realm is already available from a previous user plane segment. Thus it can bypass its own TrGW and one or more prior TrGWs. A common application of this scenario is when realm R1 is the internet and realm R2 is a private network isolated by the two IMS-ALGs. If no media resources are required within the network of realm R2 then there is no need to allocate TrGWs. IMS-ALG1 must initially allocate a TrGW since it does not know the ultimate destination of the SDP offer.

NOTE: Realm instances shown in italics in this and subsequent figures indicate their optionality. For example, an SDP offer from a UE will contain no realm instances.

Figure Q.1: IMS-ALG bypasses its TrGW and one or more prior TrGWs

1. IMS-ALG1 receives an SDP offer from realm R1. The SDP offer can include IP realm instances Rx associated with prior user plane segments and can include a visited realm instance for incoming realm R1. If realm instances are included in the received SDP offer, the IMS-ALG1 (and subsequent IMS-ALGs) verify that intermediate signalling entities have not modified the SDP.

2. IMS-ALG1 allocates TrGW1 to provide a NAT between R1 and R2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both the incoming and outgoing realms. IMS-ALG1 creates a new visited realm instance for the incoming realm if it was not present in the received SDP offer.

4. Since an IP address already exists within a visited realm instance for the outgoing realm R1, the IMS-ALG2 can avoid allocating a TrGW and can bypass a previous TrGW1.

5. IMS-ALG2 forwards connection information from the SDP offer in step 1 (IP1), which is valid in the outgoing realm R1. The forwarded SDP offer retains those IP realm instances that remain connected to the media path.

6. IMS-ALG2 receives an SDP answer with valid connection information (IP3) in realm R1.

7. IMS-ALG2 forwards the SDP answer to IMS-ALG1 after including an IP realm instance for the connection information from the SDP answer in step 6. The IP realm instance in the SDP answer identifies a corresponding realm instance from the SDP offer associated with the same IP realm, thus uniquely identifying the TrGWs to be bypassed. The connection information in the forwarded SDP answer cannot be used by the receiving IMS-ALG to establish this segment of the media path.

8. IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.

9. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP realm instance received in step 7.

10. A user plane connection is now established in realm R1 without the need to allocate any additional TrGWs.

Q.2.3.4 IMS-ALG bypasses its TrGW using secondary realm from prior IMS-ALG

Figure Q.2 applies when an IMS-ALG (IMS-ALG2) recognizes that it can avoid allocating a TrGW by using a secondary realm instance from a prior IMS-ALG.

Figure Q.2: IMS-ALG bypasses its TrGW using secondary realm from prior IMS-ALG

2. IMS-ALG1 allocates TrGW1 to provide a NAT between R1 and R2. IMS-ALG1 also allocates TrGW2 to provide a NAT between R1 and alternate realm R3.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx, visited realm instances for both the incoming and outgoing realms R1 and R2, and a secondary realm instance for realm R3.

4. Since an IP address already exists within a secondary realm instance for the outgoing realm R3, the IMS-ALG2 can avoid allocating a TrGW.

5. IMS-ALG2 forwards the SDP offer with connection information from the secondary realm instance received in step 3 (IP3), which is valid in the outgoing realm R3. The forwarded SDP offer retains those IP realm instances that remain connected to the media path.

6. IMS-ALG2 receives an SDP answer with valid connection information (IP4) in realm R3.

7. IMS-ALG2 forwards the SDP answer to IMS-ALG1 after including an IP realm instance for the connection information from the SDP answer in step 6. The connection information in the forwarded SDP answer cannot be used by the receiving IMS-ALG to establish this segment of the media path.

8. IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2. IMS-ALG1 retains TrGW2 to maintain the user plane connection via R3.

9. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.

10. A user plane connection is now established with one segment in realm R1 and a second segment in realm R3, mediated by TrGW2.

Q.2.3.5 IMS-ALG bypasses one or more prior TrGWs using a secondary realm

Figure Q.3 applies when an IMS-ALG (IMS-ALG2) determines that it must allocate a TrGW under its control but can bypass previously allocated TrGWs by allocating a TrGW with access to an alternate realm (not the incoming one) associated with an earlier user plane segment.

Figure Q.3: IMS-ALG bypasses one or more prior TrGWs using a secondary realm

2. IMS-ALG1 allocates TrGW1 to provide a NAT between R1 and R2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both the incoming and outgoing realms.

4. If IMS-ALG2 controls a TrGW (TrGW2) with access to realm R1, then IMS-ALG2 can use the visited realm instance for R1 to establish the incoming user plane segment, rather than using the connection information for TrGW1 from the received SDP offer in step 3. IMS-ALG2 allocates TrGW2 to provide a NAT between alternate realm R1 and realm R3.

5. IMS-ALG2 forwards the SDP offer with connection information for TrGW2 in realm R3 along with IP realm instances Rx and the visited realm instances for R1 and R3.

6. IMS-ALG2 receives an SDP answer with valid connection information (IP4) in realm R3.

7. IMS-ALG2 forwards the SDP answer to IMS-ALG1 after including an IP realm instance for the TrGW2 address in realm R1. The connection information in the forwarded SDP answer cannot be used by the receiving IMS-ALG to establish this segment of the media path.

8. IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.

9. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.

10. A user plane connection is now established with one segment in realm R1 and a second segment in realm R3, mediated by TrGW2.

Q.2.3.6 IMS-ALG bypasses TrGWs performing NAT traversal

Figure Q.4 applies when an IMS-ALG (IMS-ALG2) that is performing NAT traversal for a terminating UA recognizes that the offering UA is in the same private realm behind a NAT, so that all TrGWs can be bypassed and a direct user plane connection established between the endpoints.

Figure Q.4: IMS-ALG bypasses TrGWs performing NAT traversal

1. IMS-ALG1 receives an SDP offer from UA1 in private realm R1 behind a NAT.

2. IMS-ALG1 allocates TrGW1 to provide NAT traversal between private realm R1 and realm R2. TrGW1 can only be bypassed if the answering UA2 is in the same private realm R1.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with visited realm instances for the private realm R1 for UA1, and the outgoing realm R2.

4. Since an IP address already exists within the visited realm instance for the private realm R1 for UA2, the IMS-ALG2 can avoid allocating a TrGW and can bypass a previous TrGW1.

5. IMS-ALG2 forwards connection information from the SDP offer in step 1 (IP1), which is valid in the outgoing private realm R1 behind the NAT.

6. IMS-ALG2 receives an SDP answer with valid connection information (IP3) in realm R1.

8. IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.

9. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP realm instance received in step 7.

10. A user plane connection is now established in realm R1 without the need to allocate any TrGWs.

Q.2.5 Flows with transcoding

Q.2.5.1 Proactive transcoding where transcoding is required

When an IMS-ALG supporting OMR allocates a TrGW during forwarding of the SDP offer for proactive transcoding with resource reservation, if subsequent IMS-ALGs do not replace the transcoder and the answering side signals in the SDP answer that transcoding is required, then the IMS-ALG retains the TrGW for transcoding and anchors it in the user plane path. The call flow is the same as the usual call flow for TrGW insertion except for the addition of some SDP extension information to the SDP messages.

Q.2.5.2 Proactive transcoding where transcoding not required

Figure Q.5 applies when IMS-ALG1 allocates a TrGW during forwarding of the SDP offer for proactive transcoding with resource reservation, IMS-ALG1 is the last signalling entity on the path before UA2, and UA2 signals in the SDP answer that transcoding is not required. UA2 ignores unrecognized OMR extension attributes.

A second SDP offer/answer transaction is required to remove the transcoder from the path.

As an alternative to the procedure shown, the IMS-ALG1 may forward connection information for a prior user plane segment without transcoding options while including an IP realm instance for the transcoding TrGW. This alternative avoids a second SDP offer/answer transaction if transcoding is not required, but does include a second SDP offer/answer transaction if transcoding is required.

NOTE: Realm instances shown in bold in this and subsequent figures include codec change information.

Figure Q.5: Proactive transcoding where transcoding not required

1. IMS-ALG1 receives an SDP offer from realm R1. The SDP offer can include IP realm instances Rx associated with prior user plane segments and can include a visited realm instance for incoming realm R1. The realm instances in this and other messages in the figure are shown in italics to indicate their optionality. For example, an SDP offer from a UE will contain no realm instances. If realm instances are included in the received SDP offer, the IMS-ALG1 (and subsequent IMS-ALGs) verify that intermediate signalling entities have not modified the SDP.

2. IMS-ALG1 allocates TrGW1 to offer transcoding options to UA2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both its incoming and outgoing user plane segments. IMS-ALG1 creates a new visited realm instance for the incoming realm if it was not present in the received SDP offer. The visited realm instance for the outgoing side includes information about the codec changes associated with TrGW1.

4. UA2 selects one of the original codecs, i.e., transcoding is not needed. In response to the SDP offer, UA2 sends an SDP answer to IMS-ALG1 with connection information for its address in realm R1.

5. IMS-ALG1 determines that the transcoder is not needed and forwards a second SDP offer to UA2 with connection information from a prior realm. This SDP offer includes those IP realm instances that remain options without transcoding.

6. UA2 updates its remote connection information and responds with a new SDP answer.

7. IMS-ALG1 de-allocates TrGW1.

8. IMS-ALG1 forwards the SDP answer with connection information for UA2 in realm R1.

9. A user plane connection is now established in realm R1 without use of any TrGWs.

Q.2.5.3 IMS-ALG bypasses prior unrequired proactive transcoder

Figure Q.6 applies when IMS-ALG1 allocates a TrGW during forwarding of the SDP offer for proactive transcoding with resource reservation, another IMS-ALG (IMS-ALG2) is the last signalling entity on the path before UA2, IMS-ALG2 must allocate a TrGW to provide NAT, and UA2 signals in the SDP answer that transcoding is not required. There may be additional IMS-ALGs between IMS-ALG1 and IMS-ALG2.

This scenario avoids the need for a second SDP offer/answer transaction as required in clause Q.2.5.3 and clause Q.2.5.5. IMS-ALG2 signals to IMS-ALG1 in the SDP answer to bypass the transcoder.

Figure Q.6: IMS-ALG bypasses prior unrequired proactive transcoder

2. IMS-ALG1 allocates TrGW1 to offer transcoding options to UA2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both its incoming and outgoing user plane segments. The visited realm instance for the outgoing side includes information about the codec changes associated with TrGW1.

4. IMS-ALG2 allocates TrGW2 to provide a NAT between R1 and R2.

5. IMS-ALG2 forwards the SDP offer with connection information for TrGW2 in realm R2 along with IP realm instances for prior user plane segments.

6. UA2 selects one of the original codecs, i.e., transcoding is not needed. In response to the SDP offer, UA2 sends an SDP answer to IMS-ALG2 with connection information for its address in realm R2.

7. IMS-ALG2 determines that transcoding is not necessary.

8. IMS-ALG2 forwards the SDP answer to IMS-ALG1 after including an IP realm instance for the TrGW2 address in realm R1. The connection information in the forwarded SDP answer cannot be used by the receiving IMS-ALG to establish this segment of the media path.

9. IMS-ALG1 de-allocates transcoder TrGW1 since there is no valid connection information available in the SDP answer.

10. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.

11. A user plane connection is now established with one segment in realm R1 and a second segment in realm R2, mediated by TrGW2.

Q.2.5.4 IMS-ALG bypasses its TrGW and prior unrequired proactive transcoder

Figure Q.7 applies when IMS-ALG1 allocates a TrGW during forwarding of the SDP offer for proactive transcoding with resource reservation, another IMS-ALG (IMS-ALG2) is the last signalling entity on the path before UA2, IMS-ALG2 does not need to allocate a TrGW to provide NAT, and UA2 signals in the SDP answer that transcoding is not required. There may be additional IMS-ALGs between IMS-ALG1 and IMS-ALG2.

A second SDP offer/answer transaction is required to remove the transcoder from the path. The scenario allows IMS-ALG2 to initiate the second SDP offer/answer transaction rather than requiring IMS-ALG1 to do this, thus saving some messaging.

Figure Q.7: IMS-ALG bypasses its TrGW and prior unrequired proactive transcoder

2. IMS-ALG1 allocates TrGW1 to offer transcoding options to UA2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both its incoming and outgoing user plane segments. The visited realm instance for the outgoing side includes information about the codec changes associated with TrGW1.

4. IMS-ALG2 does not allocate a TrGW since its incoming and outgoing realms are compatible.

5. IMS-ALG2 forwards the SDP offer with no changes.

6. UA2 selects one of the original codecs, i.e., transcoding is not needed. In response to the SDP offer, UA2 sends an SDP answer to IMS-ALG2 with connection information for its address in realm R1.

7. IMS-ALG2 determines that transcoding is not necessary and sends a second SDP offer with the connection information from the visited realm instance for a prior user plane segment. This SDP offer includes those IP realm instances that remain options without transcoding.

8. UA2 updates its remote connection information and responds with a new SDP answer.

9. IMS-ALG2 determines that the prior transcoder is to be bypassed.

10. IMS-ALG2 forwards the SDP answer to IMS-ALG1 after including an IP realm instance for the UA2 address in realm R1. The connection information in the forwarded SDP answer cannot be used by the receiving IMS-ALG to establish this segment of the media path.

11. IMS-ALG1 de-allocates transcoder TrGW1 since there is no valid connection information available in the SDP answer.

12. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of UA2 in realm R1.

13. A user plane connection is now established in realm R1.

Q.2.5.5 IMS-ALG replaces prior proactive transcoder

Figure Q.8 applies when IMS-ALG1 allocates a TrGW during forwarding of the SDP offer for proactive transcoding with resource reservation, and a later IMS-ALG (IMS-ALG2) chooses to bypass the transcoding offered by IMS-ALG1 and optionally offer its own transcoding options. There may be additional IMS-ALGs between IMS-ALG1 and IMS-ALG2.

The flow assumes that TrGW2 must remain to providing transcoding or NAT. The call flow variant if TrGW2 is not needed can be derived by combining this flow with one of the other transcoding flows.

An IMS-ALG may remove codec options, or re-instate codec options removed by a previous IMS-ALG by bypassing that IMS-ALG’s TrGW if allocated. The call flow continues to apply except that TrGW allocation is optional.

Figure Q.8: IMS-ALG replaces prior proactive transcoder

2. IMS-ALG1 allocates TrGW1 to offer transcoding options to UA2.

3. IMS-ALG1 forwards connection information for TrGW1 in the SDP offer along with prior IP realm instance information Rx and visited realm instances for both its incoming and outgoing user plane segments. The visited realm instance for the outgoing side includes information about the codec changes associated with TrGW1.

4. IMS-ALG2 bypasses the prior transcoder and allocates TrGW2 to provide alternate transcoding options to UA2.

5. IMS-ALG2 forwards the SDP offer with connection information for TrGW2 in realm R2 along with IP realm instances associated with all user plane segments. The forwarded SDP offer includes information about all potential transcoders so that a subsequent entity has the option to choose the earlier one if appropriate.

6. IMS-ALG2 receives an SDP answer with connection information for a valid address in realm R2.

8. IMS-ALG1 de-allocates transcoder TrGW1 since there is no valid connection information available in the SDP answer.

9. IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.

10. A user plane connection is now established with one segment in realm R1 and a second segment in realm R2, mediated by TrGW2.

Q.2.5.6 Proactive transcoding without resource reservation

An IMS-ALG performing proactive transcoding without resource reservation provides an indication in the forwarded SDP that an address is unavailable if transcoding is selected. Subsequent IMS-ALGs can replace this transcoder when forwarding the SDP offer according to the procedure in clause Q.2.5.6, but cannot insert a transcoding TrGW on behalf of the IMS-ALG performing proactive transcoding if needed. Thus the procedures in clause Q.2.5.4 and clause Q.2.5.5 do not apply. If transcoding is required, the IMS-ALG performs a procedure very similar to clause Q.2.5.3 to allocate the transcoding TrGW and signal its address to the answering side.

Q.2.5.7 Reactive transcoding

An IMS-ALG performing reactive transcoding follows all OMR procedures when forwarding the initial SDP offer but does not allocate a transcoder. If the initial SDP offer is rejected due to lack of support for an offered codec, the IMS-ALG performing reactive transcoding will restart the OMR procedure with the answering side after allocating and anchoring a TrGW with transcoding. The IMS-ALG removes all prior visited realm and secondary realm instances from the SDP offer before forwarding.