DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.


IMPORTANT

Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC creates a Service-Route header in outgoing SIP messages. If “Add Service Route Per TG” is also enabled, the SBC 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 SBC 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 SBC 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