Finite State Machine based Flow Analysis for

WebRTC Applications

Sergej Alekseev

Fachhochschule Frankfurt am Main

University of Applied Sciences

Nibelungenplatz 1

60318 Frankfurt am Main, Germany

email: alekseev@fb2.fh-frankfurt.de

Christian von Harscher

Fachhochschule Frankfurt am Main

University of Applied Sciences

Nibelungenplatz 1

60318 Frankfurt am Main, Germany

email: harscher@stud.fh-frankfurt.de

Marco Schindler

Fachhochschule Frankfurt am Main

University of Applied Sciences

Nibelungenplatz 1

60318 Frankfurt am Main, Germany

email: mschindl@stud.fh-frankfurt.de

Abstract—This paper presents an approach for analysing thebehaviour of WebRTC - based applications, typically being usedfor direct audio or video browser-to-browser communication.The approach is based on finite-state machines derived fromthe WebRTC specification. A state change of a WebRTC peerinvolved in the communication process generates an event whichis collected and analysed. We present algorithms for analysingthe collected events and generating various statistics about aWebRTC session. Finally we present some experimental resultsbased on the library named WebRTCStateAnalyser. This self-madelibrary is an open source project which is available under theApache License.

Index Terms—WebRTC, Finite State Machine, Pattern Match-ing

I. INTRODUCTION

WebRTC (Web Real Time Communication) is a commu-

nication standard developed by the W3C [1] in close coop-

eration with the RTCWeb standard developed by the IETF

[2]. WebRTC offers developers the ability to create web

multimedia applications for real time communication without

plugins, downloads or installations. In this paper we present

an approach which allows to represent the state of a WebRTC

based application by collecting and analysing the state events.

The field of application could be e.g. error handling, collecting

statistics, detection of fraud attempts or analysis of user

behaviour.

The main idea of the proposed approach is to collect events

generated by WebRTC peers when a change of a state occurs.

For modelling the possible WebRTC states and flows we derive

the finite-state machines from the WebRTC specification [1].

The state change events are generated asynchronously by

WebRTC peers and this process does not have any influence on

the overlaying application. The collected events are validated

by the proposed algorithm to detect illegal state changes

according to the WebRTC specification [1]. The second al-

gorithm recognizes the predefined sequences of event state

changes to create various statistics.

To evaluate our approach, the open source library WebRTC-

StateAnalyserhas been implemented and tested with various

WebRTC applications. The implemented library may be easily

integrated into any WebRTC application and is available as an

open source project. We present some experimental results and

statistics based on this implementation at the end of the paper.

II. RELATED WORKS

The idea to use finite-state machines for modelling the

network protocols and distributed systems is known for a

long time. Communication protocols are often modelled as

a network of two finite-state machines that communicate by

exchanging over unbounded channels [3], [4], [5]. There are

a lot of publications dealing with finite-state model based

tests [6], [7] which are partially related to our approach. Very

close to our approach are publications for diagnostics and

fault localisation problems based on finite-state machines [8],

[9]. Some recent publications are [10] and [11]. However, our

approach has its focus on collecting and examining statistics

for WebRTC based applications.

The second algorithm (Event Sequence Pattern Matching)

in this paper uses the structural comparison to recognize an

event sequence. There are a lot of known algorithms for text

pattern matching. The Boyer-Moore [18], Quick-search [19] or

Horspool [20] algorithms and their variants are widely used in

the software industry. They are in general close to our algo-

rithms, but not suitable to perform the structural comparison.

For our approach, we adapted the path profiling algorithm

published by Ball and Larus [17], originally developed for

program profiling. The essential idea behind the algorithm is

to identify sets of potential event sequences which are encoded

as integer values. The comparison costs are thereby reduced

to a minimum. The costs are limited to the calculating of an

integer value for an event sequence to be analysed.

III. WEBRTC FINITE STATE MACHINES

Finite-state machine (also called a finite-state automaton)

provides a simple computational model for modelling software

