Assignment 9

The assignment is due Sunday, July 25, 11.59 pm EDT. Submission Guidelines

1. Programming problem: Add basic SIP capability to your voice client. You should support the INVITE (with ACK) and BYE transactions necessary to set up direct client-to-client unicast audio sessions, using RFC 3261 and the examples in RFC3665. In particular, consider Sections 2.1 and 3.1. Compared to the specification, you can take a few short cuts:
   • Only TCP.
   • You do not need to support request and response retransmission.
   • Only the core headers (To, From, Via, Content-Length, Call-ID, CSeq) need to be parsed.
   • Authentication is not necessary.
   • Only one media (audio) session in SDP will be negotiated.
   • You do not have to support Record-Route and Route.
   • Your code should recognize the SIP response classes and display the responses, but does not have to deal with redirection (3xx responses) beyond indicating the condition.

   However, your code should deal with properly-formatted SIP headers, including headers that are continued across more than one line, spaces where permissible and header fields in various combinations of upper and lowercase.

   Your code should generate a Ringing (180) response.

   You should add three commands to your interface: call sip:user@host (caller), hangup (caller or callee) and answer (callee), with the obvious meaning. You only need to support standard DNS A records (gethostbyname), not the SIP SRV and NAPTR conventions.

   You should show the above functionalities in your README/sample output file with brief explanations.

2. The utility curves shown in class were of the decreasing-reward type, i.e., the marginal utility decreased as a function of bandwidth. Can you picture an application that could have an increasing reward function? (Hint: consider Metcalfe's Law)
3. Review question: What's the difference between a leaky bucket and a token bucket?
4. A token bucket has an average rate of 25 Mb/s and a max. burst size of 100 Mb. Assume that the token counter is initially "full". The token bucket drops packets when there are no tokens. A host is connected via a 100 Mb/s network and starts transmitting at full line rate. How long can the host keep this up without having its packets dropped?
5. An obnoxious host wants to be as network-unfriendly as possible, by injecting bursts into the network. For the token bucket in the previous problem, what should this host do?
6. We saw two traffic policers/shapers, namely the token bucket and the ATM GCRA one (e.g., for mean rate). Can you show that the two are or are not equivalent? If they are, how would you compute the CDVT parameters from the token bucket parameters (average rate, token bucket size)?
7. Review question: What are the three principal components of a QoS system for the Internet?
8. Review question: Why is "fair sharing" not optimal for many real-time applications?