The SUBSCRIBE method is used by the SBC to request the current state and state updates from the remote node. The subscription is valid until the expiration of the subscription timer (indicated in Expires header), or by explicit removal of the subscription (by sending SUBSCRIBE with expires 0, or sending NOTIFY with subscription state as terminated).

While SUBSCRIBE creates an explicit subscription, the REFER request (used in such applications as call transfer) implicitly establishes a subscription to the refer event.

On reception of an OOD (Out-Of-Dialog) SUBSCRIBE or REFER, a matching Registration Control Block (RCB) is searched. If no matching RCB is found and if Registration is required, then the request is rejected.

If the psxRouteForSubscribe flag is disabled, the request is handled with the RCB capturing the changes listed below. A relayCB is used as the subscription context to store the route-set related information from the SUBSCRIBE/REFER and the corresponding 200 OK.

  1. Subscription state information

  2. Subscription timer

  3. Route-set information

If the psxRouteForSubscribe flag is enabled (or no RCB is found), the SUBSCRIBE/REFER is handled as a relay scenario whereby a relayCB is allocated for the Subscription irrespective of whether it is a registered or unregistered user..

In a situation with registered users and psxRouteForSubscribe is not set, the following routing handling occurs:

  1. If ‘use stored route-set’ is enabled, route the request based on the stored route-set (received on Service-Route/Path header depending on the direction of the request)

  2. Otherwise, route the request to the REGISTER.

Note that the received Route header is applicable for INVITE only.

The SBC maintains a context for SUBSCRIBE for duration of subscribe timer (the expires value in SUBSCRIBE request). During subscription, if any in-dialog SUBSCRIBE/NOTIFY is received, then routing is based on record-routes present in SUBSCRIBE or 200 OK to SUBSCRIBE or NOTIFY if it comes before 200 OK to SUBSCRIBE.

During the following scenarios, the route set is formed on ingress and egress side of the SBC:

  1. When the SBC receives initial SUBSCRIBE with record-route, the SBC stores the received record-routes in subscription context and forwards the received in-dialog requests based on the route set that is formed from received record-route headers.
  2. When the SBC receives 200 OK to initial SUBSCRIBE with record-route, the SBC stores these received record-routes as a route set on egress side and uses the same route set to forward the further in-dialog requests towards core.
  3. When the SBC receives initial NOTIFY from core before receiving 200 OK to initial SUBSCRIBE, the SBC forms the egress route set based on the received record-routes in initial NOTIFY and uses the same route set to forward further in-dialog requests (refresh SUBSCRIBE) towards core.

 

  • No labels