SIP SUBSCRIBE and NOTIFY Requests

SUBSCRIBE and NOTIFY (rfc 3265) 

1. ability to receive asynchronous notification of events, on subscription
2. general concept is that the entities in the network can SUBSCRIBE (which needs to be refreshed periodically) to resource or call state, and be notified when the state changes
3. SUBSCRIBE requests create a dialog
4. terms and definitions
   1. Event Package, set of state info to be reported by a notifier to a SUBSCRIBEr
   2. Event Template Package, special kind of event package which defines a set of event packages with a set od states which may be applied to all possible event packages
   3. Notification, act of sending a NOTIFY message to the SUBSCRIBER, informaing the state of resource
   4. Notifier, UA which generates the NOTIFY request, and typically accepts SUBSCRIBE request to create subscriptions
   5. State Agent, notifier which publishes the state on behalf of a resource, they may need to gather such info from multiple sources
   6. SUBSCRIBER, UA which receives a NOTIFY request, typically generate SUBSCRIBE request
   7. subscription is a set of application state associated with a dialog, containing a pointer to the associate dialog, the even package name, and an identifiction token
   8. Subscription Migration, act of moving a subscription from one notifier to another
5. "Expires" Header
   1. SUBSCRIBE requests should contain an "Expires" header, indicating the duration of subscription 
   2. if no "Expires" header is present then the implied default defined in the even package is used
   3. 200 class response to a SUBSCRIBE request must contain an "Expires" header, the period can be shorter(but not longer) than specified in the request
   4. SUBSCRIBE with an "Expires" of 0 means
      1. the request is for unSUBSCRIBE from an event
      2. can also cause a fetch of state
      3. successful unsubscription will also trigger a final NOTIFY message

SIP Dialog

1. peer to peer SIP relationship between two user agents
2. facilitate sequencing messages between UA and proper routing of requests between them
3. provides a context in which to interpret SIP messages
4. dialogs can be created by
   1. INVITE method (rfc 3261)
   2. SUBSCRIBE and NOTIFY method (rfc 3265)
5. a dialog is identified with a Dialog-ID
   1. the dialog-ID at each UA involved in the dialog is not the same, the local tag at one UA are identical to the remote tag at the peer UA
   2. dialog-ID is also associated with all the responses and with any request that contain a tag in To filed
   3. the rules for computing the dialog-ID of a message depends on whether SIP element is a UAS or UAC. 
   4. for a UAC the dialog-ID is composed of 
      1. call-ID
      2. remote tag (tag in the To field)
      3. local tag (tag in the From field), as this is added by the UAC on sending the request
   5. for a UAS the dialog-ID is composed of
      1. call-ID
      2. remote tag (tag in the From field)
      3. local tag (tag in the To field), added by UAS in the response