The assignment is done in groups of two students. After the assignment has been
accomplished, please demonstrate it to some of the assistants. After the assistant
has verified the functionality of your implementation, you are free to leave. Before
leaving, please send your source codes with the list of the group members and
contact information by email to:
firstname.lastname@example.org. (group nr assignment) (email or possibly optima?)
The assistants are available until 18:00, but you can continue after that as well.
If you finish your assignment after 18:00, you can demonstrate the functionality next
day. (deadline: next assignment beginning)
- RFC3621: SIP: Session
- RFC2327: SDP: Session
- The recommended programing languages for all assignments are Java and C/C++.
You can also use Python if you like, but in that case you have to find some libraries
by yourself. The programming style guidelines apply.
- The default programming environment for all assignments is Linux (through Wmware),
but you can also use your own laptop with your preferred OS if it supports IPv6 and
has a webcam.
In this assignment, your task is to add a SIP User Agent to the video sender/receiver
application developed in the previous assignment, to open and close on-demand video streaming sessions. We are aware that using RTP and SIP is a bit artificial way to stream a file over the network. A realtime video source (such as a live sport event) instead of a file would be more reasonable in this scenario.
- You should support a simple SIP URL of the form sip:user@ip_address.
- You only need to support SIP on UDP ports 5060 (caller) and 5061 (callee). (Yes, we know using port 5061 is a cheat to make it possible to test the software in localhost). Use separate port for RTP traffic.
- Only the INVITE and BYE requests and needed response codes (for accepting and terminating calls) are needed
(the 180 Ringing and ACK messages, that are normally used in session initiation, are not needed).
- You can send the response to the original source IP adddress and port (ignoring
the Via header completely; this is again a cheat).
- Authentication and SIP registration (REGISTER) are not required. Timers are not required (no message loss assumed).
- The required SIP message-syntax support is greatly simplified. Only the headers
shown in SIP INVITE example need to
be generated at the sender and parsed in the receiving end.
In real SIP, the allowed syntax of header field values is quite complex. However, you only need to parse
that kind of syntax
that is shown in the example
(for each header field type). Also, you can hardcode the "tag" and "branch" parameters.
- The SDP offer and answer are in the SIP INVITE request and 200 OK response messages, respectively. You only need the mandatory SDP elements (
s=), and two additional elements:
m= to carry media type & port, and
i= to carry the filename information. If the requested file is not
i= element is used to carry an error message in the SDP answer. You can define the error message in
i= by yourself. (again, a hack that would not
be used in realtime streaming).
- You should build either a command-line interface (if using C/C++), or
a simple GUI (if using Java) to play a remote video file at a local computer. For command-line interface, something like
get movie.mjpeg sip:user@host should be sufficient. The UI should provide similar functions.
- After successful session startup, The callee's application should start streaming the MJPEG video, and playing it back at caller's UA, and stop the streaming after
hangup (BYE) from caller. For plain C and Python groups, storing the media to a file at the receiving end is enough. The callee (server) should automatically hangup after the file is
completely streamed to caller.
- You only need to support one stream at a time.
When finished, demonstrate your application to an assistant and capture the SIP/RTP traffic using packet
sniffer, such as WireShark or tcpdump.