Background

The P2P phenomenon has radically changed the way in which everyone looks at the Internet and also aroused people’ concern in day-to-day life.

■ P2P (Peer-to-Peer)

This P2P revolution has soon reached applicative areas that were believed to be strongholds of the client-server model, such as data transmission and storage, CPU computing sharing, search engines, instant-message, massive multi-participant online world simulations, Voice/Video over IP and many other fields.

For live streaming applications, the way of media broadcasting over the networks is usually a client-server mode. In the client-server model, clients connect to server and receive directly from the server. However, it is very expensive and causes many serious problems such as bandwidth, processing power, system resource and scalability.

The P2P has some characteristics: (1) user to user, (2) either side can initiate a session, (3) equal responsibility, and in fact (4) two peers on a P2P system often require contents from third others.

■ IP multicast and Application-layer multicast

The IP Multicast service model extends the Internet delivery service for efficient multi-point packet delivery. Figure 1-1 shows the IP Multicast Service models, the concept of it was to diminish the transmission of duplicated packets over Internet routers.

Figure 1-1 IP Multicast service model

However, in spite of a decade of research on multicast protocols and applications, a globally deployed multicast service is nowhere in sight, hindered by multitudes of problems such as routers management, lack of a robust multicast routing protocol between local (inter-domain) routers, scalability, deployment, combination with heterogeneous networks, and support for high layers functionality inclusive of retransmission, flow and congestion control. Following we summarize the drawbacks of IP multicast.

First, IP Multicast requires routers to maintain per group state, which not only violates the “stateless” architectural principle of the original design, but also introduces high complexity and serious scaling constraints at the IP layer.

Second, IP Multicast is a best effort service, and attempts to conform to the traditional separation of routing and transport layers that have worked well in the unicast context. However, providing higher level features such as reliability, congestion control, flow control, and security has been shown to be more difficult than in the unicast case.

Finally, IP Multicast needs to change at the infrastructural level, and slows down the pace of deployment.

■ SIP (Session Initiation Protocol)

SIP [1] is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. SIP was modified from HTTP (Hypertext Transfer Protocol), had the same syntax and format with HTTP, high modifiability, defined in Request for Comments (RFC) 2543 by a working group of Internet Engineering Task Force (IETF), and a new SIP RFC 3261 has also been produced.

SIP defines five types of network entities: (1) user agent client (UAC), (2) user agent server (UAS), (3) registrar and location server, (4) redirect server, (5) proxy server. A SIP UAC can send SIP requests to UAS directly or through one or more proxy servers. Registrar and location server is used to record the addresses mapping of each SIP users queried by proxy or redirect servers. When receiving a SIP request, a redirect server responds a caller’s SIP request with the callee’s real location (in the form of SIP URL). In this thesis, we will combine the (1), (2), and (4) into a SIP UA, and a relay server is also included.

■ SDP (Session Description Protocol)

SIP uses SDP [14] in an answer/offer mode. A caller sends an INVITE with an SDP description that describes the set of media formats, address, and ports (for different media sessions) that the caller is willing to use. This set of media formats comprises an offer by the calling party. The called party responds with an SDP description that aligns with the offered SDP description, but which includes an acceptance or rejection of each of the offered media formats. The result of this exchange is an agreement between the two parties as to the types of media they are willing to share.

SDP is specified in RFC 2327 entitled “SDP: Session Description Protocol”.

Nowadays, a number of modifications to the protocol have been suggested such as RFC 3266 entitled “Supporting for IPv6 in Session Description Protocol (SDP)”

obsoletes RFC 2327 by supporting IPv6, RFC 3264 entitled “An Offer/Answer Model with Session Description Protocol (SDP)” updates RFC 2543 with an Offer/Answer model.

SDP simply provides a format for describing session information to potential session participants. Basically, a session is comprised of a number of media streams (voice/video/text/application…). Therefore, the description of a session involves the specification of a number of parameters related to each of the media streams.

Parameters are divided into two parties: session-level parameters and media-level parameters. Session-level parameters include information such as the name of the session, the originator of the session, and the time(s) that the session is to be active.

Media-level parameters include the media type, port number, transport protocol, and media format.

Because SDP simply provides session descriptions and does not provide a means for transporting or advertising the sessions to potential participants, it must be used in conjunction with other protocols (such as SIP). For example, SIP carries SDP

information within the SIP message body.

Similar to SIP, SDP is a text-based protocol, utilizing the ISO 10646 character set in Unicode Standard Transmission Format (UTF)-8 encoding (RFC 2044). SDP field names use only US-ASCII, and textual information may be passed in any language.

Although the use of ASCII coding in SDP, as opposed to binary coding, is a little bandwidth greedy, SDP is written in a compact from to counteract bandwidth inefficiency.