7. - SIP Messages - Requests Methods
SIP request methods are used to initiate a request from a client to a server or from one server to another server in a distributed network. The SIP request methods are similar to HTTP methods and are used to perform different functions such as establishing, modifying, and terminating a session. Some of the common SIP request methods include:
| INVITE |
Used to initiate a session or invite another user to participate in a session or session modification |
| ACK |
Sent by the client to confirm that it has received a final response to its INVITE request, ACK is only used with Invite requests including re-invites. |
| BYE |
Used to terminate an existing session. |
| CANCEL |
Used to cancel an outstanding request or pending request. |
| REGISTER |
Used by a client to register its contact address with a registrar server bby binding the Agent URI to an AOR (address of record) so the sip seerver knows the location of the user agent. |
| OPTIONS |
Used by SIP User Agents (UAs) to query a server or another UA for its capabilities and determine what SIP methods and extensions it supports. It is a way for SIP UAs to discover what services are available from the server or UA and what methods can be used to access them. The OPTIONS method is usually sent without a request body, and the response from the server or UA will include information about its supported methods, extensions, and capabilities. The OPTIONS method is often used to determine if a server or UA is available and responsive, and to verify that it supports certain features before attempting to use them. |
| INFO |
The SIP INFO method is used to carry session-related control information that cannot be carried by other SIP methods. This method is used to send mid-session signaling information within an existing SIP session, such as DTMF (Dual Tone Multi-Frequency) digits or an update to session parameters. The INFO method does not modify the session state or the dialog state. It is a simple request/response method, where the recipient of the INFO message responds with a 200 OK message to acknowledge receipt of the message. The INFO message is commonly used in Voice over IP (VoIP) applications, particularly in interactive voice response (IVR) systems. |
| SUBSCRIBE |
Used to request notification of an event or set of events at a later time. An example can be requesting a notification when another person IM Presence details change. The server sends a SIP 200 OK response message to confirm the subscription, along with the current state of the event. The server then sends a NOTIFY message to the client whenever the event state changes. The NOTIFY message contains the updated state of the event and other relevant information.The client can unsubscribe from the event notifications by sending a SIP UNSUBSCRIBE request message to the server. The server sends a SIP 200 OK response message to confirm the unsubscription. The client can also renew the subscription by sending a new SUBSCRIBE request message before the subscription expires. |
| NOTIFY |
Used to notify that an event which was requested by an earlier SUBSCRIBE method has actually ocurred. It can also be used by a SIP server to NOTIFY a client of an event. The NOTIFY message contains a payload that describes the event, and it is sent in response to a subscription request made by the client using the SIP SUBSCRIBE method. The NOTIFY message is also used in the context of the SIP event notification framework, which allows for the subscription and notification of events using specific event packages. When a client receives a NOTIFY message, it can take appropriate action based on the information contained in the message. |
| REFER |
Used to Transfer calls and also to contact external resources, the REFER message contains a URI identifying the new target for the call transfer. The server receiving the REFER message will create a new INVITE request to the new target and then try to establish a new call between the transferee and the new target. Once the new call is established, the server will send a SIP NOTIFY message to the transferor indicating the status of the call transfer. If the transfer is successful, the NOTIFY message will contain a 200 OK response. If the transfer is not successful, the NOTIFY message will contain a different response code indicating the reason for the failure. |
| PRACK |
Used to acknowledge the receipt of a provisional response (1xx) to a SIP INVITE request. PRACK is used to confirm that the user agent has received a provisional response and is ready to receive the final response for the request. Each provisional response (from a UAS - e.g. a 183 session in progress) is given a sequence number, carried in the RSeq header field in the response. THE PRACK messages (from the UAC) contain a RAck heeader field, which indicates the sequencee number of the provisional response that is beingg acknowledged. PRACK messages can be used in scenarios where reliability is important, such as when using SIP over unreliable transport protocols like UDP. PRACK messages can also include a body that contains an offer or an answer to a session description protocol (SDP) negotiation. The PRACK message is part of the SIP protocol and is defined in RFC 3262 |
| UPDATE |
Used to modify the state of a session without creating a new one. It is typically used to update the session parameters such as media characteristics or session description. An UPDATE request is sent to the UAS that is involved in the session, and it includes the new session description with the updated parameters. The UAS responds with a 200 OK message, indicating that the session has been updated successfully. The UPDATE method is a reliable method and requires a reliable transport such as TCP. It can also be used to update the session timers or to cancel a pending offer. |
| SERVICE |
Can carry a Simple object access protocol (SOAP) message as it's payload. SOAP is a lightweight protocol that defines a framework for encoding request and response messages in XML. |
| BENOTIFY |
also known as Best Effort NOTIFY is used by Microsoft Lync, LCS and OCS communication products, unlike the notify method, BENOTIFY doesnt require a response as applications may no need a notify reesponse to a certain requeest thus reducing SIP signaling traffic. This is important for deployments with large numbers of clients per Lync, LCS, or OCS Server. |
| COMET |
Used to confirm that conditions to make the connection have been met, such as QoS requirements. |
No Comments