The Subscribe Downstream Forking Feature manages the additional SIP legs that can result from forked subscriptions.

  1. When Sentinel sends or forwards an initial SUBSCRIBE, a downstream proxy may fork the request to several targets.

  2. Each target that accepts the SUBSCRIBE will send an initial NOTIFY back to Sentinel.

  3. The first NOTIFY to arrive is associated with the original downstream leg, and will automatically be forwarded upstream by the B2BUA Feature if it previously forwarded the SUBSCRIBE .

  4. If additional NOTIFYs arrive as a result of a fork, then the SubscribeDownstreamForking feature is needed to determine how to handle them.

  5. Each additional NOTIFY potentially creates a new SIP dialog, or leg in Sentinel.

    • If the event package (determined by the NOTIFY Event: header) does not support forking, then the SubscribeDownstreamForking feature automatically rejects the NOTIFY with a 481 response, and no new leg is created.

    • If the event package does support forking, then the SubscribeDownstreamForking feature creates new downstream and upstream legs, and schedules the NOTIFY to be forwarded upstream. The new upstream and downstream legs are linked, and subsequent requests on these legs will be handled by the B2BUA Feature.

    • The names of event packages that are known to support forking are configured as per Forking event packages configuration.


Feature script name


Applicable contexts

SIP service

SAS Support


Prerequisite features

B2BUA Feature

Feature execution point

SubscriptionSipRequest [Pre]

Specification references

Example Call Flows

Forked subscription accepted

This call flow shows a downstream proxy forking a SUBSCRIBE request. The resulting NOTIFYs from each target are forwarded upstream.

subscribe downstream forking accepted

Forked subscription rejected

This call flow shows a downstream proxy forking a SUBSCRIBE request. In this case, assume that the subscribed event package does not allow forking. The SubscribeDownstreamForking feature rejects the forked NOTIFY immediately with a 481 response.

subscribe downstream forking rejected

Session state inputs and outputs


Name Type Format Description



selection key
for example, <platform>::::

For selecting configuration data


Name Type Format Description



Enum values:

Describes the outcome of the feature:

  • NONE: no action was taken

  • REJECTED: the forked NOTIFY was rejected with a 481 response

  • ACCEPTED: the forked NOTIFY will be forwarded upstream, with new upstream and downstream legs created for the new subscription.


Forking event packages configuration

Parameter Type Description



Names of SIP event packages that support forking.

The default set of event packages that support forking is:

  • call-completion

  • dialog

  • message-summary

  • refer

  • winfo

This is derived from the current list of standard event packages in the IANA SIP Event Packages Registry.

If an event package happens to be an event template package (such as winfo above), all event packages that derive from it are handled automatically. So the fictional package foo.winfo will automatically support forking because winfo does.

Additional event packages may be added as standards evolve, or to support proprietary events.


Statistic When incremented


A forked NOTIFY is accepted because the event package allows forked subscriptions.


A forked NOTIFY is rejected because the event package does not allow forked subscriptions.


The feature is unable to create the leg representing the downstream side of a forked subscription.


The feature is unable to create the leg representing the upstream side of a forked subscription.

Previous page Next page
Sentinel Express Version 4.1