SIP Interview Questions-2
16. Difference between a Stateful and a Statless Proxy.
- Maintains a client and server transaction state.
- Creates a new server transaction for each new request it receives.
a) Validates the request.
b) Preprocess routing information.
c) Determine target(s) for the request.
d) Forward the request to each target.
e) Process all responses.
- May generate a CANCEL request for pending INVITE client transaction. This is the only request that a Proxy can generate.
- Can apply additional logic after response arrives.
- Refer 5,7 and 8
- Does not maintain client and server transaction.
- Forward every request it receives downstream and every response it receives upstream.
- It forwards all re-transmissions and do not re-transmit message of their own.
a) Validates a request.
b) Chose one and only one target from the target set.
c) Forward the request to the chosen target.
- MUST not generate CANCEL request.
17. What does SUBSCRIBE request do?
Its very simple and I will explain it in terms of a Yahoo Messenger or GTalk in which a person gets to see the online/offline (many more) status of his/her friend.
Alice wants to know the status of 2 friends Carol and Smith or we can say that Alice wants to get notified whenever Alice's friends changes their state. For this to accomplish:
a) Alice sends a SUBSCRIBE request. To whom ? To a Server X which maintains a subscription database and the states of its subscribers. This example is close to an actual Presence Event Package but not exactly the same so just consider it for explanation sake.
b) Might be possible that Carol and Smith are also subscribed to the Server X.
Case 1: If Carol and Smith not subscribed, then Server X will send lets say an Unknown State in a NOTIFY request to Alice,
Case 2: If Carol and Smith have subscribed to Server X. Carol is online and Smith is away.
Server X will send 2 NOTIFY' to Alice, one NOTIFY indicating Carol's state and another
NOTIFY indicating Smith's state.
c) Alice Subscribe request to Server X will contain an Expires Header and an Event Header (lets say presence).
d) Server X will respond with a 200 OK indicating that the subscription has been successful. If Server X responds with a 202 Accepted it merely indicates that the server understood the request but still the subscription has not been authorized/accepted.
e) 200 OK will also contain an Expires Header with the same duration as mentioned in the Subscribe Request or it may shorten the duration but it will never lengthen the interval.
f) After the subscription is successful, immediately a NOTIFY request will be sent to Alice and also whenever there is a change in the status of Carol or Smith, Server X will send a NOTIFY request to the subscriber i.e to Alice indicating the current state of Carol or Smith.
- A NOTIFY request will contain Subscription-State (active,pending,terminated) header field that shows the current state of the subscription. It will also contain an Event header as mentioned in the initial Subscribe request.
- A NOTIFY request is also sent at the termination of the Subscription.
- 200 OK is sent back by the UAC (Alice) to indicate the receipt of the NOTIFY request.
- 200 OK response to a SUBSCRIBE request creates a Dialog.
- To terminate a SUBSCRIPTION for an event the UAC (Alice) should send a SUBSCRIBE request with Expires:0 to Server X.
- NOTIFY requests are sent from Server X within this dialog. It contains a From Tag, To Tag and an existing Call-ID.
- If a NOTIFY request is sent and there is no such dialog, the UAC(Alice) must respond with 481 Call Leg/Transaction Does Not Exist.
SUBSCRIBE creates a dialog with no SIP Sessions.
Another important thing is how does Server X will get to know the state changes of Carol and Smith. This is done by A PUBLISH method which sends the state information to Server X. For example:
- If Carol is currently online but now does not want to get disturbed by anyone, it changes its state to DONotDisturb by sending a PUBLISH request with this state info.
- A PUBLISH request will contain the same Event header as mentioned in the SUBSCRIBE request.
- The state info might be present in an xml/pidf format.
18. What is a Loop?
Loop occurs when a request that arrives at a proxy, is forwarded and later the request arrives back at the same proxy. When the request arrives for the second time, its Request-URI is identical to the first time it was forwarded and all the other header fields that affect proxy routing operation are unchanged. Thus, the proxy will again make the same routing decision on the request it made the first time.
- Loop requests are error conditions. When a loop is found a Proxy was respond with 482 loop detected.
- Loop detection technique:
a) Max-Forwards - Counter decremented on each hop of the request. If the counter reaches a value of 0 before reaching the destination, the request is discarded.
- Loop identification:
a) Branch Parameter in Via - Proxy performs some branch parameter calculation based on the header fields(From.To,CALL-ID,CSeq,R-URI) and inserts it in the Via header. In case, if the request arrives at the same proxy for a second time - the Proxy will again perform a branch parameter calculation from the header fields of the request(arrived second time) and check if the currently calculated branch parameter is equal to the branch parameter previously inserted by it.
If found to be equal, a loop has been detected. (will be equal if no header fields have changed in the request arriving a second time)
Else, the request will be forwarded towards the desired destination.
19. What is a Spiral?
This occurs when a SIP request arrives at a proxy and is forwarded onwards and the request again arrives back to the same proxy. But, this time the Request's Request-URI differs from the previous arrival. A spiral is not an error condition, unlike loop.
A typical example is of call-forwarding.
20. Mandatory Header fields for a SIP Request?
Mandatory header fields are:
Also, do not forget the mandatory request line - which has the Method, Request-URI and SIP version. The above mentioned header fields are in addition to this.
21. Explain the importance of Max-Forwards.
It servers to limit the number of hops a Request can be forwarded by proxies or gateways on the way to its destination.
- It is an integer range 0 - 255, indicating the number of times a particular request message is allowed to be forwarded.
- It must be used with any SIP method.
- Its count is decremented on every hop or we can say it is decremented by each entity that forwards the request.
- UAC must insert Max-Forwards with a default value of 70.
If the Max-Forwards value becomes 0 before the request reaches its destination, then that request will be rejected with a "483 too many hops" response. This header field also acts as a loop detection technique.
22. Explain BYE message and its branch parameter.
The BYE method is used to indicate the termination of an established media session. It can be sent by any of the User Agents participating in the session but never by proxies or other third parties. Since, it is an end-to-end method responses are generated by the other user agent.
- Any session associated with the dialog in which a BYE has been sent should terminate.
- All pending methods (if any) should be terminated.
As we read in 9, BYE is considered to be a separate transaction, thus the branch parameter present in its Via header is different from that of the INVITE transaction plus from the ACK branch param sent for 200 OK.
23. How a BYE request is routed?
A Contact Header present in INVITE and 200 OK enables a BYE request to go directly to the User Agents considering the fact that there is no Record-Route header. In case, if there is a Record-Route header the BYE request needs to traverse all the list of proxies present in the header.
If the caller sends a BYE before receiving a 200OK then, the BYE request will be handled by the proxies in the same way; as they handled the corresponding INVITE request i.e forking of BYE may occur.
24. Talking about re-transmissions - are ACK requests re-transmitted?
Think as to when an ACK request is sent? It is sent by the UAC on receiving a response from the UAS. Considering that a UAS sent a 200 OK response for an INVITE request. I will give you just a basic glimpse of RFC 3261 and you can dive further in if interested.
INVITE Server Transaction first accepts an INVITE request and then moves forward to create provisional and final responses. When a 2xx response is constructed by a TU(transaction user) it is passed to the Server Transaction layer. But remember that an INVITE Server Transaction destroys on receiving this final 2xx response from the TU (state machine moves to a Terminated state) and passes it to the transport layer.
Now, it is necessary to pass this response directly to the transport layer until an ACK arrives. Thus, 2xx response is passed to the transport layer with an interval that starts at T1 seconds and doubles for each re-transmission until it reaches T2 seconds. These 2xx response re-transmissions cease as soon as an ACK request for the response is received.
So, we can come to a conclusion that ACK request is only re-transmitted on receiving 2xx re-transmissions.
Note: ACK is only used for INVITE
25. Explain SIP Registration.
Firstly, what is Registration ?
This is a process that creates bindings in a location service for a particular domain that associates an Address-Of-Record URI with one or more Contact Addresses.
- Location Service -> It is an abstract location database that stores and retrieve location information. Please refer SIP Entities section for more details.
- Registrar -> Please refer SIP Entities section.
The location service may either be co-located with the registrar or it may run on a remote machine that may be contacted via protocol such as LDAP.
REGISTER request are sent from the UAC to the SIP Registrar Server. Contained in the REGISTER message "To Header" is the SIP URI of the Address-Of-Record of the user agent(well known address - such as printed on the business card) that is being registered. Also, the "Contact Header" in the REGISTER message is the SIP URI/Contact URI that represents the current device(and its IP address) that the user is currently using.
The Registrar binds the SIP URI of Alice and the IP address of the device in a database(location service) that can be used by the proxies. When a proxy with access to this database receives an INVITE addressed to Alice(incoming call), the request will be proxied/forwarded to the Contact URI of the currently registered device.
|------------ REGISTER -------------->|
|<---------- 200 OK --------------------- |
REGISTER Alice -> Registrar
REGISTER sip:registrar.atlas.com SIP/2.0Via: SIP/2.0/UDP alicepc.atlas.com:5060;branch=z9hG4bKnashds7
From: Alice ;tag=456248
CSeq: 1 REGISTER
Request URI - in the start line is the address of the Registrar Server. It also depicts the which domain is served by the Registrar.
To Header - contains the URI that is being registered i.e the user being registered.
Contact Header - SIP URI in it is the contact address stored by the Registrar.
From Header - Identifies the user performing the Registration.
There are 2 ways to suggest the expiration interval for a binding(s):
a) Expires header - Sets the expiration interval for all Contact Headers(one or multiple Contact URIs in case when user is registered on several devices)
b) expires parameter in Contact Header - Sets the expiration interval on a per-binding basis.
In above case, the registration expires after two hours.
Processing at the Registrar:
a) Checks if the domain in the Register request is the one that it serves.
b) Authenticate the user in From. (by sending 401 Unauthorized response)
c) Add address bindings of "To" to contact list.
d) Modify expiration interval if too long or if its too short then returns a 423 Interval too brief response to UAC, mentioning the minimum expiration time to be set in the Min Expires field of 423 response.
e) Return in 200 OK response, list of all current registrations and their expiration time and respective priorities ( 'q' param in Contact header)
200 OK Registrar -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP alicepc.atlas.com:5060;branch=z9hG4bKnashds7;received=192.0.2.4
To: Alice ;tag=2493k59kd
From: Alice ;tag=456248
CSeq: 1 REGISTER
Registrar server acknowledges the register request by sending 200 OK response to Alice. The response echoes the Contact Information that has just been saved/stored in the location database and includes a To Tag.
26. More information on SIP Registration.
- Register is an additive process - more than one device can be registered against a SIP URI.
- REGISTER request does not create a dialog.
- If no Contact Header is present in the REGISTER request, then the Registrar returns all current registrations in response.
- UAC should use the same Call-Id for registration refresh and it must refresh before expiration.
- Cseq is incremented for each REGISTER request.
- A register request may receive a 4xx response(failure) or 3xx response (redirect) containing a Contact header with the location to which subsequent registrations should be sent.
- From and To header are mostly the same except for the case of Third Party Registration.
27. Mandatory headers for SIP Registration.
28. Basic role of SIP Proxy.
- It can be both User Agent Server or User Agent Client.
- One of its primary role is routing.
- It interprets a request and if necessary it can rewrite that request message before forwarding it.
- Proxy can forward the request one after another sequentially or it can fork the request to multiple destinations/servers.
- One of its important feature can be Policy Enforcement on User Agents.
- It can Authenticate and Authorize users for certain services. Can also implement service provider call routing policies.
- Can be used as an Entry/Exit point.
29. Which headers can be modified by a Proxy?
A Proxy can only modify the following headers:
30. What is an Outbound and an Inbound Proxy?
Basic roles and services of a proxy have been described above.
When "User Agent A" makes a call - we can say it is an outbound call. The Outbound Proxy is a proxy which is serving User Agent A's domain i.e it is serving domain "texas.com". This also implies to the fact that all the agents having "texas.com" domain will be routed via this Outbound Proxy.
The scenario depicted below contains two proxies. Why? The reason is that the caller and the callee both have different domains.
User Agent A - Domain is "texas.com"
User Agent B - Domain is "chicago.com"
Outbound Proxy can also authenticate User Agent A, use its registration/subscription profile to provide some routing or feature services and also look up to the Request URI (its the address of the callee) in the DNS and then after address resolution will route the call to its destination.
The destination we got above after address resolution is actually the address of another Proxy which is an Inbound Proxy. This Inbound Proxy is a home proxy serving User Agent B's domain i.e "chicago.com". Its purpose is to contact the Location Service to find where and on which device the User Agent B is registered. After it gets the info from the Location Service it dispatches the call to the callee's (User Agent B) registered device. This is an "inbound service" and is thus called an Inbound Proxy.