Chapter 2 Background
2.4 SIP Package
Communication using SIP (Figure 3) comprises of series of messages. Messages can be transported independently by the network. Usually they are transported in a separate UDP datagram each. Each message consist of “first line”, message header, and message body, and patched with SDP message (Fig. 4). The first line identifies type of the message. There are two types of messages--requests and responses. Requests are usually used to initiate some action or inform recipient of the request of something. Replies are used to confirm that a request was received and processed and contain the status of the processing.
Applications
UDP
RTP/
RTCP
SDP
HTTP SMTP SIP RTSP SAP
TCP/SCTP TCP/UDP
Figure 3 Session Layer Protocol
v=0o=walker 243472520 243472520 IN IP4 192.168.1.1 s=Session SDP
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.1.1.34
Figure 4 SIP Package
A typical SIP request looks like this:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.0.30:5060; branch= z9df3fdf To: <sip:[email protected] >
From: "bob" <sip:[email protected]>;tag=76ff7a07-c091-4192-84a0-d56e91fe104f Call-ID: [email protected]
Max-Forwards: 10
CSeq: 1 INVITE
Contact: <sip:192.168.0.200:9315>
Content-Length: 451 v=0
o= user 28908442526 289088 IN IP4 client.example.com s=session c=IN IP4 192.168.0.100 b=CT:1000
c=IN IP4 192.168.0.200 t=0 0
m=video 51372 RTP/AVP 34 98 a=rtpmap：34 H263 / 90000 a=rtpmap：98 H264 / 90000 m=audio 4006 RTP/AVP 0 97 a=rtpmap：0 PCMU / 8000 a=rtpmap：97 iLBC/8000
The first line tells us that this is INVITE message which is used to establish a session. The URI on the first line--sip: [email protected] is called Request URI and contains URI of the next hop of the message. In this case it , will be host nuk,edu.tw. A SIP request can contain one or more Via header fields which are used to record path of the request. They are later used to route SIP responses exactly the same way. The INVITE message contains just one Via header field which was created by the user agent that sent the request. From the Via field we can tell that the user agent is running on host 192.168.0.30 and port 5060. From and To header fields identify initiator (caller) and recipient (callee) of the invitation (just like in SMTP where they identify sender and recipient of a message). From header field contains a tag parameter which serves as a dialog identifier and will be described in Section 1.6. Call-ID header field is a dialog identifier and it’s purpose is to identify messages belonging to the same call. Such messages have the same Call-ID identifier. CSeq is used to maintain order of requests. Because requests can be sent over an unreliable transport that can re-order messages, a sequence number must be present in the messages so that recipient can identify retransmissions and out of order requests. Contact header field contains IP address and port
on which the sender is awaiting further requests sent by callee. Other header fields are not important and will be not described here.
Table 3 SIP Example with Line-by-Line Description
LINE DECRIPTION
INVITE sip:[email protected] SIP/2.0 The fist line of a SIP request does not contain headers, but starts with the name of the method (INVITE), followed by a space, the request-URI, (In this case, sip：[email protected], which is the destination address of the request), a space, then the current version of SIP (2.0).Each line end with a CRLF (Carriage Return and Line Feed). Note that both RFC 2543 and RFC 3261 SIP implementations are both version (2.0)
Via:SIP/2.0/UDP
192.168.0.30:5060;branch= z9df3fdf
The via header contains the version of SIP(2.0)and the transport protocol(UDP) followed by the IP Address(192.168.0.30) or host name of the originator of the request and the port number (5060, the well-known SIP port number). Any server that forwards the request adds a via header with its own address to the message and the port number ay which it wants to receive responses. The branch parameter is a transaction identifier indicated to be unique be the first seven characters being the cookie z9df3fdf
To: <sip:[email protected] > The To header contains a display name (jane) followed by the URI of the request originator enclosed in angle brackets sip:[email protected]
From: "bob" <sip:[email protected]>;
tag=1234
The from header contains a display name (User A) followed by the URI of the request recipient enclosed in
<sip:[email protected]>. The tag parameter is a pseudo random string generated uniquely for each dialog Call-ID: [email protected] The call-ID header contains a unique identifier for this
call (session). It is usually made up of a locally unique pseudorandom string. All request and responses during the call will contain this same Call-ID
Max-Forwards: 10 The Max-Forward header field is a hop count that is decremented by each proxy server that forwards a
request. When the count goes to zero, a 483 Too Many Hops response is returned
CSeq: 1 INVITE CSeq is the Command Sequence number, which contains an integer (1) a space, then the request method (Invite). Each successive request (command) during the call will have a higher CSeq number. The caller and called parties each maintain their own separate CSeq counts
Contact: <sip:192.168.0.200:9315> Contact contains one or more SIP URIs that provide information for the other party in the session to contact User A
Content-Length: 451 Content-Length is the octet (byte) count of the message body (451) that follows the list of SIP headers and is separated from the headers by a single CRLF.A Content-Length of 0 indicates no message body
Message header is delimited from message body by an empty line. Message body of the INVITE request contains a description of the media type accepted by the sender and encoded in SDP.
Table 4 SDP Offer Example with Line-by-Line Description
LINE DESCRIPTION
V=0 Version – Current version number of SDP(0) –
not used by SIP O = user 28908442526 289088 IN IP4
client.example.com
Origin – Only the version (2890844526) is used by SIP
S = subject subject
C = IN IP4 192.168.0.200 Connection – network (IN for internet), address type (IP4 for IP version 4) and address 192.168.0.200
t = 0 0 Time – start and stop time – not used b SIP m=video 51372 RTP/AVP 34 98
Media – Media type (video), port number (51372), type (RTP/AVP Profile), and number (Profile 34 or 98)
a=rtpmap：34 H263 / 90000 Attribute – rtpmap lists attributes of RTP/AVP video profile 34, include codec (h.263) and
sampling rate (90000 Hz)
a=rtpmap：98 H264 / 90000 Attribute – rtpmap lists attributes of RTP/AVP video profile 98, include codec (h.264) and sampling rate (90000 Hz)
m=audio 4006 RTP/AVP 0 97 Media – Second media type (audio), port number (4006), type (RTP/AVP Profile), and number (Profile 0 or 97)
a=rtpmap：0 PCMU / 8000 Attribute – rtpmap lists attributes of RTP/AVP video profile 0, include codec (PCMU – PCM u-Law) and sampling rate (8000 Hz)
a=rtpmap：97 iLBC/8000 Attribute – rtpmap lists attributes of RTP/AVP video profile 97, include codec (iLBC) and sampling rate (8000 Hz)
2.5 Studies of Load Balance Algorithm
2.5.1 Load Balance Algorithm brief introduction
The load balancing algorithm [26][27][28][29] is also called dispatcher algorithm.
According to the processing capability of all sub-servers, the main-server dispatches the connection requests to the sub-servers. All sub-servers have the difference processing capability. So the number of working load of a sub-server is depended on itself processing capability. The most efficient load balance method of cluster system is distributing client’s request to a server which is least loaded.
Load balancing algorithm is divided into the static algorithm or dynamic algorithm. The main difference of these two algorithms is that the static algorithm has not considered the state of the sub-servers, but the dynamic algorithm has considered the state of the sub-servers.
The following sections recommend two basic static algorithms and two basic dynamic algorithms. And the sections point out that these algorithms have not considered questions.
Table 5 SLB compare to DLB
SLB Algorithm DLB Algorithm
1.Nature Workload is assigned Work load is assigned
at compiled time At Run time 2.Associated
overhead
Lesser overhead More overhead
3.Resource Utilization
Lesser Utilization More Utilization
4.Processor Thrashing
No Thrashing Substantial Thrashing
5.Preemptiveness Non preemptive Preemptive and non Preemptive 6.Predictability More predictable Lesser predictable
7.Adaptability Less More
8.Reliability Less More
9.Response time Less More
10.Stability More Less
11Other Issues
Estimating process execution times and other resource needs at compiled time
Developing techniques to reduce communication overhead
2.5.2 Weighted Round Robin Scheduling
Weighted round robin scheduling will distribute requests in a sequential manner around the real servers. If the capacities of the real servers are different (determined by the weight factor), then more requests are given to those servers. The pseudo code of weighted
round-robin scheduling is as follows:
Table 6 WRR codec Supposing that there is a server set S = {S0, S1, …, Sn-1};
W(Si) indicates the weight of Si;
i indicates the server selected last time, and i is initialized with -1;
cw is the current weight in scheduling, and cw is initialized with zero;
max(S) is the maximum weight of all the servers in S;
gcd(S) is the greatest common divisor of all server weights in S;
while (true) {
return NULL;
} }
if (W(Si) >= cw) return Si;
}
Figure 5 WRR
2.5.3 Weighted Least Connection Scheduling
The weighted least-connection scheduling is a superset of the least-connection scheduling, in which you can assign a performance weight to each real server. The servers with a higher weight value will receive a larger percentage of active connections at any one time. The default server weight is one, and the IPVS Administrator or monitoring program can assign any weight to real server. In the weighted least-connections scheduling, new network connection is assigned to a server which has the least ratio of the current active connection number to its weight. An example of WLC like table 7.
Table 7 WLC codec
Supposing there is a server set S = {S0, S1, ..., Sn-1}, W(Si) is the weight of server Si;
C(Si) is the current connection number of server Si;
CSUM = ΣC(Si) (i=0, 1, .. , n-1) is the sum of current connection numbers;
The new connection is assigned to the server j, in which
(C(Sm) / CSUM)/ W(Sm) = min { (C(Si) / CSUM) / W(Si)} (i=0, 1, . , n-1), where W(Si) isn't zero
Since the CSUM is a constant in this lookup, there is no need to divide by CSUM, the condition can be optimized as
C(Sm) / W(Sm) = min { C(Si) / W(Si)} (i=0, 1, . , n-1), where W(Si) isn't zero
Since division operation eats much more CPU cycles than multiply operation, and Linux does not allow float mode inside the kernel, the condition C(Sm)/W(Sm) > C(Si)/W(Si) can be optimized as C(Sm)*W(Si) > C(Si)*W(Sm). The scheduling should guarantee that a server will not be scheduled when its weight is zero. Therefore, the pseudo code of weighted least-connection scheduling algorithm is
for (m = 0; m < n; m++) { if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (C(Sm)*W(Si) > C(Si)*W(Sm)) m = i;
}
return Sm;
} }
return NULL;
Figure 6 WLC
2.5.4 Hash Over Called/ From URI/ To URI/ Request URI
In table 8 and table 9 are an example of hash over to uri. This algorithm will accord to the to user URI / from user URI, to decide which server is to serve the task. Below is the fragment of the hash algorithm. When the number runs through this function, the function will transform the number into an integer h, and then returns the h back to the origin called function.
Table 8 Hash function I
unsigned int ds_get_hash(str *x, str *y) {
char* p;
register unsigned v;
register unsigned h;
if(!x && !y)
return 0;
h=0;
if(x) {
p=x->s;
if (x->len>=4) {
for (; p<=(x->s+x->len-4); p+=4) {
v=(*p<<24)+(p[1]<<16)+(p[2]<<8)+p[3];
v=(*p<<24)+(p[1]<<16)+(p[2]<<8)+p[3];
h+=v^(v>>3);
When it comes to decide the destination server, it will divide with the number of the real server, and decide which server is to serve the task by it’s remainder. Below is the fragment
of the program code.
Table 9 Hash function II
int ds_select_dst(struct sip_msg *msg, int set, int alg, int mode) {
int idx, i, cnt;
unsigned int hash;
int_str avp_name, avp_val;
if(msg==NULL) {
LOG(L_ERR, "DISPATCHER:ds_select_dst: bad parameters\n");
return -1;
}
if(_ds_list==NULL || _ds_index==NULL) {
LOG(L_ERR, "DISPATCHER:ds_select_dst: no destination sets\n");
return -1;
}
if((mode==0) && (ds_force_dst==0)
&& (msg->dst_uri.s!=NULL || msg->dst_uri.len>0)) {
LOG(L_ERR,
"DISPATCHER:ds_select_dst: destination already set [%.*s]\n", msg->dst_uri.len, msg->dst_uri.s);
return -1;
}
Figure 7 DHS
Figure 8 SHS 2.5.5 Random
Just like the literal meaning, it decides the real server without any rules. It just picks a real server randomly. Figure 9 is an example of random.
Figure 9 Random
2.6 Load Balance Architecture Used In Telecommunication
In the previous section was some popular methods used for load balance, but most are used for WEB server load distribution except DHS/SHS, in this section we will talk about some methods used and already implement for telecommunication environment.
2.6.1 SBC-SAG
SBC-SAG like in Figure 10 is an extension of SBC(Session Border Controller)[30]. SBC is a VoIP session-aware device that controls call admission to a network at the border of that network. Optionally (depending on the device), it can also perform a host of call-control functions to ease the load on the call agents within the network.
The Signaling SBC function (SBC-SIG) controls access of VoIP signaling messages to the core of the network, and manipulates the contents of these messages. It does this byacting as a Back-to-Back User Agent (B2BUA).
The Media SBC function (SBC-MEDIA) controls access of media packets to the network, provides differentiated services and QoS for different media streams, and prevents service theft. It does this by acting as an RTP proxy.
SAG group SPR: SIP Proxy and Register AS: Authentication Server
OpenSER is a SIP proxy server, it can decide if it wants to stay in the loop or not. If not, OpenSER will provide the user agents with the information they need to contact with each other, afterwards, the SIP messages will go directly between the two user agents. SIP can also include additional information, for example, related to how to set up a call with an audio or video stream (called SDP, Session Description Protocol). The SDP information will result in one or more RTP streams (or sessions) to be set up, normally directly between the two user agents. OpenSER will NEVER participate in the RTP stream. RTP streams are by nature bandwidth and processing intensive. However, as we will describe later, OpenSER can make sure that a third party application like a B2BUA or RTP Proxy can become the middle man.
You can distribute the load, by distributing the task to several RTP servers,
Figure 11 Openser with RTPproxy
2.6.3 DNS-Based Architecture
Considering SIP server failover techniques based on the clients, DNS (Domain Name Service), database replication and IP address takeover, and load sharing techniques using DNS, SIP identifiers, network address translators and servers with same IP addresses.
The two-stage reliable and scalable SIP server architecture shown in figure 12, which the first stage proxies the request to one of the second stage server group based on the destination user identifier. As in figure 13, is a simple call flow of the two-stage architecture. Using DNS is a way to offer redundancy since it does not require network co-location of the servers. For example, one can place SIP servers on different networks. With IP address takeover and NATs, that is rather difficult. Such architecture combines DNS, server redundancy, and the identifier-based load sharing in this architecture two-stage reliable and scalable server architecture that can theoretically scale to any capacity.
Figure 12 Two-stage reliable and scalable architecture
Figure 13 Example message flow
2.7 Analyze And Comparison
Like in table 1, we compare the methods which mentioned above with our thesis.
A. Complexity of the system：
The complexity of SBC-SAG is much higher than the others, caused by the various elements included in the architecture. Although based on DNS architecture isn’t complex as SBC-SAG, but the specialized knowledge needs to be understood. OpenSER
architecture is similar to our architecture, using SIP proxy as the entrance of the system, and distributes the information of RTP to other media server.
B. System extension：
DNS-based and our architecture are all translated by SIP protocol, cause them to combine with other SIP services, the slave system which wish to integrate with the system can be SIP IPPBX(Private Branch eXchange), providing such as voice mail、number plan or other phone related work, but OpenSER with RTP architecture is using client-server protocol, due to this reason, it can not integrate with other services. Base on SBC architecture, the protocol that is used between SAG and MCC is h.248, so the media server that’s under SBC architecture must support h.248, so SBC is not easy to integrate with other SIP service.
C. Transmission mode：
Our system and OpenSER both are able to transmit by peer-to-peer or client-sever mode, due to the environment which UA is in, if both are in public network, choosing peer to peer as transmission mode, the load of the server can than be reduced.
D. Way to distribute：
Our system can distribute the load to appropriate server by the status of the sever, even if the server unexpected shut down, or the sever unexpected overload, these will all be notified in our architecture, but OpenSER with RTP proxy distribute the load by its weight, the load will be distributed by turns, and SBC-SAG will only distribute the load to the next server when overload is detect, the NMC will look for a new MCC when overload occurs, but in this time, it will cause the session initial to finish a bit longer. A simple comparison is shown in table 10.
Table 10 Architecture Comparison Multi Server OpenSER/RTP
proxy
SBC/SBC-SAG DNS Based SIP architecture
Complexity LOW LOW HIGH LOW
Extension HIGH LOW LOW MIDDLE
Transmission Peer-to-peer/
client-server
Peer-to-peer/
client-server
Peer-to-peer Peer-to-peer/
client-server
Protocol SIP SIP/customer
protocol
SIP/h.248 SIP
Distribute Efficient Distribute by weight
If overload, NMC will assign a new MCC
SRV records saved in DNS
Chapter 3 Adaptive Load Balance Architecture
Chapter 3
Adaptive Load Balance Architecture
3.1 Design Issue
By time to time, the working ability of the hardware equipment has increased, and the cost of a high performance computer is cheaper, therefore, it is a waste having a single machine working only on one or two tasks. On the other hand, with more than a job working on a single computer, the more computers you can save to work for a job, which means we can save money from buying new computers. Moreover, with the popular of VM(Virtual Machine), more and more company has been trying to fit different services into a single machine.
Although multiprocessing has become more and more popular, but due to this growth, we became facing more and more implicit issues. First, security, the health of the computer has been threatened, cause by the reason of more than one port need to be opened for multi services,. Second, load of CPU and memory or other parameter in a multiprocessing computer, the instant time or in a short period of time, the computer might be kidnapped to do some particular work, and ignore other works which need to be done. Third, shutoff、
overloaded caused by multiprocessing, dealing with several tasks at the same time might cause the computer overload or unexpected shutoff. Although it seems like multiprocessing might be facing a great danger, but with a well planed management, these problems can be solved easily.
3.2 System Scheme
3.2.1 System Architecture
The master SIP proxy is the entrance of our system, providing both peer to peer and client-server mode, according to user’s situation, the service mode will be changed dynamically. Relying on the integration of the slave servers, the capability to distribute the server load and the RTP flow, and other telephony functions are provided.
Like in figure 14 when both users are in public network, the master proxy will let both user
Like in figure 14 when both users are in public network, the master proxy will let both user