This section contains answers to SIP queries asked by the Users. Please post more of your queries and questions @ Ask Your Question?
Query By - Arun Kumar:
For the Registration request, if the UE does not receive any 401 unauthorized or 200k OK response. What action at the UA will takes place? How long it will wait for the response?
I will try to explain this in a few
Query By - Manish Rai:
In certain cases a Proxy authenticates a user? Can you explain the exchange of messages and whether can we ignore this process?
A brief explanation would be as follows. When an initial INVITE request is sent by the UAC towards the Proxy it may think of authenticating the user by sending 407 Proxy Authentication Required Response. This response will contain a Proxy-Authenticate Header containing a challenge which would be built using cryptographic hash. For the obvious reasons so that certain fields are not shown in the open to everybody. The UAC will then resend the INVITE request with a Proxy-Authorization Header containing the credentials which will be a cryptographic hash value as well. These credentials will match the challenge from Proxy.
For the second part of your question - Yes, we can ignore this extra processing and delay caused by the 407 response. How? A client can beforehand send the credentials in the initial INVITE request. The credentials can be built form the cached challenge responses (messages exchanged earlier).
Proxy Authentication can be very helpful when:
- You want to make sure that the Originator is a valid user who is authorized to use the services provide by the Service Provider.
- Confirmation is required that no other 3rd Party has altered any message fields.
Query By - Prakash Choudhury:
i have dout on bu2back server,pls post about this.
A B2BUA is actually a SIP logical entity and is one of the most powerful Servers. It is always present in between both the endpoints of a call or a media session. What it does ? B2BUA divides the entire signaling between both ends of the call into 2 call legs and acts as a mediator. More clearly, on the originating call leg (say call-leg1) it will act as a User Agent Server accepting/receiving requests from ABC and then it will initiate a new request/an outbound call acting as a User Agent Client towards DEF. This will constitute the terminating call leg (say call-leg2).
- It maintains dialog state and must be a part of all the requests sent on the dialogs that it has established.
- It provides a "third party call control" - 3PCC
- B2BUA can also be implemented as media gateways and thus can bridge media streams for full control.
Query By - Pulkit Jain:
- To establish a call is it necessary that the both Proxy Servers are stateful.If yes then call stateful or transaction stateful?
- Is 100 Trying a mandatory parameter.
- Is it necessary to answer SDP in 200 OK or we can answer it in 180 Ringing.
- To establish a call it is not necessary for a Proxy to be stateful. A stateless proxy can be used that will just forward every request it receives downstream and every response it receives upstream. It will continue to perform the basic routing operation. It won't maintain any transaction state (will not be transaction stateful neither call stateful)
- Correction ! 100 Trying is a response not a parameter. It is sent as a response to INVITE request to stop the retransmissions by the UAC where the transport used is UDP. The UAC starts Timer A(initially set to T1 = 500ms) as soon as it sends out an INVITE. If no response is received the INVITE will be retransmitted after 2*T1 seconds:
a) 100 Trying indicates the UAC that the request has been received.
b) Also, if the Proxy/UAS knows that TU can send a reliable response within 200ms then it can refrain itself from sending a 100 Trying.
- If an initial INVITE contains an SDP offer that it can also be answered in 180 Ringing.
Query By - Abhi Singh:
What is the difference between an INVITE and and INVITE Hold?
Query By - Abhi Singh:
An INVITE sent by Endpoint(A) is an invitation to the Endpoint(B) to start a session. The SDP body in the INVITE sent from A will contain an SDP offer. Endpoint B will send an SDP Answer in 200 OK(can also be 180 ringing), ACK is sent from A and the RTP streams start flowing between A and B.
Suppose, Endpoint A wishes to put the call on hold i.e it wants to put B on hold. For this purpose A will send a Re-Invite (or for simplicity you can say a new invite) to B.
- This Re-Invite will contain an SDP offer with an attribute set to "sendonly".
o=alice 289 289 IN IP4 host.dummy.example.com
c=IN IP4 host.dummy.example.com
m=audio 49170 RTP/AVP 0
- B will reply with an SDP answer in 200 OK with an attribute set to "recvonly".
o=bob 280 280 IN IP4 host.dodo.example.com
c=IN IP4 host.dodo.example.com
m=audio 49172 RTP/AVP 0
- Thus, there will be a uni-directional flow between A and B but no media flowing between them.
This is how you put a call on HOLD by using INVITE. There are also other-ways to put a call on hold but this is the most generic way of performing a SIP Call Hold scenario.
How Stateful Transaction maintain the information?
Query By - Abhi Singh:
The Stateful Proxy keeps track of the Branches it creates i.e keeps a track of the branch ids and the CSeq of the requests that it forwards ahead. Thus, stateful proxies have a memory requirement.
Suppose we are sending invite from one endpoint and we are not getting any response then What will be done? Pls answer Thanks.
When an INVITE request is sent, a Timer B is started at the Client Transaction side.
Query By - Rakesh Kumar:
- Timer B is the INVITE transaction timeout timer.
- It is set to fire after 64*T1 seconds. T1 is equal to 500ms.
- If within this time limit UAC does not get a response the INVITE Client Transaction will be silently destroyed.
Who accessed location services? Branch-id is same for ACK in non 2xx response.
Location Service is accessed by Proxies and Redirect Servers to find the exact location of the User.
Branch-Id is same for ACK when UAC receives a non-2xx response for an INVITE.
Query By - Satya Rout:
What's the basic difference between TO and REQUEST-URI ? Are they both identical ?
TO - It is the address of record(AOR) of the user or resource that is the target of this request.
REQUEST-URI - It indicates the user or service to which this request is being sent or addressed. For ex: REGISTER Method. R-URI would be the address of the Registrar Server including the domain of the Registrar.
Main difference is that the R-URI may change along the signaling path. Simple examples can be:
- Alice calls Bob but only knows the AOR of Bob. At this point the To and R-URI will be the same in INVITE. The outbound proxy of Alice will perform the DNS resolution on the R-URI to find the proxy that serves the domain of Bob and thus there will be a change in the R-URI of the subsequent INVITE which is being forwarded by Alice's Outbound Proxy. At this point the R-URI and the TO (it does not change) will be different.
- Another case can be of strict routing where the R-URI changes.
- In case of third party Registration R-URI and the TO will differ.
Query By - Satya Rout:
Let A be sending INVITE to B and then B will send 180 ringing, 200 OK. But A will not be sending ACK so:
a) Is voice path will get established between A and B?
b) So what will happen if A will not send ACK?
c) What's the problem of A, why A is not sending an ACK?
First question - No, there will be no voice path between A and B if an ACK has not been sent for 200OK.
Second question - INVITE Server Transaction at B will send a 2xx response that 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 (==to 4 secs).
Third question - There are few possibilities but a couple of them may be:
a) It is possible that A did not receive a 2xx response from B and hence it is not sending an ACK.
b) A is sending an ACK, but it is getting lost somewhere along the signaling path.
Query By - Sree Dave:
What forms a partial dialog?
Partial Dialog = Call-Id + Local Tag.
Dialog Id (Complete) = Local Tag + Call-Id + Remote Tag.
While sending an INVITE request you have the call-id and the local tag but there is no remote tag, since we are yet to receive a response.
Query By - Satya Rout:
Why is codec important in VOIP testing?
CODECS define the way how media conversation is going to happen such as bandwidth (needed by the respective codec), sampling rate, frequency etc... Alice and Bob tell each other about the kind of codec they support and which is their preferred codec for conversation via exchanging SDPs. If, in a VOIP call there is no talkpath among the parties then, a codec mismatch between the parties might be one of the failure reasons.
I hope you major concern was related to talkpath. If any other info required let me know.
Query By - Shubha Samal:
Why ACK is called a separate transaction in SIP? Please give me an answer.
Quote from RFC3261:
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 220.127.116.11), and the UAC alone takes responsibility for acknowledging them with ACK (see Section
18.104.22.168). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.
- When the TU (transaction user) at the UAS core generates a 200 OK final response it passes it to the transaction layer and thus, at this very point the INVITE Server Transaction is destroyed - the state machine moves to COMPLETE.
- Similarly, when 200 OK final response is received by the TL (transaction) layer it destroys the INVITE Client Transaction - the state machine moves to COMPLETE. Then, the TU at the UAC core generates an ACK and passes it to the TL layer. There is no existing transaction and thus, a new transaction for ACK is created (the branch parameter also can be checked).
- As the RFC states, UAS alone takes the responsibility of retransmitting 2xx response to the UAC and the UAC alone takes the responsibility of retransmitting the ACK.
Query By - Ram Mohan
What is the significance of "via" header in SIP? Is it possible that my upstream path for request and down stream path for response can be different? If so then how "via" can be used? If I have "route" header then "via" header is useless isn't it?
For the significance of "via" please refer to the Section on SIP Headers.
A slight correction:
a) Downstream - Direction of SIP Requests
b) Upstream - Direction of SIP Responses.
I might now have got your exact question but, will give it a try.
Consider an example:
When a UAC sends out a request it is not aware of what path the request would traverse.
In the above cases no matter what path the request has traversed, the upstream response would arrive at the UAC based on the "via" headers inserted by the intermediate entities (such as Proxies). Since, each entity would add a "via" header before pushing the request to the next hop.
Route headers are meant for the purpose of routing a SIP Request - indicating the route that the request should follow to reach the destination. Via headers are meant for an exact opposite reason. It is used by the UAs or proxies generating a response to a request since a "via header" indicates the path taken by a request.
As you mentioned, a UAC may initially have a Route set for a request say INVITE so that teh request goes through the listed proxies. Each proxy on receiving the request would be removing the itself from the Route Header and forward the request along (at the same time would add itself in the via header) till the request reaches the destination. Now, the UAS (destination) does not have any route set and the only way to send a response back to the UAC is by using "via headers".