If you have the answers you can send them to me. If you like to discuss these or some other questions send me email with your suggestions/comments. I will keep this updating so feel free to visit again. New questions will be added at the end.
Via header is needed so that response can traverse the reverse request path. The response needs to traverse the reverse request path, so that intermediate proxies implement reliability state machine for INVITE and filter responses for forking proxies. If response is sent directly from final destination to original source, it might not reach the original source due to NAT and firewall issues.
No. A conference server can be a SIP user agent to receive or send call invitations, and bridge the media path.
SIP on TCP: large message bodies, requirement for secure TLS or "sips", but requires overhead of connection. SIP on UDP: stateless and fast, especially for intermediate proxies, but breaks due to NAT and firewall with large message bodies, and easily prone to spoofed requests causing DoS.
Unlike other SIP requests, a SIP INVITE's retransmission stops after receiving a provisional response. This is to avoid retransmitting, because the time between a phone ringing and a user picking up the phone can be too high. To make sure that the final response is delivered, the final response is retransmitted. To stop the retransmission of final response, the caller sends an ACK. In case of BYE and other requests, the reliability is done by retransmitting the request, even after a provisional response is received. For early media, the provisional response needs to be reliably delivered, hence is retransmitted until acknowledged by a PRACK request. TBD: REFER.
In RFC 3261, a SIP user agent MAY listen to multicast address to be aware of other users in the location, but do not respond to multicast requests. However, if the SIP devices treat them as UDP requests, it is possble to receive zero or more responses from whoever receives INVITE request. In this case the the UAC treats the first response as valid, and others are retransmissions (section 17.1.3).
Ideally, you would respond with "482 Loop Detected".
Ideally, a UAC would not send such a request. But a UAS may have registered its Contact as this URI, hence may receive such as request routed via a proxy.
Bandwidth will be too high. It will provide unwanted reliability due to SIP retransmission hence more delay. It will have more delay due to the path through all the proxies. Note that SIP can have binary message body, hence that is not really a reason.
The Content-Length header determines the size of message body. In case of UDP, a robust implementation can assume that whole packet is the SIP message if the Content-Length is missing. This assumption does not apply to TCP. Hence a missing or malformed Content-Length header would be a informed guess.
This attack is possible because a proxy routes requests that are not meant for it. Note that loop detection using Via header cannot be used to counter the attack because request URIs are different. The Max-Forwards header can be used to prevent loop, assuming that the hacked proxy correctly handles this header. Another way is to disable routing requests for which the proxy does not recognize the request-URI and the From header.
No, because proxies perform forking behavior only for INVITE. It does not work for INVITE also, because only one branch of forked request will be successful, and others will be cancelled by the proxy.
Every three hours, each user will generate 1+3=4 REGISTER requests. So hundred thousand users will generate 4*100000/3*60*60 = 37 requests/second at the registrar, which should be its minimum capacity. In practice, it should be many times more than this to handle unexpected spike of requests, e.g., restarting the server after significant downtime will cause all users to quickly register.
SIP discourages Basic authentication, and only Digest is used. Using separate passwords for REGISTER and INVITE causes unnecessary complexity. Using separate userid for REGISTER and INVITE does not work well for authenticated call routing. The best solution is to disable Basic authentication at UAC. Alternatively, the UAC should warn the user if it is using the Basic authentication for calls.
Yes, you still need Via, because one proxy sends message to another proxy at application layer, by building a new packet (transport and IP layer), and hence sets the TTL to the initial high value instead of decrementing from received IP packet. Detecting loops using Via header is CPU Intensive, hence expensive, at high speed proxies, hence Max-Forwards allows you to have a fallback loop prevention.
Advantage of same signaling and media path is that it simplifies the protocol and ensures easy firewall and NAT traversal. Disadvantage is that it introduces unnecessary latency and transport constraints on media path, if signaling path is via multiple proxies or on TCP. Advantage of different signaling and media path is that it de-couples the two, and is more efficient. The disadvantage is that it requires additional work to get around NAT and firewall. In a SIP based IP telephony calls, DTMF signals may be carried as (1) embedded audio, in which case the low bandwidth codecs distort the signal, causing problems in recognization at the receiving end, (2) special RTP packet as per RFC 2833 and signalled as telephone-event media type, or (3) SIP INFO request containing message body describing the signal. The option (2) is preferred, since it avoids the signaling path.
Yes, partially. Since RTSP allows both record and playback of real-time media stream, you can have the user publish his own stream, e.g., rtsp://caller@domain/123, and play other person's stream, e.g., rtsp://callee@domain/123, and vice-versa for the other person. Timing the play after publish, you can also do end-to-end media path. The problem is that it does not handle call signaling (ringing of phone only when the other party calls), call routing, e.g., proxy, redirect, forking, etc, and offer/answer session negotiation.
Yes. A forking proxy sends a CANCEL to other unterminated branches when it receives a 200-response, and deletes the original transaction state. However, a race condition may cause second receiving device to send 200-response, before it receives the CANCEL. The proxy must forward any 200-response upstream, otherwise the caller cannot send ACK to terminate its retransmissions. The caller should explicitly terminate the second call leg by sending a BYE.
Advantage of end-to-end ACK is that it reduces the number of messages to proxies. Disadvantage is that it is an exception rather than a rule hence adds complexity, because ACK for failure response still needs to be hop-by-hop. Another problem could be that for end-to-end ACK the final destination may not be directly reachable from the original source due to NAT and firewall.