SIP Register Call Flow

 SIP Entities Call Flows:

1) Registrar Server  :

                                             User A                                            Registrar
                                                                                                    Server

Step 1
 In this case User A  sends a REGISTER request, where the fields “from” and “to” correspond to the registered user and Request-URI contains the address of "Registrar". The Proxy server, who acts as" Registrar Server".

Step 2
The Registrar server Challange the  User A  by adding "WWW-Authenticate" header field in 401 Unauthorized Response.

WWW-Authenticate: Digest realm="atlanta.com", qop="auth", opaque="", nonce="f4dfjkdfh6jfjdf7fdfdf7fdf8dfd4", algorithm=MD5, stale=false

Step 3
User A send Register request with Credentials containing the authentication information of user agent for the proxy added in header field " Authorization".

Authorization: Digest Username="alice",realm="atlanta.com",nonce="f4dfjkdfh6jfjdf7fdfdf7fdf8dfd4",, response="f8fjfhgf8ffgf8gfg9egt9gt9gtsfs9",cnonce="gtgt5kuyk6jujuj8",opaque="",qop=auth.

Step 4

Registrar server sends,   Registration successfull -200 OK response back to User agent .
 Registration Unsuccessfull - 401 Unauthorized back to User agent.


Proxy Server :

                                     User A                      Proxy Server                     User B                                                                                     

Add caption

Step 1
 In this case User A and User B sends a REGISTER request, where the fields “from” and “to” correspond to the registered user and Request-URI contains the address of "Registrar". The Proxy server, who acts as" Registrar Server", checks if the user can be authenticated and sends an OK message if everything is fine.

Step 2
User A sends an INVITE request to the proxy server. Immediately, the proxy sends a TRYING 100 to stop the retransmission and reroute the request to the User B by sending an INVITE to it.

Step 3
The User B on receiving the INVITE sends a TRYING 100 to proxy followed by a Ringing 180. It is at this time the telephone begins to ring and it is also reroute by the proxy to the User A.

Step 4
Finally, User B sends the  200 OK message to the proxy which is sent to User A which is acknowledged by User A and the ACK is sent to User B. 

Step 5

The call is now establised and the RTP transport protocol starts with the parameters (ports, addresses, codecs, etc.) of the SDP protocol.

Step 6
This transaction corresponds to a session end . This is carried out with an only BYE request to the Proxy, and later reroute to User B. This user replies with an  200OK message to confirm that the final message has been received correctly.

Redirect Server:

UA Server:

**************************************************************

 Call Functionality Flows

Basic Call Flow(Two-Party session):





CALL BUSY:

CALL HOLD:






MUSIC ON HOLD:

CALL FORWARD UNCONDITIAL:

CALL FORWARD BUSY:

CALL FORWARD NO-ANSWER:

Cancel Request:

• Cancel is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would " stop ringing " , and then respond to the INVITE with a specific error response (a 487).
• Cancel has no effect on a request to which a UAS has already given a final response.

Client Behaviour:
1) A CANCEL request should not be sent to cancel a request other than INVITE.

2) Once the CANCEL is constructed, the client should check whether it has received any response ( provisional or final ) for the request being cancelled.

3) If no provisional response has been received, the CANCEL request must not be sent ; rather, the client must wait for the arrival of a provisional response before sending the request.



Server Behaviour:

1) The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL request of its own, and a UAS will respond to it.

2) If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it should respond to the CANCEL with a 481 ( Call Leg/Transaction Does Not Exist.

3) If the original request was an INVITE, the UAS should immediately respond to the INVITE with a 487.