Page History

Optimal Media Routing Support

The 

supports secondary realm if it is present in the OMR SDP attributes. It does not add secondary-realm while forwarding SDP offer.

When the 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. An

• No transcoding is required
• Protection of a network resource is unnecessary
• When

• multiple

  Spacevars
  0 product

  s are present, the successive

• Spacevars
  0 product

  in a path is reachable by the previous

• Spacevars
  0 product

  on the same path through a common IP realm.

The OMR procedure is applied before sending out the offer and re-evaluated based on the answer received in 18x. The re-evaluation of OMR procedure during answer processing is based on certain conditions:

• Local

• Spacevars
  0 product

   was in media path while sending offer
• Egress peer supports SIP UPDATE
• Pass-through based call outcome on answer received in 18x 

Four possible outcomes exist when applying OMR procedures:

• Bypass local MR and bypass previous MR
• Bypass no local MR, and bypass previous MR
• Bypass local MR (

• Spacevars
  0 product

  ) and bypass no previous MR (

• Spacevars
  0 product

  )
• Bypass no local MR and bypass no previous MR (same as normal call without OMR)

The 

remains in the path (local policy) and disables OMR when any of the following features are active:

• Multiple M-Lines in SDP
• Video Only Call
• LRBT
• Two Stage Calls

For the following features, "bypass no local MR, and bypass previous MR" is attempted, with no visited-realm sent in egress INVITE.

• Lawful Intercept
• SIP Rec
• Trans-code Only
• ATCF Call

OMR Bypass Rules

Four possible bypass rules (outcomes) exist when applying OMR procedures as shown in the table below:

Support for Insertion and Transparency of TRF Attribute as per RAVEL Architecture

The TRF procedures

are listed below.

1. The 

   Spacevars
   0 product

   as PCSCF uses Roaming Agreement from Router Controller Bundle (RCB). If UE is identified as roaming, the Roaming Agreements flag Support RAVEL, is accessed from RCB.

1. 
   
   
2. The 

   Spacevars
   0 product

1. as PCSCF adds configured preferred URIs using the following objects.
   

1. 1. Preferred_TRF_URI

1. 1.  in IPSP in the PSX. If the incoming request is identified as roaming (calling Party),

1. 1. the

      Spacevars
      0 product

       adds "Feature-Caps" header with configured TRF-URI in "+g.3gpp.trf" parameter value.

1. 1. Preferred_MRB_URI

1. 1.  in IPSP in the PSX. If the incoming request is identified as roaming (calling Party),

1. 1. the

      Spacevars
      0 product

       adds "Feature-Caps" header with configured MRB-URI in "+g.3gpp.mrb" parameter value.

1. 1. 
      
      

2. The 

   Spacevars
   0 product

1. as IBCF adds configured preferred URIs using the following objects.

1. 1. Preferred_TRF_URI

1. 1.  in IPSP in the PSX. If the incoming request is identified as roaming (calling Party) and call is originating,

1. 1. the

      Spacevars
      0 product

       adds "Feature-Caps" header with configured TRF-URI in "+g.3gpp.trf" parameter value. If the received request already contains a "+g.3gpp.trf" parameter field in "Feature-Caps" header,

1. 1. the

      Spacevars
      0 product

       does not overwrite the header field value with the configured Preferred_TRF_URI value.

1. 1. Preferred_MRB_URI of type "string"

1. 1. in IPSP

1. 1. in the PSX. If the incoming request is identified as roaming (calling Party) and call is originating,

1. 1. the

      Spacevars
      0 product

       adds "Feature-Caps" header with configured MRB-URI in "+g.3gpp.trf" parameter value. If the received request already contains a "+g.3gpp.mrb" parameter field in Feature-Caps header,

1. 1. the

      Spacevars
      0 product

       does not overwrite the header field value with the configured Preferred_MRB_URI value.

1. 1. 
      
      

2. The 

   Spacevars
   0 product

   as IBCF/TRF identifies TRF role and Mark Looped-back call. If the SIP INVITE contains "Feature-Caps" header field “+g.3gpp.loopback”,the call is marked as a looped back call. If the top route header points to self,

1. the

   Spacevars
   0 product

    considers itself as the TRF. As part of TRF Processing,

1. the

   Spacevars
   0 product

    performs:
   
   1. The 

      Spacevars
      0 product

      as IBCF/TRF supports to remove loopback from "Feature-Caps".

1. 1. Spacevars
      0 product

      removes “+g.3gpp.loopback" when copying "Feature-Caps" header to egress.

1. 2. The 

      Spacevars
      0 product

1. 1. as IBCF/TRF supports to handle IOI-Parameter (Inter-Operator-ID) in P-Charging Vector.

1. 1. 
      
      1. The

         Spacevars
         0 product

          stores

1. 1. 1. any orig-IOI parameter received in P-Charging-Vector header.

1. 1. 1. The

         Spacevars
         0 product

          uses a type-2 orig-IOI parameter in the P-Charging-Vector header of egress request, which identifies the network that SBC (TRF) belongs to (IOI Configured in Ingress SG).

1. 1. 2. The

         Spacevars
         0 product

          stores the term-IOI in P-Charging-Vector and uses a type-2 term-IOI, which identifies the TRF’s network  in the P-Charging-Vector header of the response  generated for corresponding 1xx/2xx responses received.

1. 1. 2. The

         Spacevars
         0 product

          removes

1. 1. 1. any transit-IOI parameter from P-Charging-Vector sent in egress request.

1. 1. 1. 
         
         
2. The 

   Spacevars
   0 product

1. as IBCF to add TRF. SBC checks if "+g.3gpp.trf=<trf_uri>" exists in "Feature-Caps" header. if not,

1. the

   Spacevars
   0 product

    supports to send bottom "Route Header" in PSX Query to fetch Roaming Agreement. If Roaming Agreement is present and TRF-URI/MRB_URI is configured in egress IPSP (in PSX), SBC is supported to send "+g.3gpp.trf=<trf_uri>"/"+g.3gpp.mrb=<mrb_uri>" in "Feature-Caps" header.