systems. A finite-state machine (FSM) is defined formally as

a 3-Tuple, (V, σ,E) consisting of a finite set of states V , a

finite set of input symbols σ and a transition function E :V × σ → V . A FSM is usually represented as a directed

graph G = (V,E), where V is a set of nodes and E is a

set of edges. The finite set of input symbols σ (corresponding

actions) is assigned to the edges of the Graph.

978-1-4799-4233-6/14/$31.00 ©2014 IEEE 1

We derive from the WebRTC specification [1] following

finite-state machines:

• Signaling state machine S = (Vs, Es) (section III-A).

• Gathering state machine G = (Vg, Eg) (section III-B).

• Connection state machine C = (Vc, Ec) (section III-C).

The specification defines the set of states for each finite state

machine as an enum structure. The sets of transitions (edges)

are derived from the methods or event handlers.

Zs = (s, g, c) (1)

The state of the entire system Zs is defined by the equation

1, where s ∈ Vs, g ∈ Vg and c ∈ Vc.

When the WebRTC peer within a browser has been created

[1], it has a signaling state, an ICE gathering state [14],

and an ICE connection state [14]. The WebRTC peer has

two associated stream sets: a local streams set, representing

streams that are currently sent, and a remote streams set,

representing streams that are currently received. Once the

WebRTC peer has been initialised the methods createOffer,

setLocalDescription, createAnswer and setRemoteDescription

are executed to initialise the connection. The following steps

are performed:

• The WebRTC peer starts gathering ICE addresses and sets

the ICE gathering state to gathering.

• If one or more candidate pairs have been found the ICE

connection state is changed to connected.

• When the WebRTC peer finishes checking of all candidate

pairs the ICE connection state is changed to completed.

• If the ICE connection state is connected or completed

and both the local and remote session descriptions have

received a valid SDP offer / answer pair, the ICE con-

nection state is set to stable.

The next subsections describe the formalisation of the

signaling, gathering and connection state machines.

A. Signaling state machine

To model the signaling state machine the following state

definitions (fig. 1) from [1] are used. The corresponding

enum RTCSignalingState {

"stable",

"have-local-offer",

"have-remote-offer",

"have-local-pranswer",

"have-remote-pranswer",

"closed"

};

Fig. 1. Signaling states and transitions

signaling state machine S is represented in fig. 2.

The state stable is the initial state in which case the local

and remote descriptions are empty and there is no offer/answer

exchange in progress. The execution of methods createOffer

and setLocalDescription will cause the state change from

stable to have-local-offer (fig. 2: transition a ). The methods

createAnswer and setRemoteDescription will change the state

from have-local-offer to stable (fig. 2: transition b). By calling

a❄☛✡ ✟✠have-local-offer ✲c

❄b

☛✡ ✟✠have-remote-pranswer

!!

!!✠b

✻a☛✡ ✟✠stable

❄d

❄g

❅❅

❅❅❘g

✲g☛✡ ✟✠closed

!!

!!✒ g ✻g

✻e☛✡ ✟✠have-remote-offer ✲f

e✻

c❄

❅❅

❅❅■d ☛✡ ✟✠have-local-pranswer

f✻

Fig. 2. Signaling state machine.

the close method (fig. 2: transition g) the connection is closed

and the state is changed to closed. Further transitions are:

• setRemoteDescription(pranswer) (fig. 2: transition c)

• setLocalDescription(answer) (fig. 2: transition d)

• setRemoteDescription(offer) (fig. 2: transition e)

• setRemoteDescription(pranswer) (fig. 2: transition f)

The type pranswer indicates that a description should be

treated as a non final answer.

B. Gathering state machine

The gathering state definitions from [1] are represented in

fig. 3. The state new represents the state of the WebRTC

enum RTCIceGatheringState {

"new",

"gathering",

"complete"

};

Fig. 3. Gathering states

peer before any networking actions have been executed. The

transition from the state new to the state gathering is executed

if the WebRTC peer starts the process of gathering candidates

