SIP CALL FLOWS & RFC 5359

 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/Supplementary features Call Flows

Basic Call Flow(Two-Party session):




CALL BUSY:

CALL HOLD:


         UserA                     Proxy                          UserB

In this scenario, User A calls User B, then User A places the call on hold. User A then takes the call off hold, then  User A hangs up the call.  Note  that hold is unidirectional in nature.  However, a UA that places the  other party on hold will generally also stop sending media, resulting  in no media exchange between the UAs.  Older UAs may set the connection address to 0.0.0.0 when initiating hold.  However, this  behavior has been deprecated in favor or using the a=inactive SDP  attribute if no media is sent, or the a=sendOnly attribute if media  is still sent.

  Also note the use of the rendering feature tag in Re-Invite (Hold) to indicate that User B's UA is no longer rendering media to B, i.e., that User B has placed the call on hold.

SIP Rendering:

                                       sip.rendering", which positively describes whether the user  agent is rendering any of the media it is receiving.  Ex: conferencing. It MUST only be used in a Contact header field in a dialog created using the INVITE request. This parameter has three legal values: "yes", "no", and "unknown".

• The value "yes" indicates positive knowledge that the user agent is rendering at least one of the streams of media that it is receiving. 
• The value "no" indicates positive knowledge that the user agent is  rendering none of the media that it is receiving.
•  The value  "unknown" indicates that the user agent does not know whether the media associated with the session is being rendered (which may be the  case if the user agent is acting as a 3pcc (Third Party Call Control)

Point to be remembered (Hold):

1) A sends re-invite to B, with new SDP Offer  that includes Attribute(a) = SendOnly /Inactive.
2) B accepts the Hold request with SDP answer that includes Attribute(a) = RecvOnly
3) The media session is unidirectional,but B UA doesn't send data.

Point to be remembered (UnHold):

1) A sends re-invite to B, with new SDP Offer  that doesn't includes Attribute(a) = SendOnly /Inactive.
2) B accepts the UnHold request with SDP answer that doesn't includes Attribute(a) = RecvOnly
3) RTP stream is re-established between A & B.

MUSIC ON HOLD:

CALL FORWARD UNCONDITIAL:

B wants all calls forwarded to the Public Switched Telephone  Network (PSTN) (which is just another URI to the proxy server).  A calls B.  The proxy server rewrites the Request URI, and
   forwards the INVITE to a Gateway.  Details of messaging behind the  Gateway are not shown.

   Note that the 181 Call is Being Forwarded response is shown as sent  by the proxy.  Strictly speaking, the proxy is behaving as a user agent in this case as a proxy cannot generate non-100 provisional responses.

   Note also that forwarding could be accomplished using a redirect (302  Moved Temporarily response).