You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

IMPORTANT

The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.

Refer to the SBC SIP Transparency Implementation Guide for additional information.

 

When the

Unable to show "metadata-from": No such page "_space_variables"
 receives a 200-class response to a REGISTER request from the SIP Registrar, it stores the received Service-Route header value but does not include a Service-Route header when sending the response to the SIP endpoint. SIP INVITE requests from the SIP Registrar include a reg-info parameter in the Request-URI. The
Unable to show "metadata-from": No such page "_space_variables"
 checks for the presence of the reg-info parameter when processing INVITE Request-URIs. Support for the reg-info parameter is needed to determine the direction of a call when using hop-by-hop routing.

When the

Unable to show "metadata-from": No such page "_space_variables"
 receives an INVITE request not containing a reg-info parameter in the Request-URI, it determines that the request was sent by a SIP endpoint. The
Unable to show "metadata-from": No such page "_space_variables"
 converts the Service-Route header saved from the 200-class response to the REGISTER request for the SIP endpoint into a Route header and includes the Route header in the outgoing INVITE request to the SIP Registrar.

When the

Unable to show "metadata-from": No such page "_space_variables"
 receives an INVITE request containing a reg-info parameter in the Request-URI, it determines that the request was sent by the SIP Registrar. The
Unable to show "metadata-from": No such page "_space_variables"
 does not include the Route header in the outgoing INVITE request to the SIP endpoint.

The following flags are associated with Service-Route headers:

  • Create Service Route Header—If enabled, the

    Unable to show "metadata-from": No such page "_space_variables"
     creates a Service-Route header in outgoing SIP messages. If “Add Service Route Per TG” is also enabled, the
    Unable to show "metadata-from": No such page "_space_variables"
     pushes two Service Route headers before forwarding a 200 - class response to REGISTER. The first Service Route header contains ingress SIP signaling address and trunk group information; the second Service Route header contains egress SIP signaling address and trunk group information (default is ‘disable’).

    % set profiles signaling ipSignalingProfile <profile> commonIpAttributes flags createServiceRouteHeader <disable | enable>

  • Store Service Route Header—Controls whether a

    Unable to show "metadata-from": No such page "_space_variables"
     stores/caches locally the Service-Route headers received in a 200-class response to a REGISTER request (default is ‘disable’).

    % set profiles signaling ipSignalingProfile <profile> commonIpAttributes flags storeServiceRouteHeader <disable | enable> 

  • Service Route Header Transparency Flag—If set, the

    Unable to show "metadata-from": No such page "_space_variables"
     transparently passes the received Service Route headers (default is ‘disable’).

    % set profiles signaling ipSignalingProfile <profile> commonIpAttributes transparencyFlags serviceRouteHeader <disable | enable>
  • Add Path/Service Route Flag—This flag applies to both Path Headers and Service Route Headers, and is defined in previous section.

 

  • Use Route Set Stored – Use this command to route a call using route stored from 200 OK response during registration. (default is ‘disabled’).

    % set addressContext <addressContext name> zone <zone name> sipTrunkGroup <trunk group name> callRouting useRouteSet <disabled | received | stored | storedAll> 

     

    • If set to "disabled", the request is routed using the routing database.
    • If set to "received", the request is routed using the received routeset in the request.
    • If set to "stored", the request is routed using the Path or Service-Route stored during registration.
    • If set to "storedAll", all requests (including refresh registers) are routed using Path or Service-Route stored during registration.

  • No labels