to setup a connection. The WebRTC peer changes the state to☛✡ ✟✠new

❄☛✡ ✟✠gathering

❄ ✻☛✡ ✟✠complete

Fig. 4. Gathering state machine.

complete if it has completed gathering. Events such as adding

a new interface will cause the state to go back to gathering.

The corresponding gathering state machine G is shown in fig.

4.

C. Connection state machine

The state definitions of the connection state machine from

[1] are represented in fig. 5. The corresponding connection

2

enum RTCIceConnectionState {

"new",

"checking",

"connected",

"completed",

"failed",

"disconnected",

"closed"

};

Fig. 5. Definition of connection states.

state machine C is presented in fig. 6. The state new rep-

resents the state in which a WebRTC peer waits until the

gathering process is completed and all connection candidates

are determined. The state new changes to state checking if the

☛✡ ✟✠new ✲b

✻g

☛✡ ✟✠checking✛a

✲c

❅❅❘g

❄e

☛✡ ✟✠connected ✲d

❄f

❄a

!!✠g

☛✡ ✟✠completed❄

a

!!✠f✻g☛✡ ✟✠failed ✲f

!!✒g

✻a

☛✡ ✟✠disconnected

✻c ✻d

!!❅

❅❅■g

✻a ☛✡ ✟✠closed

Fig. 6. Connection state machine.

WebRTC peer received the remote candidates and is able to

check candidate pairs (fig. 6: transition b). The state connected

is reached after the gathering process is fully completed and a

connection for at least one component has been found (fig. 6

transition c). The state completed is reached after the WebRTC

peer has determined connections for all components (fig. 6:

transition d).

If the WebRTC peer is not able to determine any connections

then the state checking changes to the state failed (fig. 6:

transition e). The state disconnected is reached if the estab-

lished connection is lost for one or more components (fig. 6:

transition f ).

The state closed is reached from any states when the

WebRTC peer is shut down (fig. 6: transition g). Restart of

the WebRTC peer causes that the model changes back to the

state new from any state (fig. 6: transition g).

IV. COLLECTING WEBRTC EVENTS

During the communication process WebRTC peers generate

events asynchronously when the state of a peer has been

changed. The idea of the WebRTC event based state analyser

framework is to implement event handlers which log these

events, store them in a database and then analyse and validate

these events algorithmically. The fig. 7 shows the architecture

of the WebRTC event based state analyser framework. The

event handler interface [1] represents a callback method and

event types as defined in [15]. The integration of the event

handler interface is realised by including the javascript on the

HTML page of the WebRTC application. The code modifica-

tion of the WebRTC application is not necessary.

Fig. 7. WebRTC call state analyser

An event is defined by a unique id, peer id pid, session

id sid, timestamp t and the state of the entire system Zs

according to the equation 1. In the tuple notation an event

can be formalised as:

e = (id, pid, sid, t, Zs), (2)

where the state Zs is an element of the combination of

signaling, gathering and connection states Zs ∈ V s×V g×V c

as described in the section III. The sequences of events are

programmatically derived from the collected raw events. A

sequence of events Q is defined as an ordered set of elements:

Q = {. . . , en, en+1, . . .}, ∀en, en+1 ∈ Q :sidn = sidn+1 ∧ tn < tn+1

(3)

All events in the sequence Q belong to the same session and

are sorted in topological order by the time stamp. The session

id is created at the start of the session. All peers involved into

the same communication process have the same session id. An

example of an event sequence is presented in fig. 8.

V. ANALYSING WEBRTC EVENTS

The analysis of the collected WebRTC events is realized in

two steps. In the first step the sequence of events is validated

for each particular peer that is involved in the communication

process (subsection V-A). In the second step application spe-

cific patterns are recognised by the pattern matching algorithm

(subsection V-B).

A. Validation Algorithm

The sequence of events Q is divided into subsets of events

P [ ] corresponding to each peer as follows:

Q =n⋃

i=1

