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 Messages

1. request from a client and response from a server are SIP messages
   
2. SIP requests are distinguished by having a request line which contains a method name, a Request URI and protocol version
   
   1. RFC 3261 defines six methods (SIP extensions contains others)
      1. REGISTER for registering contact information
      2. INVITE, ACK and CANCEL for setting up session
         
      3. BYE for terminating sessions
      4. OPTIONS for querying server capabilities
         
   2. Request URI is a SIP or SIPS URI, it indicates the user or service to which this request is being addressed, SIP elements may support other URI types like tel URI
   3. SIP version is "SIP/2.0" 
      


3. SIP Responses have a status line as their start line, which consist of protocol version, numeric status code and its associated text
   
   
   
   1. Status code is a three digit integer result code, indicating the outcome of an attempt to understand and satisfy a request.
   2. the first digit of the status code defines the class of the response, there can be six values for the first digit, ie six response categories
      
      1. 1XX: Provisional , the request is received and is in process
      2. 2XX: Success , the request was successfully received, understood, and accepted
      3. 3XX: Redirection , the request needs to be redirected, one reason for that is, the recipient has changed its location
      4. 4XX: Client Error , bad syntax in the request, thus cant be fulfilled at this server
      5. 5XX: Server Error , server failed to fulfill the request (a valid one)
         
      6. 6XX: Global failure , the request cant be fulfilled at any server
         
   3. reason phrase is to give a short textual description of the status code, for the human user
      

Structure of SIP Protocol Stack

1. fairly independent processing stages
2. element "containing" a layer means elements compliance with the rules defined by that layer
3. lowest layer is "syntax and encoding" layer
   
   1. encoding is specified using BCNF (Backus-Naur form grammar)
      
4. second layer is "transport layer"
   
   1. defines how a client sends requests and receives responses
   2. defines how a server receives requests and sends responses
   3. all SIP elements contain a transport layer
      


5. third layer is "transaction layer"
   
   1. transaction is a 
      1. request send by client transaction (using transport layer) to a server transaction
      2. along with all the responses to that request send by the server transaction back to the client
         
   2. handles application layer retransmissions
   3. matching of responses to request
   4. handles application layer timeouts
   5. statefull proxies, and User Agents have a transaction layer
      
   6. stateless proxies don't have a transaction layer
      
   7. Transaction layer has two components, which are represented by a finite state machine constructed to process a particular requests
      
      1. Client Component (client transaction)
         
      2. Server Component (server transaction)
         
6. the fourth layer is "transaction user"
   
   1. each of the SIP entities except a stateless proxy is a transaction user
      1. when a TU wishes to send a request it creates a client transaction instance and passes it the request, along with destination IP address, port, and transport to which to send the request
         
      2. a TU that creates a client transaction can also cancel it, using a CANCEL request, which constitute its own transaction, but references the transaction to be canceled
         
      3. on canceling the server stops further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction
7. the SIP elements, UA clients and servers, stateless and stateful proxies, and registrar, contains a core that distinguish them from each other. Cores except for the state less proxies are TU. 
   

Overview Of SIP Operation I

1. basic functions of SIP (HTTP like request/response transaction model)
   
   
   1. Location of an endpoint
      
   2. signal of a desire to communicate
      
   3. negotiation of session parameters for the session
      
   4. teardown of session once established
      
2. Request handling in SIP is often classified as either INVITE or non-INVITE (an ACK is only sent in response to a response for an INVITE request,INVITE/200/ACK)
   
3. SIP messages are text-encoded
   

INVITE message example, with header fields (minimum required set)

1. INVITE sip:bob@biloxi.com SIP/2.0
   
2. Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
   
3. Max-Forwards: 70
   
4. To: Bob <sip:bob@biloxi.com>
   
5. From: Alice <sip:alice@atlanta.com>;tag=1928301774
   
6. Call-ID: a84b4c76e66710@pc33.atlanta.com
   
7. CSeq: 314159 INVITE
   
8. Contact: <sip:alice@pc33.atlanta.com>
   
9. Content-Type: application/sdp
   
10. Content-Length: 142

SIP Overview

1. An application layer control protocol (works with both IPv4 and IPv6), that can
   
   
   1. establish modify and terminate multimedia sessions (conferences), such as IP telephony calls
      
   2. invite participants to existing sessions (like multicast conferences)
      
   3. existing sessions can be modified by adding/removing media from an existing session
      
   4. transparently supports name mapping and redirection services (support to personal mobility)
      
   5. a single externally visible ID can be maintained regardless of the network location (SIP URI)

A sip of SIP

1. Session Initiation Protocol (application layer protocol)
2. communication session between two endpoints(single entity in the networked cloud which wants to initiate the session)
3. how to start talking (transfer voice data between), how to initiate, what are the things to agree upon
   
   1. some central entity to coordinate
   2. willingness to send and receive
   3. agreeing on same protocol
   4. knowledge of the location of each other (location can change at run time)
   5. ability to inform each other of some change
   6. some quality with regards to the data (voice,text,video) packets
   7. subscription to services, reception of change notification