Project: Python Video Conferencing Client - pyVCC Adrian Beutner1 and Christoph Kuhr2 Summer Semester 2013 [email protected] [email protected] Abstract In this document, the concept and design of the Python Video Conferencing Client (pyVCC) and it's development process is described. PyVCC utilizes the Session Initiation and Descrip- tion Protocols (SIP, SDP) to establish a session between two clients and a call server (CS). The two pyVCC clients share their audio and video (AV) data with the Realtime Transport Protocol (RTP). Python Video Conferencing Client Content Beutner - Kuhr Contents 1 Introduction 2 1.1 Workpackages and Schedueling . .2 1.2 Project Description . .3 2 Concept and Design 3 2.1 Communication Concept . .3 2.1.1 SIP and SDP - Kuhr . .3 2.1.2 RTSP and SDP- Kuhr . .5 2.1.3 RTP - Beutner . 10 2.2 Callserver and MCU - Beutner . 10 2.3 Software Design . 11 2.3.1 libVLC . 11 2.3.2 SIPSimple Client SDK . 12 2.3.3 UML . 13 2.4 Proof of Concept . 15 2.4.1 Virtualbox - Firewall - Beutner . 15 2.4.2 Callserver and MCU - Beutner . 15 2.4.3 libVLC RTSP Streaming . 15 2.4.4 SIP Simple SDK - Blink . 19 3 Discussion 21 3.1 Callserver and MCU - Beutner . 21 3.1.1 OpenVCS and Asterisk . 21 3.1.2 Medooze . 21 3.2 pyVLCC . 22 3.2.1 libVLC . 22 3.2.2 SIP Simple SDK . 22 3.2.3 RTSP SDP vs SIP SDP . 22 3.2.4 Python . 22 3.2.5 Performance . 23 pyVCC i Python Video Conferencing Client Content Beutner - Kuhr List of Figures 2.1 SIP Trapezoid [5, p. 4] . .3 2.2 SDP Body Scheme [4, p. 30] . .4 2.3 TEMP SIP Body Fields [4, p. 30] . .4 2.4 TEMP Field Values [4, p. 31] . .5 2.5 RTP Wireshark Capture . 11 2.6 Use Case Diagram . 13 2.7 Activity Diagram pyVCC . 14 2.8 Component Diagram pyVCC . 14 2.9 OpenVCS Communication . 15 2.10 pyVLCC GUI . 20 2.11 Blink GUI . 20 3.12 SIP Signaling Wireshark Capture . 23 3.13 RTSP Signaling Wireshark Capture . 23 3.14 SIP SDP Wireshark Capture . 23 3.15 RTSP SDP Wireshark Capture . 24 List of Tables 3.1 This table shows some data . 24 pyVCC 1 Python Video Conferencing Client Introduction Beutner - Kuhr 1 Introduction 1.1 Workpackages and Schedueling A list of single worksteps to perform: MS2 04/18/2013 Concept and Design: • Understand RTP (Beutner) • Understand SIP, RTSP, SDP, libVLC , SIPSimple Client SDK (Kuhr) • Develope communication concept (Beutner) • Design software (Kuhr) MS3 06/27/2013 Implementation and Verification: • Install call server(Beutner) • Implement software (Kuhr) • Install media control unit (Beutner) • Test software (Beutner, Kuhr) MS4 07/11/2013 Conclusions and Presentation: • Conclusions (Beutner, Kuhr) • Presentation (Beutner, Kuhr) pyVCC 2 Python Video Conferencing Client Introduction Beutner - Kuhr 1.2 Project Description PyVCC is a video conferencing client written with the Python programming language. The application script pyVCC.py is executed within the Python interpreter CLI. Thus, the inter- action and debugging iniformation is printed to the Python CLI. The required functionality for SIP sessions management shall be implemented with the SIPSimple Client SDK [?]. The SIPSimple Client SDK provides an interface for external codecs, called IMediaStream. The RTP AV data transport is implemented with the libVLC library and is called via the IMedi- aStream API by the SIP components. libVLC capture the local AV data, streams it to the remote client and plays back the AV data stream received by the remote client. With the Session Initiation and Description Protocols (SIP, SDP), two pyVCC Clients es- tablish a session, managed by a Call Server (CS). The Call Server shall be realized with the OpenSource Application openVCS. OpenVCS provides SIP functionaity along with a MCU (Multipoint Control Unit). The MCU manages RTP AV streams encoded with the h264 codec for video and the G711 codec for audio. 2 Concept and Design 2.1 Communication Concept 2.1.1 SIP and SDP - Kuhr SIP describes two types of communication, the most common way with the so called SIP trapezoid and communication which is forwarded to a Multipoint Control Unit (MCU). In the most commonly used case, Voice over IP, the user clients send and receive their SIP messages to and from their next SIP Proxy. The SIP Proxy forwards the SIP messages to the appropriate remote SIP Proxy to reach the remote URI. After the session is initialized with the SDP parameters, the audio data ist transported, via RTP, to the remote user client based on a peer-to-peer connection on different ports. Figure 2.1: SIP Trapezoid [5, p. 4] The second case is used for video conferencing environments, where different RTP AVC Profile streams, the amount depends on the users registered to the processed session, are pyVCC 3 Python Video Conferencing Client Introduction Beutner - Kuhr mixed to one RTP AVC Profile stream. The mixed stream is then return to each conference participant. This concept is described in detail in chapter 2.2 Callserver and MCU. The SDP part of a SIP INVITE message containes different lines of parameters to nego- tiate a RTP AVC Stream. Figure 2.2 shows the rule, by which each line of the SDP body is build. In figure 2.3, an example for a SDP body is given. Figure 2.2: SDP Body Scheme [4, p. 30] Figure 2.3: TEMP SIP Body Fields [4, p. 30] pyVCC 4 Python Video Conferencing Client Introduction Beutner - Kuhr The fields shown in figure 2.3 have the following meaning: Figure 2.4: TEMP Field Values [4, p. 31] 2.1.2 RTSP and SDP- Kuhr A RTSP stream uses HTTP like signaling to negotiate session parameters as well as SIP. But the signaling with RTSP is different. The mechanism to start a session uses a different data transport for signaling and media transmission, like with SIP signaling. For RTSP port 8554 is used over TCP and the ports 9000 and 9001 are used for RTP audio and video transport over UDP. Mandatory to start a presentation stream, which means a combination of for example audio and video streams, is a presentation description file. This presentation description file is provided as a SDP file. It has to be communicated, over a seperate channel like email or a webpage, before the actual start of the session. Once the servers presentation file is known, the requesting user client sends an OPTION request to the server. It contains information about the requested presentation stream by the preshared SDP file and the used user client. The server responses with a 200 OK message. In this message the server gives information about the server application that is providing the presentation stream. Also a field named PUBLIC is contained in the response. Th field PUBLIC is a list of the operations, which are implemented by the server. The most important operations, taken from the RTSP RFC2326 [7, p. 11f], are listed below: pyVCC 5 Python Video Conferencing Client Introduction Beutner - Kuhr SETUP: Causes the server to allocate resources for a stream and start an RTSP session. PLAY and RECORD: Starts data transmission on a stream allocated via SETUP. PAUSE: Temporarily halts a stream without freeing server resources. TEARDOWN: Frees resources associated with the stream. The RTSP session ceases to exist on the server. RTSP methods that contribute to state use the Session header field (Section 12.37) to identify the RTSP session whose state is being manipulated. The server generates session identifiers in response to SETUP requests (Section 10.4). The most important RTSP messages and their responses are listed below: DESCRIBE: The DESCRIBE method retrieves the description of a presentation or media object identified by the request URL from a server. It may use the Accept header to specify the description formats that the client understands. The server responds with a description of the requested resource. The DESCRIBE reply-response pair constitutes the media initialization phase of RTSP. Example: C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg RESPONSE with SDP S->C: RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 376 v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Mark Handley) pyVCC 6 Python Video Conferencing Client Introduction Beutner - Kuhr c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 m=whiteboard 32416 UDP WB a=orient:portrait The DESCRIBE response MUST contain all media initialization information for the resource(s) that it describes. If a media client obtains a presentation description from a source other than DESCRIBE and that description contains a complete set of media initialization parameters, the client SHOULD use those parameters and not then request a description for the same media via RTSP. SETUP: The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a SETUP request for a stream that is already playing to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error "455 Method Not Valid In This State". For the benefit of any intervening firewalls, a client must indicate the transport parameters even if it has no influence over these parameters, for example, where the server advertises a fixed multicast address.