Code2Compile
Get A Hold On What You Code !!!



SIP Interview Questions - 1


Please go through the set of questions below which are frequently asked in the interviews. Also, do let me know if you have any other questions in mind which have been asked to you -


1. What is a Request-URI and its purpose?

It indicates the user or service to which this request is being sent or addressed. It may support a SIP, SIPS or TEL URI or any generic URI. It should be noted that the initial value of the R-URI is set as the To header field.

Example:
Alice calls Bob.

INVITE sip:bob@alpha.com SIP/2.0
From: Alice;tag=1928301774
To: Bobbob@alpha.com
>

Break the R-URI as "userinfo" and "@' components of the SIP URI, so
R-URI = bob@alpha.com


Extra Points
===========
  • The current destination "bob@alpha.com" may change along the signalling path. How and when we        will see later (Hint: would come into play during types of routing).
  • For REGISTER Method the R-URI would be the address of the Registrar Server including the domain     of the Registrar i.e the domain for which the registration is meant. We will see this in detail when I will      cover the Registration Process.

2. What are Local and Remote tags?

These are associated with From and To headers. An initial request from a client will contain a Local Tag in the From Header and the subsequent provisional response to it from the server will contain a Remote Tag in the To Header. These tags serve as a mechanism to identify a dialog. Tags must be globally unique & cryptographically random. Algorithm of generating a tag is implementation specific.

Example:
Alice calls Bob. Consider one alpha.com proxy b/w Alice and Bob.

  1. INVITE request from Alice to Bob. Minimum required set of header fields is shown.

    INVITE sip:bob@alpha.com SIP/2.0 

    Via: SIP/2.0/UDP pc99.alpha.com;branch=z9hG4bKnashds8 
    Max-Forwards: 70 
    To: Bob  
    From: Alice ;tag=1928301774 
    Call-ID: a84b4c76e66710 
    CSeq: 314159 INVITE 
    Contact:  
    Content-Type: application/sdp 
    Content-Length: 142

  2. 100 Trying Response from alpha.com proxy -> Alice.

    SIP/2.0 100 Trying 
    Via: SIP/2.0/UDP pc99.alpha.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 
    To: Bob  No Tag
    From: Alice ;tag=1928301774 
    Call-ID: a84b4c76e66710 
    CSeq: 314159 INVITE 
    Content-Length: 0

  3. 180 Ringing from Bob -> alpha.com proxy -> Alice.

    SIP/2.0 180 Ringing 
    Via: SIP/2.0/UDP pc99.alpha.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 
    To: Bob ;tag=a6c85cf 
    From: Alice ;tag=1928301774 
    Call-ID: a84b4c76e66710 
    Contact:  
    CSeq: 314159 INVITE 
    Content-Length: 0

Extra Points
===========
  • It should be noted that 100 Trying Response does not put a tag in the To Header

3. What is a Call-ID?

The Call-ID header field is selected by the UAC as a globally unique identifier over space and time. Cryptographically random identifiers is recommended. It helps in tracking a particular SIP dialog.

The originator of the request i.e UAC creates a locally unique string, then usually adds an “@” and its host name to make it globally unique.

Example:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@alpha.com

Compact Form of it is 'i'
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@ 


4. How do you identify a dialog? or What is a dialog identifier?

The local tag (contained in the From header field), remote tag (contained in the To header field), and the Call-ID uniquely identifies a “dialog".

When that UAC generates an INVITE request it creates a From Tag and a Unique Call-ID for the entire call. This is shown in 2 aboveAt this point of time we have only half of the dialog id. When a provisional response is being sent (other than 100 Trying) from the UAS it puts a To tag in it. Now, we have a complete Dialog ID to identify a dialog.

Dialog ID = From Tag  +  To Tag  +  Call-ID 


5. What is forking?

  1. This occurs when a proxy sends a request to one or more target at once (user is registered at multiple locations).
  2. Requires a stateful proxy.
  3. First 200 OK received is forwarded upstream.
  4. All other unanswered requests are cancelled.
  5. It has two flavors
    a) Sequential Fork -> Try first address, only if that fails try second address.
    b) 
    Parallel Fork -> Try all addresses at once.


6. Why these tags are so important?

Its importance lies in case of a Forking Scenario.

Example:

  • A sends an INVITE to B.
  • Inbound Proxy for B finds that B is registered at multiple locations like on its PDA, PC softphone.
A ---- INVITE with a From Tag ----- Forking SIP Proxy1 (Forks the request to) ---------> B's PDA (UAS 1)
                                                                                                                        ----------> B's sofphone (UAS 2)  

