Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.228  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9… 
Q Optimal media routing  Q.1 General  Q.2 Procedures and flows  Q.2.1 SDP extension  Q.2.2 General IMS-ALG procedures  Q.2.3 Common flows  Q.2.3.1 IMS-ALG allocates a TrGW  Q.2.3.2 IMS-ALG does not allocate a TrGW  Q.2.3.3 IMS-ALG bypasses its TrGW and one or more prior TrGWs  Q.2.3.4 IMS-ALG bypasses its TrGW using secondary realm from prior IMS-ALG  Q.2.3.5 IMS-ALG bypasses one or more prior TrGWs using a secondary realm  Q.2.3.6 IMS-ALG bypasses TrGWs performing NAT traversal 
...

 

Q (Normative)  Optimal media routing |R10|  p. 281

Q.1  General  p. 281

The purpose of optimal media routing (OMR) is to identify and remove unnecessary media functions from the media path for each media stream associated with a session.
The IP Multimedia Subsystem has the option to deploy media functions such as TrGWs on the media path associated with each media stream associated with a session. These media functions can perform only transport level functions such as firewall or NAT, or can also perform application level functions such as transcoding or conferencing. These media functions are typically allocated proactively during SDP offer/answer signalling within a session since it is unknown which of the functions are actually needed for a media stream until the SDP offer/answer signalling completes. For example, a transcoder can be allocated during session establishment but whether transcoding is needed is determined once the SDP offer reaches the far endpoint. In another example, the IBCFs at the boundary of a network allocate TrGWs to protect media functions within the network or to provide address translation to the private address space used within the network, however it might be determined later during session establishment that no media resources are needed within the network, thus making the TrGWs unnecessary.
Any SIP signalling entity within the IMS network that allocates, to a session flow, a media function that might later be determined to be unnecessary may implement the procedures in this Annex to assist in the removal of unnecessary media functions. In particular, any entity with an IMS-ALG may implement the OMR algorithm. This includes the IBCF (see Annex I) and P-CSCF (see Annex G). Any AS performing as a B2BUA controlling media resources may also implement the OMR procedures. Annex Q shows every controlling OMR entity as an IMS-ALG and every controlled media resources as a TrGW, but other options are possible. An MGCF or AS performing as UA may also implement OMR procedures to assist in the removal of unnecessary media functions in some cases. MGCF and AS procedures can be derived from the procedures in this annex by collocating an IMS-ALG with the MGCF or AS.
The OMR procedures identify and name the IP address realm used for each media path segment among UAs and TrGWs. The terms IP realm and realm are equivalent to the term IP address realm in this annex. An IP realm name is associated with each set of IP endpoints that are mutually reachable via IP routing and without address translation. Endpoints in different IP realms usually require allocation of a TrGW between those IP realms for connectivity and possibly for NAT.
When endpoints in different IP realms are mutually reachable without allocation of a TrGW, then OMR procedures may use provisioned information about such connected IP realms to determine possible optimal media paths through these connected realms.
IMS-ALGs implementing OMR shall include information in forwarded SDP regarding IP realm, codec and IP connectivity information for TrGWs on the media path to assist in bypassing unnecessary TrGWs. A TrGW can be bypassed when it is not required to transcode, when it is unnecessary to protect a network resource, and when a successive TrGW on the path is reachable by a previous TrGW on the path via a common IP realm.
The OMR procedures have the following additional characteristics:
  • They build on the ALG NAT traversal model that is an alternative to the ICE NAT traversal model.
  • They usually complete within a single end-to-end SDP offer/answer transaction. Some transcoding scenarios require additional signalling to complete optimisation.
  • They apply independently to each media stream established by an SDP offer/answer transaction.
  • They apply to media streams established between any types of endpoints (e.g. UEs, media servers, media gateways).
  • They apply to media streams established using SIP 3pcc procedures. OMR applies to the endpoints of an SDP offer/answer transaction and not necessarily to the endpoints of a SIP dialog.
  • They apply separately to each dialog when forking occurs. An IMS-ALG shall delay the release of a TrGW for OMR until it is clear that no forked dialog needs the TrGW.
  • For early media negotiated with the same SDP as normal media, the OMR procedures have no direct impact on early media handling since path modifications are in place as soon as the SDP offer/answer transaction completes. An IMS-ALG can anchor in place any TrGW needed for blocking of unauthorized early media by removing OMR SDP extension attributes as necessary. For separate early-session disposition SDP the OMR algorithm shall not be applied.
  • They do not require endpoints to support new procedures, although some additional optimisations are possible in some special cases.
