Peer joins

First, we define an entity: SN, a super node or serving node, is a SIP UA that can relay the signaling and streaming media from the media source to the requester. Every peer in this overlay network has the ability to become a SN in terms of their capabilities such as processing power or network bandwidth, etc.

When a SIP UA wants to receive the streaming media, it has to first contact the media source or to obtain a peer list. The media source receives the request message and determines in terms of its capabilities whether to accept this request or respond with a peer list to ask the new coming peer choosing another peer as its SN. If the selected SN has enough capacities, it will accept this call, otherwise, it sends a response with children peers’ information from its peer list to the new coming peer, and these steps are continuous until the new coming peer finds one SN with the shortest routing path through it.

We use SIP for our signaling control and combine some behavior of SIP servers (e.g., redirect server and relay server) into the original SIP UA. Our join algorithm is almost implemented and accomplished on the “Peer layer”.

2.2.1 Joining Peer accepted by the source/SN

Figure 2-1 illustrates the signaling flow when the media source/SN accepts UA1’s request in terms of its capabilities. Both the new coming peer UA1 and the source/SN should run a ping echo routine to obtain the numbers of hops and RTT between each other and record this information into the peer list. Using the peer information one can know how far the routing path to the source of each peer.

Figure 2-1: The source/SN accepts UA1’s request

After receiving the SIP ACK message, the source/SN joins UA1 to its RTP streaming member list. Then the new coming peer UA1 can obtain media streaming from the source/SN.

2.2.2 Joining Peer forwarded by the source/SN

If the source/SN has up to its capabilities or maximum serving degrees, it can forward this request message to another peer which is selected by random policy, round-robin policy, or locality policy. Figure 2-2 shows the signaling flow of this method.

There are various policy in common use proposed by [16], (1) Random policy:

the source/SN randomly chooses a peer from its peer list; (2) Round-Robin (RR) policy: the source/SN chooses a peer with maximum surplus serving degrees, each node requires some state information of others; (3) Smart-placement policy: the

source/SN chooses a closest node; (4) Knock-downs policy: If the requesting node is closer to the source/SN node ( or in terms of network bandwidth), the source/SN node will accept the requesting node as its child, and redirect the farthest node.

Figure 2-2 The source/SN forward the request to PeerA

This method can be used in case of UA1 is not powerful to become a SN (this can be accomplished by adding another parameter in the SIP header to describe joining peer’s serving degrees). We may want this kind of peer to be a leaf in the overlay network because it cannot serve anymore. Therefore, the source/SN can select a peer with the longest path to the source and forward to it. In next section, we will describe how to select the best SN for each peer that can also become SN in the overlay network.

2.2.3 Joining Peer redirected by the source/SN

Figure 2-3 The source/SN redirect with SIP 302 Move temporarily

The selected SN close to the source/SN may not close to UA1 peer. Our main goal is to find a SN with shortest routing path from the source, and it is difficult for forwarding method. In addition to forward by the source/SN, we can also use redirection mechanism.

Figure 2-3 shows the signaling flows when the source/SN rejects the INVITE request from UA1 and sends a redirect response message with the peer information.

The 302 Moved temporarily message is used to tell UA1 that the source/SN cannot accept this request in terms of its capabilities and provides its children peers to UA1 for choosing. The reasons for only sends children peer are that the source/SN presumes UA1 already knows about some peers and from these peers UA1 can choose a best one from them. These children peers’ information are packeted into the SIP 302 Moved_Temporarily response message in the form as illustrated in Figure 2-3:

“Contact:SIP_URL;h=[ Hops to the source];r=[ RTT to the source]\r\n”

At the peer layer, UA1 parses the message and extracts peers’ information from the response message, stores to peer list; it also executes an ICMP echo routine iteratively and compares with the peers already in its peer list to find a SN with shortest path to the source. With the ICMP echo function, if the remote peers are reachable they will copy the original data packets to a serious of reply packets and send them back to the echo requesting node.

When receiving these replies packets, we calculate the round-trip time (RTT) by the difference from the first sending packet to latest receiving one and numbers of hops between. Every computer implements the ICMP echo function, so we can use this to measure the network state. Therefore, we can choose the peers with lowest hops between and lowest transmission time to contact. Because we have known the numbers of hops between the selectable serving peers and the source from the SIP 302 response message, store them to each “Hops2Source” of specific peer data structure, after ICMP echo function we can obtain the “Hops2Peer” information of each. Adding “Hops2Source” and “Hops2Peer” of each peer and selecting the minimum one. If the selected SN accepts this request, setting UA1’s global variable with them.

(1) g_Hops2Source = SN.Hops2Source + SN.Hops2Peer + 1;

(2) g_RTT2Source = SN.RTT2Source + SN.RTT2Peer + 1

In next section, we will describe our algorithm in more detail by using a simulation example.