RFC 2976                    SIP INFO Method

   The INFO method is used to carry session control information 
   (application level information) along the SIP signaling path during 
   the session.

   The INFO method is not used to change the state of SIP calls, or the 
   parameters of the sessions SIP initiates.  




1 Example Uses

   Carrying mid-call PSTN signaling messages between PSTN gateways.

   Carrying DTMF digits generated during a SIP session.

   Carrying wireless signal strength information in support of wireless 
      mobility applications.

   Carrying account balance information.

   Carrying images or other non streaming information between the 
      participants of a session.



2 Response to INFO Method

   If a server receives an INFO request it MUST send a final response. 
    
   Handling the message body of request has no relationship with this 
   method. The SIP stack only check if the type of body is supported.
    
2.1 200 OK (with no message body)
    
   If the INFO request was successfully received for an existing call 
   and the type of message body is supported.
      
2.2 481 Call Leg/Transaction Does Not Exist 
    
   If the INFO request does not match any existing call leg.
  
2.3 415 Unsupported Media Type 
    
   If the server does not support the type of message body.
      
2.4 487 Request Cancelled
      
   If the server received a CANCEL for a INFO request, and the final 
   response has not been send.
          

          
3 Behavior
   
3.1 SIP User Agents
   
   Same as BYE request.
     
   If UAS receiving a CANCEL for an INFO request SHOULD respond to   the 
   INFO with a "487 Request Cancelled" response if a final response has 
   not been sent to the INFO and then behave as if the request were 
   never received.
     
   ? never received: Does it means the UAS should rollback the state 
   information?
     
3.2 Proxy Server (Same as BYE request)
   
3.3 Forking Proxy Server (Same as BYE request)

3.4 Redirection Server (Same as BYE request)



4 Message Bodies

   The mid-session information between SIP user agents can be placed in 
   either headers or bodies of INFO message.
   
   Bodies which imply a change in the SIP call state or the sessions 
   initiated by SIP MUST NOT be sent in an INFO message.
   
   The INFO method does not define additional mechanisms for ensuring 
   in-order delivery.  And the CSeq header should not be used to 
   determine the sequence of INFO information.  


   
5 Guidelines for extensions making use of INFO

5.1 Size Consideration while Use Unreliable Connection (UDP)
   
   Consideration should be taken on the size of message bodies to be 
   carried by INFO messages.  The message bodies should be kept small 
   due to the potential for the message to be carried over UDP and the 
   potential for fragmentation of larger messages.

5.2 Handling Fork
   
   There is potential that INFO messages could be forked by a SIP Proxy 
   Server.  The implications of this forking of the information in the 
   INFO message need to be taken into account.

5.3 Multi-part Message Bodies
   
   The use of multi-part message bodies may be helpful when defining the 
   message bodies to be carried by the INFO message.

5.4 Not to Change State of Session
   
   The extensions that use the INFO message MUST NOT rely on the INFO 
   message to do anything that effects the SIP call state or the state 
   of related sessions.

5.5 Interoperability
      
   The INFO extension defined in this document does not depend on the 
   use of the Require or Proxy-Require headers.  Extensions using the 
   INFO message may need the use of these mechanisms.  However, the use 
   of Require and Proxy-Require should be avoided, if possible, in order 
   to improve interoperability between SIP entities.