Up

Q.2  Procedures and flows  p. 282

Q.2.1  SDP extension  p. 282

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.
Up

Q.2.2  General IMS-ALG procedures  p. 282

IMS-ALGs supporting OMR shall be able to support the call flows in clause Q.2.4 and clause 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.
  • 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 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 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).
Up

Q.2.3  Common flows  p. 284

Q.2.3.1  IMS-ALG allocates a TrGW  p. 284

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.
Up

Q.2.3.2  IMS-ALG does not allocate a TrGW  p. 284

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.
Up

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

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.
Reproduction of 3GPP TS 23.228, Fig. Q.1: IMS-ALG bypasses its TrGW and one or more prior TrGWs
Figure Q.1: IMS-ALG bypasses its TrGW and one or more prior TrGWs
Up
Step 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.
Step 2.
IMS-ALG1 allocates TrGW1 to provide a NAT between R1 and R2.
Step 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.
Step 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.
Step 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.
Step 6.
IMS-ALG2 receives an SDP answer with valid connection information (IP3) in realm R1.
Step 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.
Step 8.
IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.
Step 9.
IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP realm instance received in step 7.
Step 10.
A user plane connection is now established in realm R1 without the need to allocate any additional TrGWs.
Up

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

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.
Reproduction of 3GPP TS 23.228, Fig. Q.2: IMS-ALG bypasses its TrGW using secondary realm from prior IMS-ALG
Figure Q.2: IMS-ALG bypasses its TrGW using secondary realm from prior IMS-ALG
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 6.
IMS-ALG2 receives an SDP answer with valid connection information (IP4) in realm R3.
Step 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.
Step 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.
Step 9.
IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.
Step 10.
A user plane connection is now established with one segment in realm R1 and a second segment in realm R3, mediated by TrGW2.
Up

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

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.
Reproduction of 3GPP TS 23.228, Fig. Q.3: IMS-ALG bypasses one or more prior TrGWs using a secondary realm
Figure Q.3: IMS-ALG bypasses one or more prior TrGWs using a secondary realm
Up
Step 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.
Step 2.
IMS-ALG1 allocates TrGW1 to provide a NAT between R1 and R2.
Step 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.
Step 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.
Step 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.
Step 6.
IMS-ALG2 receives an SDP answer with valid connection information (IP4) in realm R3.
Step 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.
Step 8.
IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.
Step 9.
IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP address of the TrGW2 in realm R1.
Step 10.
A user plane connection is now established with one segment in realm R1 and a second segment in realm R3, mediated by TrGW2.
Up

Q.2.3.6  IMS-ALG bypasses TrGWs performing NAT traversal  p. 288

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.
Reproduction of 3GPP TS 23.228, Fig. Q.4: IMS-ALG bypasses TrGWs performing NAT traversal
Figure Q.4: IMS-ALG bypasses TrGWs performing NAT traversal
Up
Step 1.
IMS-ALG1 receives an SDP offer from UA1 in private realm R1 behind a NAT.
Step 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.
Step 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.
Step 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.
Step 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.
Step 6.
IMS-ALG2 receives an SDP answer with valid connection information (IP3) in realm R1.
Step 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.
Step 8.
IMS-ALG1 de-allocates TrGW1 since there is no valid connection information available in the SDP answer for realm R2.
Step 9.
IMS-ALG1 forwards the SDP answer after modifying the connection information to correspond to the IP realm instance received in step 7.
Step 10.
A user plane connection is now established in realm R1 without the need to allocate any TrGWs.
Up

Up   Top   ToC