A <---- 180 Ringing from B's PDA with a To Tag (tag1) <---- Forking Proxy1 <----------- B's PDA (UAS 1)
  <---- 180 Ringing from B's Softphone with a To Tag (tag2) <---- Forking Proxy1 <---- B's softphone (UAS 2)

A <------- 200OK from B's softphone with a To Tag (tag2) <----- Forking Proxy1 <------ B's Softphone (UAS 2)
                                                                                not answered <----- B's PDA

Explanation:

B's two devices send 180 Ringing and one of the device answers the call by sending a 200 OK response to A. How A would be able to distinguish which device actually answered the call?

UAS does not know that the INVITE request has been forked by Proxy1 and thus each of the UAS (B's PDA/SoftPhone) insert tags in 180 and 200OK responses. The two 180 Ringing responses are exactly identical except for having different To Tags put by the respective UAs.

Important Conditions:
  1. B's Softphone answered before B's PDA (similar to the above case)
    Forking proxy forwards the 200 OK Response from B's Softphone to UAC and sends a CANCEL request to B's PDA to stop the alerting.
  2. B's Softphone and B's PDA both answered the call
    A <---- 200OK from B's softphone with a To Tag (tag2) <------ Forking Proxy1 <----- B's SoftPh (UAS 2)
       <--------- 200OK from B's PDA with a To Tag (tag1) <------- Forking Proxy1 <------ B's PDA (UAS 1)
As stated in 5, a proxy that forks a request should be stateful and such a proxy will forward only the first 200 OK response upstream (may be from UAS 2) to UAC and will send a BYE request to other UAS (say UAS 1).

Note:
"Considering a scenario in which a UAC received multiple 200 OK responses since the Proxy was stateless, Tags will help to distinguish the response from multiple UAS or we can just say that Tags would help a UAC to identify from which UAS it has received the final response".

Extra Points
===========
  • Proxies only insert tags in Final Responses they generate themselves, but they never insert tags in          request or responses they forward (ex: from UAC/UAS).
Now we can say, Tags are used by the UAC to distinguish multiple final responses from different UAS. In our case A (UAC) will get to know whether it is receiving the 2xx response from B's PDA or B's softphone based on the Tags inserted by them.

But how Proxy1 will match multiple 200 OK responses to forked requests (or can be 2xx,3xx,4xx,5xx,6xx) that it is receiving. Why I said so, look at 7.


7. Why are branch-ids so important?

For basic information refer SIP Headers section.

For the proxies to match responses to forked requests, Branch IDs are very important. Without the branch-id included in the via header, the proxy cannot tell to which branch a response corresponds to.

Again considering a similar example as above:

A ---- INVITE with a From Tag ----- Forking SIP Proxy1 (Forks the request to) ---------> B's PDA (UAS 1)
                                                                                                                           --------> B's sofphone (UAS 2)  
                                                                                                                           --------> B's Voicemail
Three branches created by the Forking proxy. How ?
  1. One request to B's PDA - Proxy included a via header with unique branch-id.
  2. Second request to B's Softphone - Proxy included a via header with unique branch-id.
  3. Third request to B's voicemail - Proxy included a via header with unique branch-id.
Responses from B's PDA, Softphone and Voicemail are matched at the Forking Proxy based on the Branch ID present in the via header that the Forking proxy had included while sending the respective requests. Here, Tags are not helpful since they are not known to the Proxy until the responses come back from UAS(s)


8. Another question on similar lines, Why a forking proxy should be stateful?

Consider the same example as above:

A ---- INVITE with a From Tag ----- Forking SIP Proxy1 (Forks the request to) ---------> B's PDA (UAS 1)
                                                                                                                           --------> B's sofphone (UAS 2)  
                                                                                                                           --------> B's Voicemail

The Forking Proxy is Stateful because:
Suppose the Forking Proxy has three branches and on each of respective branches it receives 2xx from B's PDA, 4xx from B's softphone and 5xx from B's voicemail. Now, if the forking proxy would be stateless it would end up sending all the 3 responses (since it cannot remember the response it has received earlier) to the UAC i.e A. This will cause -
  • Response implosion at the client.
  • Multiple and inconsistent responses at the client (for once that UAC will think that it is a success call        but a second later it will receive a 4xx forcing to think that it is a unsuccessful call ... confused UAC).
Thus, a forking proxy should be stateful.

Also, a proxy that uses TCP as the transport protocol must be stateful, whether it forks or not. This has to do with reliability reasons.


9. What is a SIP Transaction?

I guess we should try to understand the answer in bullet points and then followed by a pictorial description. Perfect :-)

  1. A transaction is a fundamental unit of message exchange.
  2. Simply a Request/Response cycle.
  3. It consists of a single request and any response to that request, which include
    Zero or more provisional responses.
    Usually one final response.
    Maybe ACK
  4. Transaction exists within UAs and Stateful Proxy Servers.
