HP-UX C SIP Stack Programmer's Guide (Novembery 2007)

264 HP-UX C SIP Stack Programmer’s Guide
Support for Subscription Forking
SUPPORT FOR
S
UBSCRIPTION
F
ORKING
According to the proxying rules in RFC 3261, a SUBSCRIBE request will
receive only one 200-class response. The subscription, however, may have been
accepted by multiple nodes due to forking. Therefore, the subscriber must be
prepared to receive NOTIFY requests from multiple notifiers, with From tags
that differ from the To tag received in the SUBSCRIBE 200 response.
The application should decide if the creation of multiple subscriptions from a
single forked SUBSCRIBE is allowed. If so, the subscriber establishes new
subscriptions by returning a 200-class response to each NOTIFY. Each
subscription is then handled as its own entity, and is refreshed independent of
the other subscriptions. See RFC 3265, sections 3.3.3 and 4.4.9 for multiple
subscription handling.
Note that an original subscription is a subscription that sent the original
SUBSCRIBE request. A forked subscription is a subscription that was created
by an incoming NOTIFY request.
WORKING WITH
SUBSCRIPTION
F
ORKING
A User Agent Client (UAC) sends a SUBSCRIBE request as usual. This creates
a subscriptions, sets the dialog and subscription parameters, and sends the initial
SUBSCRIBE request.
This subscription is identified by its Call-ID, From tag and Event header. The To
tag value is empty until a response message is received from a UAS. If a
NOTITY request arrives before the 200-class response, the subscription will
inherit its To tag from the NOTIFY From header tag.
HANDLING MULTIPLE
N
OTIFY REQUESTS
As a result of forking of the SUBSCRIBE request, the SIP Stack can receive one
or more NOTIFY requests. Each NOTIFY matches the subscription and nearly
matches the dialog. All identifiers are equal, but the From tag of the NOTIFY is
not equal to To tag of the dialog. This means that another server is ready to serve
the subscription.
As a result, the SIP Stack creates a forked subscription, based on the original
subscription. The forked subscription inherits the majority of its parameters
from the original subscription. The forked subscription is independent of the
original subscription, and behaves as a regular subscription.
Figure 12-9 illustrates the message flow of subscription forking.