Based on SIP specifications, there are bunch of Request Method in Request-Line and Response Codes in Response-Line. On the bottom of this post, I made up a list for Request Methods and Response Codes. And how to use the major request/response operation with examples in this post.
When a user agent desires to initiate a session, it gets started with INVITE request. Unlike other requests, INVITE needs three-way handshake; INVITE / 200 OK / ACK. There is no separate ACK transaction, which means TU passes one directly to the transport layer for transmission and does not wait for response to it.
Other methods are expected to complete rapidly and non-INVITE transactions are known as two-way handshake. INVITE transaction is different from other methods because it takes some duration to receive the final response, 200 OK. Normally human input is required on the callee's end point system, 1xx provisional responses like 100 Trying, 180 Ringing and etc. can be used before the final response like 200 OK is sent by the callee.
When the client receives 1xx responses, retransmission cease altogether and wait for the final response. If other responses like 3xx, 4xx, 5xx, or 6xx are received, the caller can retry INVITE.
On the above example, the caller initiates a call with INVITE and it alerts the callee's device and ring back tone can be hear on the caller side. When the callee answers the call, 200 OK final response is sent to the caller and ACK is sent from the caller as final message in this 3-way INVITE operation. And also Cseq (sequence number and method) in ACK is combined from INVITE as original request and ACK as another.
PRACK method is used by clients in order to ask callee's network to reserve network resource for call establishment. Supported header field with option tag "100rel" must be included in INVITE request and Require header field containing option tag "100rel" in non-100 responses to the request before doing PRACK related operation.
When PRACK operation is negotiated, UPDATE method can be used in order to update SDP description on both client and server sides. Depending on how to negotiate SDP features between the caller and callee, there are 2 different status types; End-to-End Status Type and Segmented Status Type.
- End-to-End Status Type: Reservation gets started on both sides for further SDP negotiation with UPDATE methods
- Segmented Status Type: Caller's resource reservation is done before INVITE request
Here is an example with PRACK operation for the first case. Supported with 100rel in INVITE request with SDP (a=curr:qos e2e none) is sent to the callee, then the callee's network resource reservation can get started with 183 Session Progress response. Since callee's reservation got started first and assure callee's sending resource is reserved, the callee asks confirmation of the caller's sending resource (a=conf:qos e2e recv). After the caller receive this, caller's sending resource reservation gets started under PRACK operation. When reservation is done, UPDATE request is sent with it's modified SDP (a=curr:qos e2e send). Lastly the callee sends 200 OK response with it's modified SDP (a=curr:qos e2e sendrecv), which meets the original destination status.
And here is another example for Segmented Status Type. In this case caller's network resource reservation can be started before INVITE is sent from the caller. Since the INVITE includes reserved resource related SDP (a=curr:qos local sendrecv, a=curr:qos remote none), the callee should reserve resource after the request received. Reservation is done and then 180 Ringing with modified SDP (a=curr:qos local sendrecv) is sent to the caller. Since SDP modification is completed, PRACK and other INVITE related operation is deployed without UPDATE operation.
Let's clarify each SDPs attributes for these 2 different types with comparison table below.
A user agent must place registration before make or receive calls through SIP protocol. In protocol message perspective, REGISTER operation is quite simple and usage of header fields is a bit different from other requests. Both To and From header fields have the same contents because REGISTER request does not have purpose to call another but register itself.
When REGISTER is shown in Wireshark log, it seems pretty much simple and 200 OK response says 1 bindings. In order to understand what this means, SIP message does not help and need to understand how server side works based on RFC 3261.
Here is another example, which I draw based on my understanding of Figure 2: REGISTER example in RFC 3261. When UA sends REGISTER request to Registrar server, To and Contact header fields are critical role on server side. Registrar asks Location server to add this user, domain name (address-of-record) in To header field and Contact address, which is so called, binding on Location server. These Registrar and Location servers could be located in the same or different position. This picture below shows logical operation how to handle REGISTER request through network. Once a UA is registered on a location server, another UA can refer to that Location server via proxy servers in order to call the first UA.
UAs can use 3 steps to determine the address to which to send a REGISTER request; 1) by configuration of phone side, 2) using the address-of-record, 3) multicast. If there is not configuration of registrar address on device side, UA should use the host part of the address-of-record in Request-URI.
Authorization/Authentication can be required while registration or call. Here is an example with REGISTER operation. UAC originates REGISTER request with Authorization field header, which does not have credentials; no nounce and response values. UAS can challenge the originator to provide credentials by rejecting it with a 401 Unauthorized status code. WWW-Authentication header field in the response contains authentication algorithm and parameters such as nounce, qop, and opaque. Once UAC receives this, the same request with more parameters in Authorization header field including generated response value. Finally 200 OK response comes out from UAS after add binding.
UAs use SUBSCRIBE operation in order to refresh remote state, server's state when they would like to subscribe to resource or call state for various resources in the network. Server on network side sends notification when those stages changed.
SUBSCRIBE method includes Expires header with number and Event header with event package name. In registration procedure, Event header with "reg" tag is used in SUBSCRIBE request and the 200 OK response is sent. This SUBSCRIBE method uses a new Call-ID and a new tag, which are different from what used in previous dialog. If the Event header cannot be understood on server side, non-200 class responses like 489 Bad Event or 406 Not Acceptable are sent.
After resource is reserved and refresh state on network side, NOTIFY method is sent to the UA. This includes Event header with "reg" tag as well as Subscription-State header with state (active, pending, terminated, or so) and expires.
Lastly, here is the list for SIP Requests and Responses
INVITE ( / 200 OK / ACK ) operation
When a user agent desires to initiate a session, it gets started with INVITE request. Unlike other requests, INVITE needs three-way handshake; INVITE / 200 OK / ACK. There is no separate ACK transaction, which means TU passes one directly to the transport layer for transmission and does not wait for response to it.
Other methods are expected to complete rapidly and non-INVITE transactions are known as two-way handshake. INVITE transaction is different from other methods because it takes some duration to receive the final response, 200 OK. Normally human input is required on the callee's end point system, 1xx provisional responses like 100 Trying, 180 Ringing and etc. can be used before the final response like 200 OK is sent by the callee.
When the client receives 1xx responses, retransmission cease altogether and wait for the final response. If other responses like 3xx, 4xx, 5xx, or 6xx are received, the caller can retry INVITE.
On the above example, the caller initiates a call with INVITE and it alerts the callee's device and ring back tone can be hear on the caller side. When the callee answers the call, 200 OK final response is sent to the caller and ACK is sent from the caller as final message in this 3-way INVITE operation. And also Cseq (sequence number and method) in ACK is combined from INVITE as original request and ACK as another.
PRACK ( and UPDATE) operation
PRACK method is used by clients in order to ask callee's network to reserve network resource for call establishment. Supported header field with option tag "100rel" must be included in INVITE request and Require header field containing option tag "100rel" in non-100 responses to the request before doing PRACK related operation.
When PRACK operation is negotiated, UPDATE method can be used in order to update SDP description on both client and server sides. Depending on how to negotiate SDP features between the caller and callee, there are 2 different status types; End-to-End Status Type and Segmented Status Type.
- End-to-End Status Type: Reservation gets started on both sides for further SDP negotiation with UPDATE methods
- Segmented Status Type: Caller's resource reservation is done before INVITE request
Here is an example with PRACK operation for the first case. Supported with 100rel in INVITE request with SDP (a=curr:qos e2e none) is sent to the callee, then the callee's network resource reservation can get started with 183 Session Progress response. Since callee's reservation got started first and assure callee's sending resource is reserved, the callee asks confirmation of the caller's sending resource (a=conf:qos e2e recv). After the caller receive this, caller's sending resource reservation gets started under PRACK operation. When reservation is done, UPDATE request is sent with it's modified SDP (a=curr:qos e2e send). Lastly the callee sends 200 OK response with it's modified SDP (a=curr:qos e2e sendrecv), which meets the original destination status.
And here is another example for Segmented Status Type. In this case caller's network resource reservation can be started before INVITE is sent from the caller. Since the INVITE includes reserved resource related SDP (a=curr:qos local sendrecv, a=curr:qos remote none), the callee should reserve resource after the request received. Reservation is done and then 180 Ringing with modified SDP (a=curr:qos local sendrecv) is sent to the caller. Since SDP modification is completed, PRACK and other INVITE related operation is deployed without UPDATE operation.
Let's clarify each SDPs attributes for these 2 different types with comparison table below.
REGISTER operation
A user agent must place registration before make or receive calls through SIP protocol. In protocol message perspective, REGISTER operation is quite simple and usage of header fields is a bit different from other requests. Both To and From header fields have the same contents because REGISTER request does not have purpose to call another but register itself.
Here is another example, which I draw based on my understanding of Figure 2: REGISTER example in RFC 3261. When UA sends REGISTER request to Registrar server, To and Contact header fields are critical role on server side. Registrar asks Location server to add this user, domain name (address-of-record) in To header field and Contact address, which is so called, binding on Location server. These Registrar and Location servers could be located in the same or different position. This picture below shows logical operation how to handle REGISTER request through network. Once a UA is registered on a location server, another UA can refer to that Location server via proxy servers in order to call the first UA.
UAs can use 3 steps to determine the address to which to send a REGISTER request; 1) by configuration of phone side, 2) using the address-of-record, 3) multicast. If there is not configuration of registrar address on device side, UA should use the host part of the address-of-record in Request-URI.
Authorization/Authentication can be required while registration or call. Here is an example with REGISTER operation. UAC originates REGISTER request with Authorization field header, which does not have credentials; no nounce and response values. UAS can challenge the originator to provide credentials by rejecting it with a 401 Unauthorized status code. WWW-Authentication header field in the response contains authentication algorithm and parameters such as nounce, qop, and opaque. Once UAC receives this, the same request with more parameters in Authorization header field including generated response value. Finally 200 OK response comes out from UAS after add binding.
SUBSCRIBE / NOTIFY operation
UAs use SUBSCRIBE operation in order to refresh remote state, server's state when they would like to subscribe to resource or call state for various resources in the network. Server on network side sends notification when those stages changed.
SUBSCRIBE method includes Expires header with number and Event header with event package name. In registration procedure, Event header with "reg" tag is used in SUBSCRIBE request and the 200 OK response is sent. This SUBSCRIBE method uses a new Call-ID and a new tag, which are different from what used in previous dialog. If the Event header cannot be understood on server side, non-200 class responses like 489 Bad Event or 406 Not Acceptable are sent.
After resource is reserved and refresh state on network side, NOTIFY method is sent to the UA. This includes Event header with "reg" tag as well as Subscription-State header with state (active, pending, terminated, or so) and expires.
Lastly, here is the list for SIP Requests and Responses