Successful SIP Transaction         Failed SIP Transaction

How a transaction is Identified ?
It is identified by Cseq (sequence number and method tag) and branch parameter. Refer the diagram above.

Extra Points
===========
  1. For INVITE transaction, the transaction does not include/consider the ACK if the response was a 2xx. Figure (a)
  2. For INVITE transaction, the transaction includes/considers the ACK only if the final response was not a 2xx response. Figure (b)

10. What is a SIP Dialog?

Few Points :-)

  1. A SIP dialog is a peer to peer relationship between two User Agents.
  2. Or, it is a SIP level conversation between 2 endpoints.
  3. Created through the generation of non-failure responses to requests with specific methods.
    a) 2xx and 101-199 responses with a To-tag where the request was INVITE will establish a dialog,
  4. Dialog terminations are method specific.
How a dialog is identified?
Dialog ID, which is formed by From(tag) + To(tag) + Call-Id
Can also refer 4.

How it works?

SIP Dialog


11. What is a SIP Session?

  1. The exchange of media between two or more endpoints. Commonly, RTP (Real Time Transport Protocol) protocol is used for exchange of voice media. (Figure a).
  2. It can also be used to exchange text, video , game etc...
  3. A session is basically described by using SDP (Session Description Protocol) and generally consists of multiple RTP streams between two endpoints.
Extra Points
============


  • SIP is used in the setup of sessions, but sessions can also be setup without SIP (SIP is one     of the protocols).
  • Exchange of SIP Messages does not always result in a session being setup.
  • There can be dialogs' without SIP Sessions.
SIP Session



12. Significance of via, contact, max-forwards header and the very important branch parameter

Jump to SIP Headers.




13. Explain To and From Headers?


To Header:
  1. It indicates the desired "logical" recipient of the request or the AOR (address of record) of the user or resource that is the target of this request.
  2. It supports SIP or SIPs or TEL URI or any generic URI.
  3. Occurs only once per message. Compact form is 't'.
  4. Can also contain a "display name" that can be rendered by a Human User Interface.
  5. Supports a "TAG" that helps to identify the peer of the dialog.
From Header:
  1. It indicates the "logical" identity of the user that initiated this request. Possible to be an user's AOR.
  2. It supports SIP or SIPs or TEL URI or any generic URI.
  3. Occur only once per message. Compact form is 'f'.
  4. The value to be populated is pre-provisioned by the user or by the admin of the user's local domain.
  5. Can also contain a "display name" that can be rendered by a Human User Interface. For hiding the identity of the client, the display name can be set to "Anonymous".
  6. Supports a "TAG" that helps to identify the peer of the dialog.
Just to remind you that the display name mentioned above is nothing but a name label. When a name label is provisioned the SIP URI is enclosed within brackets (for routing the request) and 
the name labels can be used for the purpose of alerting.



14. How an ACK is formed for an INVITE that has received a 200 OK response? 

  1. The Call-ID, From and Request URI must be equal to the header field values present in the original request(INVITE).
  2. The ACK's request To header field must be equal to the To header field for the response being acknowledged. Now the ACK's To header field will usually differ from the original request To header due to the addition of the Tag parameter.
  3. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method must be ACK. Please refer 9 for call flow.
  4. The branch id will be different from the one present in the INVITE request since the ACK is considered to be a separate transaction. 
  5. If the 2xx response carries an SDP offer the ACK should carry an answer in its body. Also, if the offer in 2xx is not acceptable then the UAC core must provide an answer in the ACK and send a BYE immediately.

15. How an ACK is formed for an INVITE that has received a non-200 OK response?

  1. The Call-ID, From and Request URI must be equal to the header field values present in the original request(INVITE). 
  2. To header field must be equal to the To header field for the response being acknowledged. Now the ACK's To header field will usually differ from the original request To header due to the addition of the Tag parameter.
  3. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged and the CSeq method must be INVITE. Please refer Q9 for call flow.
  4. The branch id will be the same as in the INVITE request since here ACK is considered to be a part of the INVITE transaction.








































































































































































































































































































































































































































































































































































 
 




 
Linkedin          Code2CompileTwitter          Code2CompileGooglePlus
 
About Me    |    Blog    |    Contact Us    |    Member Login
 
©Code2Compile.com -- Taking the initiative of helping out people suffering from The Interview Misery