Pi, ∀pn, pn+1 ∈ P : pidn = pidn+1 (4)

The subset of events P includes events generated by a single

peer and sorted in topological order by the time stamp.

∀pn, pn+1 ∈ P : tn < tn+1 (5)

In fig. 8 we have the first subset P1 with the ids {23,

25, 28, 33, 35, 37, 44} and subset P2 = {24, 26, 27,

3

id pid sid time stamp state = { Vs, Vg, Vc }

23 0x01 0x421ff0d ’03-19-2014 13:27:18.276’ { stable, new, new }

24 0x02 0x421ff0d ’03-19-2014 13:27:18.345’ { stable, new, new }

25 0x01 0x421ff0d ’03-19-2014 13:27:18.678’ { have-local-offer, new, new }

26 0x02 0x421ff0d ’03-19-2014 13:27:18.701’ { have-remote-offer, new, new }

27 0x02 0x421ff0d ’03-19-2014 13:27:18.723’ { have-remote-offer, gathering, new }

28 0x01 0x421ff0d ’03-19-2014 13:27:19.755’ { have-local-offer, gathering, new }

33 0x01 0x421ff0d ’03-19-2014 13:27:20.765’ { stable, complete, new }

34 0x02 0x421ff0d ’03-19-2014 13:27:20.821’ { stable, complete, new }

35 0x01 0x421ff0d ’03-19-2014 13:27:20.987’ { stable, complete, checking }

36 0x02 0x421ff0d ’03-19-2014 13:27:20.998’ { stable, complete, checking }

37 0x01 0x421ff0d ’03-19-2014 13:27:21.067’ { stable, complete, connected }

38 0x02 0x421ff0d ’03-19-2014 13:27:22.126’ { stable, complete, connected }

44 0x01 0x421ff0d ’03-19-2014 13:27:32.567’ { closed, complete, closed }

45 0x02 0x421ff0d ’03-19-2014 13:27:33.663’ { closed, complete, closed }

Fig. 8. Raw Events example

34, 36, 38, 45}. The validation is executed for each subset

P the procedure V ALIDATE EV ENT SEQUENCE to

validate the sequence of signaling, gathering and connection

states. Additionally the combination of states for each event

is validated by the combination validation algorithm.

1) Validating states for a single peer : The following

algorithm demonstrates the validation of events generated by a

particular peer. The method otherend() returns the other state

connected to the given transition and state.✬

✫

✩

✪

VALIDATE EVENT SEQUENCE( Q, FSM )

1 last = NULL;

2 for ( each e ∈ Q in topological order ){3 if ( last != NULL ){4 if (! FIND STATE ( FSM , e.state, last ) ) {5 return false;

6 } }7 last = e.state

8 }9 return true;

FIND STATE( FSM , state, last )

1 for (each incoming edge of state ∈ FSM ) {2 if( otherend(edge, state) == last ){3 return true;

4 } }5 return false;

Fig. 9. Algorithm for validating states for a single peer

The runtime complexity of the procedure

V ALIDATE EV ENT SEQUENCE is O(|Q||E|),where |Q| is the number of processed events and |E| the

number of edges (transitions) of the relevant finite state

machine. Since the number of transition in all machines

is constant, the runtime complexity is O(|Q|). I.e. the two

sequences P1 and P2 from fig. 8 are valid.

2) Validating combination of states: To validate the com-

bination of states for single events, we created a static three

dimensional matrix (fig. 10) representing all combinations of

signaling, gathering and connection states. The values of the

matrix defines if the combination of states is valid (value =

1) or invalid (value = 0). The valid combination of states is

...

[stable], [new], [new] =1

[have-local-offer], [gathering], [new] =1

[have-local-offer], [new], [closed] =0

[closed], [gathering], [new] =0

...

Fig. 10. An excerpt from the combination matrix.

derived from the [1]. I.e. all the events from fig. 8 are valid.

The verification step is to find the appropriate combination and

to read the corresponding value from the matrix. The runtime

