SIP interview questions

Questions Asked in Cisco

1) why prack is required and how server know that it should send prack

2) what is route and record route

3) Call flow of call forwarding

4) different types of call forwarding

5) when the INVITE is sent with video and audio how you identify video and audio

6) SBC deplyment

7) what is dialog and txn

8) types of forking. how you identify type of forking in INVITE

9) what is registration

10) during deregistering if INVITE sent what will happen

11) how many txn and dialog in successfull call w.r.t to B2B

12) SBC with access scenario

13) If user REGISTERED in diff lcation and INVITE is sent what will happen

14) CDR

15) call flow of SIP anhttps://www.blogger.com/blogger.g?blogID=7552899752876148408#editor/target=post;postID=8009079534554581480d ISUP and how SIP - ISUP paramter is matched

16) what is reinvite

17) How d you ensure call on hold 

Difference between 180 and 183 

 As per RFC3261

21.1.2 180 Ringing

   The UA receiving the INVITE is trying to alert the user.  This
   response MAY be used to initiate local ringback.
...
21.1.5 183 Session Progress

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.

RFC : https://tools.ietf.org/html/rfc3960

Ringing Tone Generation

   In the PSTN, telephone switches typically play ringing tones for the
   caller, indicating that the callee is being alerted.  When, where,
   and how these ringing tones are generated has been standardized
   (i.e., the local exchange of the callee generates a standardized
   ringing tone while the callee is being alerted).  It makes sense for
   a standardized approach to provide this type of feedback for the user
   in a homogeneous environment such as the PSTN, where all the
   terminals have a similar user interface.

   This homogeneity is not found among SIP user agents.  SIP user agents
   have different capabilities, different user interfaces, and may be
   used to establish sessions that do not involve audio at all.  Because
   of this, the way a SIP UA provides the user with information about
   the progress of session establishment is a matter of local policy.
   For example, a UA with a Graphical User Interface (GUI) may choose to display a message on the screen when the callee is being alerted,
   while another UA may choose to show a picture of a phone ringing
   instead.  Many SIP UAs choose to imitate the user interface of the
   PSTN phones.  They provide a ringing tone to the caller when the
   callee is being alerted.  Such a UAC is supposed to generate ringing
   tones locally for its user as long as no early media is received from
   the UAS.  If the UAS generates early media (e.g., an announcement or
   a special ringing tone), the UAC is supposed to play it rather than
   generate the ringing tone locally.

   The problem is that, sometimes, it is not an easy task for a UAC to
   know whether it will be receiving early media or it should generate
   local ringing.  A UAS can send early media without using reliable
   provisional responses (very simple UASs do that) or it can send an
   answer in a reliable provisional response without any intention of
   sending early media (this is the case when preconditions are used).
   Therefore, by only looking at the SIP signalling, a UAC cannot be
   sure whether or not there will be early media for a particular
   session.  The UAC needs to check if media packets are arriving at a
   given moment.

      An implementation could even choose to look at the contents of the
      media packets, since they could carry only silence or comfort
      noise.

   With this in mind, a UAC should develop its local policy regarding
   local ringing generation.  For example, a POTS ("Plain Old Telephone
   Service")-like SIP User Agent (UA) could implement the following
   local policy:

      1. Unless a 180 (Ringing) response is received, never generate
         local ringing.

      2. If a 180 (Ringing) has been received but there are no incoming
         media packets, generate local ringing.

      3. If a 180 (Ringing) has been received and there are incoming
         media packets, play them and do not generate local ringing.

         Note that a 180 (Ringing) response means that the callee is
         being alerted, and a UAS should send such a response if the
         callee is being alerted, regardless of the status of the early
         media session.

   At first sight, such a policy may look difficult to implement in
   decomposed UAs (i.e., media gateway controller and media gateway),
   but this policy is the same as the one described in Section 2, which
   must be implemented by any UA.  That is, any UA should play incoming

media packets (and stop local ringing tone generation if it was being
   performed) in order to avoid media clipping, even if the 200 (OK)
   response has not arrived.  So, the tools to implement this early
   media policy are already available to any UA that uses SIP.

SIP Interview Questions

http://www.in2eps.com/fo-sip/tk-fo-sip-ex3261.html

http://www.code2compile.comhttps://www.blogger.com/blogger.g?blogID=7552899752876148408#editor/target=post;postID=8009079534554581480/sip-discussion.html-->2 question papers in this links

http://siptestingknowledge.blogspot.in/p/sip-inteview-questions.html-->check for other question papers in this link

http://sipken.blogspot.in/2012/01/sip-interview-questions.html

http://alokprasad7.blogspot.in/2014/06/sipvoipims-interview-questions.html

http://sipinterviewquestions.blogspot.in/

SIP Protocol Structure

The lowest layer of SIP is its syntax and encoding.  Its encoding is specified using an augmented Backus-Naur Form grammar (BNF).

2. The second layer is the transport layer.  It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network.

3. The third layer is the transaction layer.  Transactions are a fundamental component of SIP.  A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. 

a. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts.

 

4. The layer above the transaction layer is called the transaction user (TU).

a. Each of the SIP entities, except the stateless proxy, is a transaction user.

b. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. 

SIP protocol structure through an example

This example illustrates, as a slide show, the structure of the SIP protocol, as outlined in RFC 3261 – chapter 5: The lowest layer is the Transport layer. It defines how a Client sends requests and receives responses and how a Server receives requests and sends responses over the network. All SIP elements contain a transport layer. The second layer is the Transaction layer. A Transaction is a request sent by a Client transaction (using the transport layer) to a Server transaction, along with all responses to that request sent from the server transaction back to the client. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Stateless proxies do not contain a transaction layer. The layer above the transaction layer is called the Transaction User (TU). Each of the SIP entities, except the stateless proxy, is a transaction user.

Here Top Start Tip:   clicking on a number provides a direct access to the detailed figure

In this example, the rejection of the first INVITE request, followed by a valid INVITE request, enables the analysis of the processing of the ACK for these two situations. It is assumed that both Proxy 1 and Proxy 3 stateful proxy servers are in the final signalling path because they requested it in the INVITE requests they routed on.

Top Up Prev Next

At Initiating UA: • The UAC (User Agent Client) TU: – Creates the initial INVITE request; – Creates a new client transaction (in the transaction layer) and passes it the INVITE message, plus the IP address, port and transport. • The new "INVITE" Client Transaction (state="calling") is identified by the CSeq header field and the "branch" parameter of the Via header field. The T1 timer is started (if UDP) before passing the message request to transport. • The Client Transport, before sending the request, inserts the 'sent-by' parameter in the Via header field. At Proxy 1: • When receiving the request, the Server Transport, by examining the 'sent-by' parameter in the top Via header field, matches it to the relevant server transaction and adds the "received" parameter. • The new "INVITE" server transaction (state="proceeding") is created by the proxy core (not acting as TU). The server transaction transmits the INVITE request to the TU and somehow knows that this TU will generate a response within 200ms: it does not send back a 100 Trying response. • The proxy core TU first validates the INVITE request. It cannot authenticate the originator because no credentials are provided. It rejects the request by sending back (see next slide) a 407 (Proxy Authentication Required) response.

Top Up Prev Next

At Proxy 1: • The proxy core TU sends back a 407 (Proxy Authentication Required) response. • The server transaction enters the "completed" state and passes the 407 response to transport. When ACK (request) is received: passes to "confirmed" state and starts the I timer. When the I timer fires, the server transaction is destroyed. • The server transport: – before sending the response: retrieve IP@ & port from 'sent-by' and "received" – when receiving the (ACK) request: by examining 'sent-by' parameter in top Via header field, matches it to relevant server transaction + adds "received" parameter. At Initiating UA: – The client transport: – When receiving the response: matches it to the relevant client transaction by examining 'sent-by' parameter in top Via header field – Before sending the (ACK) request: inserts 'sent-by' parameter in Via header field. – When receiving the 407 response, the client transitions to state="completed", passes the response up to the TU, generates an ACK, and passes it to transport. D timer started. When D timer fires, the client transaction is destroyed. – The UAC analyses the response and prepares a new INVITE request.

Top Up Prev Next

At Initiating UA: • The UAC (User Agent Client) TU: (1) creates the new INVITE request containing the correct credentials (2) creates a new client transaction and passes it the INVITE message, plus the IP address, port and transport • The new "INVITE" client transaction (state="calling") is identified by CSeq header field and "branch" parameter of Via header field. T1 timer started (if UDP) before passing message request to transport. When receiving 1xx response: state="proceeding" and T1 reset. • Client: (1) before sending a request: insert 'sent-by' parameter in Via header field (2) when receiving a response: match it to relevant client transaction by examining 'sent-by' parameter in top Via header field At Proxy 1: • Server: (1) when receiving a request: by examining 'sent-by' parameter in top Via header field, match it to relevant server transaction + add "received" parameter; (2) before sending a response: retrieve IP@ and port from 'sent-by' and "received" • The new "INVITE" server transaction (identified by CSeq header field and "branch" parameter of Via header field) is created by proxy core (not acting as TU). The server transaction sends back a 100 Trying response and transmits the INVITE request to proxy core (acting as TU). • The proxy core TU: (1) validates the request;   (2) determines the target for the request;   (3) forwards the request (see next slide) towards the target;

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

Top Up Prev Next

trip to kottilingeshwar

I have been to kottilingeswar in may 2009. kottilingeshwar is 100 kms away from bangalore. it is near to kolhar. The place is very good and we went in may 2009 and that time its very hot. they say it 1 crore lingas but only 85 000 lingas are there . see the picture

As u can see the lingas are not covered by the roof. in summer people cant stand there and take darshana. so still lot of improvement has to be done in kotti lingeshwar. No hotels are also ther