Service-Route Header Processing

 

When the

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

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

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