complexity of this step is O(|Q|) and depends only on the

number of stored events, because the size of the matrix is

constant.

B. Event Sequence Pattern Matching Algorithm

Pattern-matching is routinely used in various computer

applications, for example, in editors, retrieval of information

(from text, image, or sound). The proposed matching algorithm

matches the sequence of events with a set of predefined

patterns. Each sequence pattern consists of three event state se-

quences Qs, the sequence of signaling states, Qg , the sequence

of gathering states, and Qc, the sequence of connection states.

Some typical patterns of WebRTC events are presented in the

following list:

• Successful session:

Qs = { have-local-offer → stable→ closed }

Qg = { new → gathering → complete }

Qc = { new → checking → connected → completed → closed }

• Session failed:

Qs = { have-local-offer → closed }

Qg = { new → gathering }

Qc = { new → checking → failed → closed }

The direct way to match the pattern is to compare the sequence

of events and the pattern in the forward direction element by

element. This process is repeated for each predefined pattern

until a pattern is matched or not matched. This approach is

commonly known as a brute-force method.

The proposed algorithm is based on structured comparison

and allows to minimise the number of calculation steps. The

4

essential idea behind the algorithm is to identify sets of

potential paths with states which are encoded as integers. For

this purpose the path profiling algorithm ASSIGN LABELS

from Ball and Larus [17], originally developed for program

profiling (fig. 11), is used. The path profiling algorithm works

efficiently for directed acyclic graphs (DAG). Therefore, the

finite state machine has to be transformed into a DAG (fig.

12: line 1). The Ball-Larus algorithm labels edges in a DAG

with integer values, such that each path from the entry to the

exit of the DAG produces a unique sum of the assigned edge

values along that path (fig. 12: line 2). Each sequence pattern✬

✫

✩

✪

ASSIGN LABELS( FSM )

1 for ( each vertex v ∈ V in reverse topological order ){2 if ( v is a leaf vertex ){3 NumPaths(v) = 1;

4 } else {5 NumPaths(v) = 0;

6 for( each edge e = v → w) {7 Val(e) = NumPaths(v);

8 NumPaths(v) = NumPaths(v) + NumPaths(w);

9 } } }

Fig. 11. Ball-Larus-Algorithm for assigning values to edges in a DAG [17].

is represented by an integer value as a sum of three paths:

V al(Qs) + V al(Qg) << 2 + V al(Qc) << 4 (6)

The calculated values are stored in an index table.✤

✣

✜

✢

/* T is an index table of event sequence patterns */

SEQ PATTERN MATCH(Q, FSM , T )

1 val = calculatePathV alue(D,Q);

2 p = getPatternFromIndexTable(val, T );3 return p;

Fig. 12. Sequence Pattern Matching Algorithm

The event sequence to be recognised is interpreted by the

finite state machine. The path value is calculated as a sum

of the transition values (fig. 12: line 3) and the correspond-

ing pattern is determined from an index table by using the

calculated integer value (fig. 12: line 4).

1) Representing event sequences with sums: The connec-

tion finite state machine C (subsection III-C) is transformed

into a DAG as presented in fig. 13. The transformation is done

by removing the back edges and adding the dummy edge EXIT

to derive correct paths for sequences that terminate before

reaching the end state.

The algorithm ASSIGN LABELS (fig. 11) calculates

and assigns values, so each sequence path of 16 possible paths

is represented by an integer value as follows:

For the gathering finite state machine the algorithm

ASSIGN LABELS (fig. 11) calculates and assigns values

of three possible paths and for the signaling finite-state ma-

chine S the values of 17 possible paths. So the maximum

☛✡ ✟✠new ✲2

✲1

✲0

☛✡ ✟✠checking ✲6

❄2

❄

1

✲0

☛✡ ✟✠connected ✲4

❄2

❄

1

✛0

☛✡ ✟✠completed

❄2

✛

1

✛ 0

☛✡ ✟✠failed ✲2

✲1

✲0

☛✡ ✟✠disconnected

