SIP Interview Questionshttp://www.code2compile.com/basic-sip-call-flow.

html
Q1. 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<sip:alice@beta.com>;tag=1928301774 To: Bob<sip:bob@alpha.com> Break the R-URI as "userinfo" and "@' components of the SIP URI, so R-URI = bob@alpha.com

Extra Points: a) 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). b) 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. Q2. 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 <sip:bob@alpha.com> From: Alice <sip:alice@alpha.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc99.alpha.com> 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 <sip:bob@alpha.com> No Tag From: Alice <sip:alice@alpha.com>;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 <sip:bob@alpha.com>;tag=a6c85cf From: Alice <sip:alice@alpha.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 Extra Points: a) It should be noted that 100 Trying Response does not put a tag in the To Header

Q3. 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@192.0.2.4

Q4. 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 Q2. At 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.

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

Q5. 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 Search -> Try first address, only if that fails try second address. b) Parallel Search -> Try all addresses at once.

Q6. Why these tags are so important ?

This comes into picture when there is a Forking scenario. Example: a) A sends an INVITE request to B. 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 Proxy1(Forks the request to) ----> B's PDA (UAS 1) ----> B's softphone (UAS 2)

A <---- 180 Ringing from B's softphone with a To Tag(say tag1) <---- Forking Proxy1 <----- B's

PDA (UAS 1) <---- 180 Ringing from B's PDA with a To Tag(say tag2) <---- Forking Proxy1 <---- B's softphone (UAS 2)
A <---- 200OK from B's softphone with a To Tag(say tag1) <---- Forking Proxy1 <----- B's PDA (UAS 1) not answered <---- B's softphone (UAS Explanation: Two

2)

devices (B's) send 180 Ringing and 200 OK responses to 'A'. How 'A' will be able to distinguish between multiple final responses ?
UAS does not know that the INVITE request has been forked by Proxy1 and thus both 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 respective UAS. Two Conditions: i) B's PDA answered before B's SoftPhone. Forking proxy forwards the 200 OK response from B's PDA to UAC and sends a CANCEL to B's SoftPhone to stop the alerting. ii) B's PDA and B's SoftPhone both have answerd.

A <---- 200OK from B's softphone with a To Tag(say tag1) <---- Forking Proxy1 <----- B's PDA (UAS 1) <---- 200OK from B's PDA with a To Tag(say tag2) <---- Forking Proxy1 <---- B's softphone (UAS 2) "As stated in Q5, a proxy that forks a request should be stateful and such proxy will forward only the first 200 OK response upstream (say from UAS 1) to UAC and will send a BYE to the UAS 2". Note: "Considering a scenario in which a UAC received multiple 200 OK responses and the Proxy is stateless Tags will help to distinguish the response from multiple UAS or we can just say that Tags help a UAC to identify from which UAS it has received a response "
Points to remember: 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 B's PDA/SoftPhone. But how Proxy1 will match multiple 200OK responses (or can be 2xx,3xx,4xx,5xx,6xx) that it is receiving on its own branches. Why I said this ? Look at Q7 ...

Q7. Why are branch-ids so important ?

For basic info 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. Considering the same example: A ----> INVITE with a From Tag ---- Forking Proxy ---- Forks the request to ----> B's PDA ----> B's softphone ----> B's VoiceMail

Three branches created by the Forking proxy. How ?

One request to B's PDA - Proxy included a via header with unique branch-id.

Second request to B's Softphone - Proxy included a via header with unique branch-id. 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 until the responses arrive from UAS(s)

Q8. Another question linked to the answer above is , why a forking proxy should be stateful ?
Considering the example above: A ----> INVITE with a From Tag ---- Forking Proxy ---- Forks the request to ----> B's PDA ----> B's softphone ----> B's VoiceMail A <---- 4xx from B's softphone with a To Tag(say tag1) ---- Forking Proxy ----- B's softphone <---- 200OK from B's PDA with a To Tag(say tag2) ---- Forking Proxy ---- B's PDA <----- 5xx from B's voicemail with a To tag(say tag3) ---- Forking Proxy----- B's voicemail The Forking Proxy here is stateful. Why ? 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: a) Response implosion at the client. b) 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.

Q9. 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 :-)

A transaction is a fundamental unit of message exchange. Simply a Request/Response cycle. It consists of a single request and any response to that request, which include

a) Zero or more provisional responses.

b) Usually one final response. c) Maybe ACK. (Please refer SIP

Messages section to understand a basic request and responses)

Transaction exists within UAs and Stateful Proxy Servers.

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

Another very important point is: For INVITE transaction, the transaction does not include/consider the ACK if the response was a 2xx. Figure (a) For INVITE transaction, the transaction includes/considers the ACK only if the final response was not a 2xx response. Figure (b)

Q10. What is a SIP Dialog ?

Points :-)

A SIP dialog is a peer to peer relationship between two User Agents. Or, it is a SIP level conversation between 2 endpoints. 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,

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 Q4. How it works ? It facilitates sequencing of messages between both User Agents and proper routing of requests between both of them. Figure (a)

Q11. What is a SIP Session ?

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

Extra Points:

a) SIP is used in the setup of sessions, but sessions can be setup without SIP ( SIP is one of the protocols). b) Exchange of SIP messages does not always result in a session being setup. c) There can be dialogs' without SIP sessions.

Q12. Explain To and From Headers ?

Make it simple to understand :-D To: 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 It supports SIP or SIPs or TEL URI or any generic URI. Occur only once per message. Compact form is 't'. Can also contain a "display name" that can be rendered by a Human User Interface. Supports a "TAG" that helps to identify the peer of the dialog.

From:

It indicates the "logical" identity of the user that initiated this request. Possible to be an user's AOR. It supports SIP or SIPs or TEL URI or any generic URI. Occur only once per message. Compact form is 'f'. The value to be populated is pre-provisioned by the user or by the admin of the user's local domain. 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. 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.

Q13. All in one: significance of via, contact, max-forwards header and the very important branch parameter :)
Please jump to SIP Headers

Q14. How an ACK is formed for an INVITE that has received a 200OK response ?
1. The CallID, From and Request URI must be equal to the header field values present in the original request(INVITE). 2. The ACK 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 referQ9 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.

Q15. How an ACK is formed for an INVITE that has received a Non-200OK response ?
1. The Called, 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.