✛ 1

✛ 0

☛✡ ✟✠closed

❄0

EXIT

Fig. 13. Transformed Connection FSM with values computed by thealgorithm ASSIGN LABELS in fig. 11.

V al(new → EXIT ) = 0V al(new → closed → EXIT ) = 1 + 0 = 1V al(new → checking → EXIT ) = 2 + 0 = 2V al(new → checking → closed → EXIT ) = 2 + 1 + 0 = 3V al(new → checking → failed → EXIT ) = 2 + 2 + 0 = 4. . .V al(new → checking → connected . . .) = 2 + 6 . . . = 15

number of possible paths (sequence patterns) is calculated as:

16× 3× 17 = 816.

2) Calculating path value for an event sequence: The path

value of an event sequence is calculated by following the

corresponding transition and adding the assigned values to the

path value.

Because the FSMs have been transformed to a DAG, the

cycles have to be removed from the sequence. This limitation

may cause the situation that two different sequence patterns are

reduced to the same template. This limitation is nevertheless

acceptable, because there are only a few use cases where this

situation may occur.

VI. EXPERIMENTAL EVALUATIONS AND ANALYSIS

To evaluate the proposed algorithm we compared the run-

time of the brute-force method (BFM) against the runtime

of the Event Sequence Pattern Matching (ESPM) algorithm.

The input is an event sequence as defined in the equation

2 and a set of templates. A template is an event sequence

which is identified as a specific scenario for an use case (e.g.

successful, failed or canceled session). The maximum possible

number of templates is 816 as calculated in section V-B. The

realistic number of templates in a real application will be

approximately between 10 to 20. The algorithms have been

implemented in Java R© and the tests have been executed on

a computer with an Intel R© 3.4 GHz processor and 8GB of

RAM.

We implemented two tests to evaluate the runtime. In the

first test we executed the BFM and ESPM algorithms with

an event sequence including five events and various number

of templates as input. The table I reports the runtime results

and the diagram (fig. 14) represents the results graphically.

To generate more representative results 1000 iterations per test

have been executed. It is not surprisingly, that the runtime of

the ESPM algorithms stays constant, because it depends on

5

TABLE IRUNTIMES IN µs DEPENDING ON THE NUMBER OF TEMPLATES.

# templates BFM ESPM # templates BFM ESPM

µs µs µs µs

5 620 364 150 2456 359

20 1210 391 400 2896 365

50 1815 368 816 4032 361

5 20 50 150 400 816

0

1,000

2,000

3,000

4,000

# templates

tim

ein

µs

BFM ESPM

Fig. 14. Visualization of the results the table I.

the length of the sequence to be analysed. The runtime of the

BFM grows with the increasing number of templates.

In the second test the input includes the constant number of

templates and event sequences with various number of events.

The test results and graphical visualization are presented in the

table II and the diagram (fig. 15). The result is consistent

TABLE IIRUNTIMES IN µs DEPENDING ON THE LENGTH OF THE SEQUENCE.

# events ESPM PMA # events BFM ESPM

µs µs µs µs

1 998 181 7 2019 829

3 1412 356 9 2102 856

5 1834 611 11 2184 888

1 3 5 7 9 11

1,000

2,000

# events

tim

ein

µs

BMF ESPM

Fig. 15. Visualization of the results from the tabable II.

with the theoretical expectation that the runtime grows by

increasing the length of the sequence. It is interesting to note

that the total time taken by the proposed ESPM algorithm

is always less than the time of the BFM. The reason for

that is the different overhead of comparison and calculation

operations used in the implementation. The runtime increase

curve of both algorithms shows the linear character and stays

absolutely in limit.

VII. CONCLUSION

This paper describes a new approach for analysing the

behaviour of WebRTC-based applications. We presented an

algorithm for validating the collected events which may be

used e.g. to identify implementation errors in a WebRTC-based

application. We also presented an algorithm for recognition

the event sequences which can be used for generating various

monitoring records about a WebRTC session. Finally we pre-

sented some experimental results including the comparison of

the runtime of the new algorithm and the brute-force method.

The results show that the proposed approach and presented

algorithms are suitable to be implemented in all applications

related to the event based analysis.

Our further interests are focused for collecting statistics

from the real WebRTC-based applications, developing new

algorithms for identifying the event sequences containing

loops and creating a concept of a self learning system for

event sequence recognition.

REFERENCES

[1] Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan,WebRTC 1.0: Real-time Communication Between Browsers, Draft 30,August 2013 http://dev.w3.org/2011/webrtc/editor/webrtc.html

[2] H. Alvestrand, Real Time Protocols for Brower-based Applications, IETF,Draft 09, Feb. 2014 http://tools.ietf.org/html/draft-ietf-rtcweb-overview-09

[3] A. Danthine, Protocol Representation with Finite State Machines, IEEE

Transactions on Communications, Vol. 28, No. 4, 1980, pp. 632-643[4] D. Brand, P. Zafiropulo, On Communicating Finite-State Machines, J.

ACM, Vol. 30, No. 2, April 1983, pp. 323-342[5] Sunshine, C., ”Formal Modeling of Communication Protocols”, in Proc.

Conference on Communication in Distributed Data Processing Systems,Technical University Berlin, January 1981.

[6] T. S. Chow, Testing Design Modelled by Finite-State Machines, IEEE

Trans. S.E. 4, 3, 1978.[7] S. Fujiwara, G.v. Bochmann, F. Khendek, M. Amalou, A. Ghedamsi,

Test selection based on finite state models, IEEE Trans. on Software

Engineering, Vol. 17, No. 6, June 1991, pp. 591-603.[8] A. Ghedamsi, G.v. Bochmann, Test result analysis and diagnostics for

finite state machines, The 12-th international conference on distributed

systems, Yokohama, Japan, June 9-12, 1992[9] B. Korel, PELAS-Program error-locating assistant system, IEEE Trans.

on Software Engineering, Vol. 14, No. 9, September 1988[10] W. Grieskamp, Y. Gurevich, W. Schulte, M. Veanes, Generating finite

state machines from abstract state machines, Proceedings of the ACM

SIGSOFT Symposium on Software Testing and Analysis, 2002, pp. 112ff[11] R. M. Hierons, Canonical finite state machines for distributed systems,

Theoretical Computer Science, 2010, pp. 566-580.[12] H. Alvestrand, Google release of WebRTC source code, public-

webrtc@w3.org, 1. Juni 2011[13] F. A. Scherschel, Google proposes VP8 and Opus for WebRTC standard,

The H Open, 31. Juli 2012[14] J. Rosenberg, Interactive Connectivity Establishment (ICE): A Proto-

col for Network Address Translator (NAT) Traversal for Offer/AnswerProtocols, RFC5245, April 2010 http://www.ietf.org/rfc/rfc5245.txt

[15] R. Berjon, S. Faulkner, T. Leithead, E. D. Navara, E. O’Connor; S.Pfeiffer, HTML5 - A vocabulary and associated APIs for HTML andXHTML, W3C , 04 February 2014 http://www.w3.org/TR/html5

[16] M. Handley, V. Jacobson, SDP: Session Description Protocol, RFC2327,April 1998 http://www.ietf.org/rfc/rfc2327.txt

[17] T. Ball, J. R. Larus, Efficient Path Profiling, Proceedings of the 29th

annual ACM/IEEE international symposium on Microarchitecture, 1996[18] R. S. Boyer, J. S. Moore, A fast string searching algorithm, Communi-

cations of the ACM 20, 1977, pp. 762- 772[19] D. Knuth, J. Morris, V. Pratt, Fast pattern matching in strings, SIAM

Journal on Computing, Vol 6(1), 1977, pp. 323-350[20] R. N. Horspool, Practical fast searching in strings, Software-Practice

Experience , Vol 10(6), 1980, pp. 501-506.

6