Verification of Session Initiation Protocol Using Timed Colored Petri Net

In this work, Session Initiation Protocol model is established by using Timed Colored Petri Nets (TCPN). SIP (Session Initiation Protocol) is a protocol developed to assist in providing advanced telephony services across the Internet. The Session Initiation Protocol (SIP) has become the quasi-standard for Voiceover-Internet Protocol (VoIP) communications. SIP is based on a client-server infrastructure in which user agents represent the end-terminals as clients, proxy servers handle SIP message routing between the user agents, and registrar servers store the client's contact information into a location service. By use of timed color set and useful time attributes in tokens defined in CPN tools, timer and time-related problems of SIP are mod-eled and analyzed. Timer is an important part for SIP, especially the INVITE transaction.


Introduction
Communications with Voice over IP (VoIP) have been popular because of developments of Internet.VoIP uses the Internet Protocol (IP) to transmit voice as packets over an IP network.VOIP can be achieved on any data network that uses IP, like Internet, Intranets and Local Area Networks (LAN).Before a conversation can take place between participants, protocols must be employed to establish a session, then to maintain and terminate the session.The Session Initiation Protocol (SIP) is one of the protocols being used for such purposes.
SIP is developed by the Internet Engineering Task Force (IETF) and published as Request for Comments (RFC) 3261 in 2002 [1].Because of its increasing popularity and importance in VoIP applications [2], SIP has become a permanent element of the IP Multimedia Subsystem architecture as a signalling protocol [3].Thus, it is important to assure that the contents of RFC 3261 are correct, unambiguous, and easy to understand.Modelling and analysing the specification using formal methods can help in achieving this goal.Moreover, from the perspective of protocol engineering, verification is also an important step of the life-cycle of protocol development [4,5], as a well-defined and verified specification will reduce the cost for implementation and maintenance.
SIP is a transaction-oriented protocol that carries out tasks through different transactions.The two main SIP transactions are the INVITE transaction for setting up a session, and the non-INVITE transaction for maintaining and closing down a session.Our current work is aimed at verifying the functional properties of the INVITE transaction.
We use Timed Colored Petri Nets (CPNs) [6] as the modeling and analyzing technique.Timed CPN have an additional property that can be used for different kinds of performance analysis.In untimed Petri Nets (Classical PNs or CPNs) it is presumed that the firing of transitions is instantaneous.Since real world actions take time to complete, tokens in timed CPN carry additional information, the time stamp.As CPNs TCPNs also have their well-developed supporting software package, the CPN Tools (Homepage of the CPN Tools).
SIP Invite Transaction is modelled and analysed with CPN in [7][8][9][10].In [7], the functional properties of the INVITE transaction over a reliable transport medium have verified.In [8], SIP INVITE transaction was modelled and analysed when the medium is unreliable.Various forms of real-time multimedia session data such as voice, video, or text messages are carried by several protocols [11,12].SIP works in concert with these protocols [13].Although time factor is very important for SIP, SIP is not modelled with using TCPNs previously.
We firstly model the INVITE transaction.The rest of the paper is organized as follows.Section 2 introduces petri nets especially timed colored petri nets and definitions of timed colored petri nets are indicated.Section 3 introduces SIP INVITE transaction.Modelling and analysis of the transaction is then described in Section 4. Finally, Section 5 concludes the work and suggests future research.

Structure of SIP
SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls.SIP is structured into four layers, each of which carries out a set of functions.The lowest layer of SIP is its syntax and encoding.Its encoding is specified using an augmented Backus-Naur Form grammar (BNF).The second layer is the transport layer.It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network.The third layer is the transaction layer with each transaction consisting of a client transaction sending requests and a server transaction responding to requests.The layer above the transaction layer is called the transaction user (TU), which creates and destroys SIP transactions, and utilises services provided by the transaction layer [1].Among the four SIP layers, the transaction layer is the most important layer since it is responsible for requestresponse matching, retransmission handling with unreliable transport medium, and timeout handling when setting up or tearing down a session.

The INVITE Transaction
The INVITE client and server transactions are defined in RFC 3261 using two state machines, as shown in Figure 1.

1) INVITE Client Transaction
The TU communicates with the client transaction through a simple interface.When the TU wishes to initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP address, port, and transport to which to send it.The client transaction begins execution of its state machine.
The INVITE transaction consists of a three-way handshake.The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK.
• An INVITE client transaction (Figure 1 (a)) has four states: Calling, Proceeding, Completed, and Terminated.
• The initial state, "calling", must be entered when the TU initiates a new client transaction with an INVITE request.
• The client transaction must pass the request to the transport layer for transmission.
• If an unreliable transport is being used, the client transaction must start timer A with a value of T1.For any transport, the client transaction must start Timer B with a value of 64*T1 seconds.Timer A controls request, Timer B controls transaction timeouts.
• When timer A fires, the client transaction must retransmit the request by passing it to the transport layer, and must reset the timer with a value of 2*T1.When timer A fires 2*T1 seconds later, the request must be retransmitted again.
• If the client transaction is still in the "Calling" state when timer B fires, the client transaction should inform the TU that a timeout has occurred.
• The client transaction must not generate an ACK.The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport.
• If the client transaction receives a provisional response while in the "Calling" state, it transitions to the "Proceeding" state.
• If a Transport Err (Error) occurs or Timer B expires, the client transaction moves to the Terminated state and informs its TU immediately.
• In the "Proceeding" state, the client transaction should not retransmit the request any longer.Furthermore, the provisional response must be passed to the TU.Any further provisional responses must be passed up to the TU while in the "Proceeding" state.
• When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 must cause the client transaction to transition to "Completed".
• The client transaction should start Timer D when it enters the "Completed" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports.Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used.This is equal to Timer H in the INVITE server transaction, whose default is 64*T1.
• If Timer D fires while the client transaction is in the "Completed" state, the client transaction must move to the terminated state.When in either the "Calling" or "Proceeding" states, reception of a 2xx response must cause the client transaction to enter the "Terminated" state, and the response must be passed up to the TU.

INVITE Server Transaction
• The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses.
• Server transactions are created by the core when a request is received, and transaction handling is desired for that request.
• As with the client transactions, the state machine depends on whether the received request is an INVITE request.When a server transaction is constructed for a request, it enters the "Proceeding" state.
• The server transaction must generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it may generate a 100 (Trying) response.
• If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction must pass this response to the transport layer for transmission.It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU.The server transaction must then transition to the "Terminated" state.
• While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response must be passed to the transport layer for transmission, and the state machine must enter the "Completed" state.
• For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports.
• When the "Completed" state is entered, timer H must be set to fire in 64*T1 seconds for all transports.Timer H determines when the server transaction abandons retransmitting the response.
• If Timer G fires, the response is passed to the transport layer once more for retransmission, and Timer G is set to fire in min (2*T1, T2) seconds.From then on, when Timer G fires, the response is passed to the transport again for transmission, and Timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2.
• If an ACK is received while the server transaction is in the "Completed" state, the server transaction must transition to the "Confirmed" state.As Timer G is ignored in this state, any retransmissions of the response will cease.
• If Timer H fires while in the "Completed" state, it implies that the ACK was never received.In this case, the server transaction must transition to the "Terminated" state, and must indicate to the TU that a transaction failure has occurred.
• The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response.
• Once Timer I fires, the server must transition to the "Terminated" state.

Petri Nets Overview
Petri Nets (PNs) are a well-known formal and graphical language for modelling concurrent and asynchronous systems in the presence of conflicts, mutual exclusion, synchronization and nondeterministic aspects.In its basic form, PNs are adequate for qualitative evaluation of systems, for example to answer questions about liveness, boundedness, invariants and other characteristics of a system's model.Analysis can be performed by linear algebra techniques or by investigating the set of reachable states.

Timed Colored Petri Nets
Most applications of CPNs are used to investigate the logical correctness of a system [14].The CPN extended by time gives a possibility to describe the dynamic properties of a system in the time space [14][15][16].The time concept of CPNs is based on the introduction of a global clock.The clock values represent the model time and they be discrete (for example integers).Each token carry a time value, also called a time stamp.The time stamp describes the earliest model time at which the token can be used, i.e., removed by the occurrence of a binding element.

The Basic Definitions of TCPN
The original definitions of TCPN [17,18]: such that the sum: is finite for all sS ∈ The non-negative integer tm(s) is the number of appearances of the element s in the timed multi-set tm.The list: is defined to contain the time values rR ∈ for which tm(s, r) ≠ 0. Each r appears tm(s, r) times in the list, which is sorted such that We usually represent the time multi-set tm by a formal sum: By TMS S we denote the set of all timed multi-sets over S. The non-negative integer b) P is a finite set of places.c) T is a finite set of transitions.d) A is a finite set of arcs such that: where p(a) is the place of N(a).i) I is an initialization function.It is defined from P into closed expressions such that: 2) R is the set of time values, also called time stamps.It is a subset of R closed under + and containing 0.
3) 0 r is an element of R called the start time.Definition 3: A binding of transition t is a function b defined on Var(t), such that;  The first sum is called the removed token while the second is called the added tokens.Moreover, we say that ( )

,
Mr is directly reachable from ( )

,
Mr by the occurrence of the step Y at time 2 r .

Summary of Timers
The client transaction uses three timers: A, B and D. Timer B sets up the maximum time that the client transaction would wait in its Calling state for a provisional or final response from the server side.This timer is used no matter over what transport medium the transaction is running.Timer A is used only when the medium is unreliable, to control retransmissions of INVITE requests.Timer D also only plays its role when the medium is unreliable because its value is set to zero for reliable transport and 32 seconds for unreliable transport.
The server transaction also has three timers: G, H and I. Timer H is used for both reliable and unreliable medium, to set up the maximum time that the server transaction would wait in its Completed state before an ACK is received.Timer G is only used for unreliable transport, to control retransmissions of 300-699 responses.Timer I is set to zero seconds for a reliable transport medium, and 5 seconds for an unreliable medium.

Software Tools and TCPN
CPN Tools can simulate both basic Petri Nets and more advanced Colored Petri Nets [17].The "color" or properties of the model are set using CPN Markup Language (CPN ML).Time is one of many properties that can be set, so timed Colored Petri Nets are available.
Since CPN Tools simulate models using Petri Nets there are only three basic elements.These are places, transitions and arcs, as shown in Figure 2.
The "color" modifies the way a model functions.CPN Tools can create, simulate and make state space analysis of the Petri Net model.Basically, Petri Net is a directed graph composed of two disjoint sets of nodes called places and transitions.Places represent states of the system, while transitions represent actions that the system can perform.To simulate an action performed by the system, appropriate transition has to "fire".
The "firing" of a transition is enabled or disabled by the tokens inside transition's input place(s).If there is an appropriate number of tokens in all input places, this depends on connecting arcs' inscriptions, then the transition is enabled and it can "fire".

TCPN Model of the INVITE Transaction
Figure 3, Tables 1 and 2 show the TCPN model which based on state machines for the INVITE transaction.It extends the CPN model presented in [7] by adding time factor, and by modelling an unreliable transport medium.Same naming conventions are used here as in [4].To distinguish a server transaction's state from a client transaction's state with the same name, a capitalised S is appended to the name of the state of the server transaction (except for the proceedingT state).SIP response messages (Table 3) are named as follows: r100 represents a 100 Trying response; r101 is for a provisional response with a status code between 101 and 199; r2xx for a 2xx response; and r3xx for a 300-699 response.
• Place Client is typed with colour set STATEC and its initial marking is calling.
• Place Invite Sent is typed by colour set INT.
• Transition Send Request is enabled only if the Client is calling and Invite Sent contains an integer 0.
• Transition Receive Response is enabled when a response is received and the Client is not terminated.
• If the client transaction receives a 300-699 response, an ACK is passed to SIP transport layer, and the Client changes to be completed.
• If the received response is r100, r101 or r2xx, no ACK is sent; when the response is r100 or r101, the Client changes to proceeding; and when the response is r2xx, the Client changes to be terminated.
• If the client transaction receives a 300-699 response, an ACK is passed to SIP transport layer, and the Client changes to be completed.
• If the received response is r100, r101 or r2xx, no ACK is sent; when the response is r100 or r101, the Client changes to proceeding; and when the response is r2xx, the Client changes to be terminated.
• Transition Timer D is enabled once the Client is completed, and its occurrence changes Client to be terminated.
• Transition Client Transport Err is enabled when the Client is completed.Its occurrence also changes Client to be terminated.• When an error is reported by SIP transport layer, the ACK that has been passed to it from the transaction layer will not be sent to the server side, so when Client Transport Err occurs, the ACK that has been put in place Requests is destroyed.
• A transport error can occur when the client transaction is Calling, so Client Transport Err is enabled as well when the Client is calling.
• Place Server is typed by colour set STATES.
• ProceedingT models the new state ProceedingT that we add to the server transaction.
• The initial marking for place Server cannot be pro-ceedingT.
• Place r3xxResent is typed by INT.
• When the transition occurs upon receiving an IN-VITE request and the Server is Idle, a proceedingT is created in the Server place.In this case and only in this case, transition Receive Request models the operation of the TU instead of the server transaction of receiving an INVITE request from the client side • Once the Server is proceedingT, transition Send Response is enabled, thus a r100 can be put into Responses, and the state of Server is changed to proceed-ingS.
• In the proceedingS state, Send Response is again enabled.When it occurs, a r101, r2xx or r3xx response is put into place Responses.This is represented by the variable re included in the else clause of the inscription of arc from Send Response to Responses where re is of type Response.Meanwhile, a proceedingS, completedS or terminatedS is put in the Server place.
• While the Server is completedS, if an ACK is received, the occurrence of Receive Request changes the Server to confirmedS.We have assumed that the server transaction can receive INVITE or ACK requests when it is confirmedS, the last else clause of the inscription of the arc from Receive Request to Server models the server transaction stays in the same state and do not send any response.The guard of Receive Request models that the server transaction cannot receive any requests after it is Terminated because it is destroyed by TU after the Terminated state is entered.
• If the medium is unreliable, when the Server is pro-ceedingS or completedS, a response (r101 or r3xx) is sent upon receiving an INVITE retransmitted by the client.
• Similar to the modelling of Timer A and Timer B requests when it is confirmedS, the last else clause of the inscription of the arc from Receive Request to Server models the server transaction stays in the same state and do not send any response.The guard of Receive Request models that the server transaction cannot receive any requests after it is Terminated because it is destroyed by TU after the Terminated state is entered.
• If the medium is unreliable, when the Server is pro-ceedingS or completedS, a response (r101 or r3xx) is sent upon receiving an INVITE retransmitted by the client.
• When the transport medium is unreliable, we cannot use lists.Instead we let the color sets of Requests and Responses be multisets of possible requests and responses respectively, so that an occurrence of an output transition of Requests or Responses destroys a randomly picked request or response.This models that the transport medium may reorder messages, i.e. messages are not received in the order they are sent (put into the Requests or Responses place).
• To model message loss, we use two transitions Lose Request and Lose Response, whose occurrences destroy requests and responses from places Requests and Responses respectively.
• Retransmission is controlled by transition "Timer A and B" with T1, an interval 2*T1 and Place A. Timeout is controlled by declared overtime function OT of 64*T1 for Timer B with transition "Timer A and B" and Place B. Time transition inscription of "Timer A and B" indicates time consuming by attaching time to "@+." • When timer D fires while the client transaction is in the "Completed" state, the client transaction must move to the terminated state.
• As Timer D, when timer I fires, the server must transition to the "Terminated" state.

State Space Analysis of the INVITE Transaction CPN Model
CPN tools offers specific tools to analyze properties of modeled net, such as boundness and liveness properties shown in the simulation report, automated state space calculation, supported query functions of CPN ML, simulation, and performance tools, etc.As state space is calculated, CPN ML query functions can be utilized for further analysis.CPN ML language is used for declarations and net inscriptions.The monitoring and performance tools are useful for simulation of models, which would store simulation data for further analysis.Simulating INVITE transaction model, we can see states of telecommunication systems which use SIP protocol at the certain time.Real-time systems behaviors and carrying of Multimedia session data such as voice, video, or text messages are seen obviously by adding time factor.
In this section we define state space analysis of model which is represented above.In order to avoid state explosion problem with state space analysis, we use 3 as the maximum length of the queue in place Response, define colset INT = int with 0 … 1 and limit transitions (for example Timer A and B is enabled when [a > = 1] and Timer D is enabled when b < 17).When the model is generated, we meet infinite state space and can not analyse state space.Its reason is Timer D is enabled for every value of b.If we did not limit transition Timer D, model would be infinite loop because value of b.
A deadlock is an undesired dead marking in the state space of a CPN model, and a marking is dead if no transitions are enabled in it [19].We also expect that the INVITE transaction has no dead code.For our model, there is no dead marking.We use state space report generated by CPN tools for analyse our model properties.
The report shows that a full state space with 14 nodes and 29 arcs is generated.If we use SCC graph(strongly connected components) a full state space with 14 nodes and 29 arcs would be generated.Dead Transition Instances returns a list with all those transition instances that are dead, i.e., do not appear in any occurrence sequence starting from the initial marking of the state space.

Conclusions and Future Work
In this paper, we have modelled and analysed SIP IN-VITE transaction using timed Coloured Petri Nets.Based on the detailed analysis of SIP, Time Coloured Petri net model of the protocol is established in the paper.By discussing and analyzing the model on the basis of properties of Petri net relating to the model, analyzing reachability tree, and calculating and analyzing the invariant, the protocol was proved to be boundedness, deadlock free, liveness and conservativeness.
In the future, we would model and analyse INVITE transaction over a reliable medium and unreliable medium and find that the INVITE transaction is free of livelocks and dead codes, as in the case of a reliable medium.We have noticed that, very recently, an Internet draft (work in progress) has been published by IETF, to propose updates to the INVITE transaction state machines [19].The proposed updates have no impacts on the behaviour of the INVITE transaction when the transport medium is reliable, which means IETF may have not been aware of the incompleteness of [19] of the specification of the INVITE transaction.On the other hand, the proposed updates may have influence on the INVITE transaction when the transport medium is unreliable.Therefore, the other possible future work can include modelling and analysing the updated version of INVITE transaction proposed in the Internet Draft [19].In this way, the correctness of the proposed updates given in the Internet Draft [19] can be checked and confirmed.
called the coefficients of the timed multi-set tm, and tm(s) is called the coefficient of s.An element sS ∈ is said to belong to the timed multi-set tm iff tm(s) ≠ 0 and we then write stm ∈ .Each timed multi-set TMS tmS ∈ determines an ordinary multi-set uMS tmS ∈ defined by: Definition 2: A timed non-hierarchical CP-nets is a tuple TCPN = (CPN, R, 0 r ) such that: 1) CPN= (Σ , P, TA, N, C, G, E, I) satisfying the requirements below: a) Σ is a finite set of non empty types, called color sets.

Figure 2 .
Figure 2. View of the CPN Tools with opened network window and opened menus to create, simulate and make state space analysis of the model.

Figure 3 .
Figure 3. CPN model of the INVITE transaction.
<b>.By B(t) we denote the set of all binding for t.

Table 2 . Declarations of the CPN model.Table 3 . SIP response messages.
TIsLive determines whether the set of transition instances (specified in the list) is live, i.e., whether, from each reachable marking, it is possible to find an occurrence sequence which contains one of the transition instances.For our model: model'Timer_G_or_H 1 TIsFairness determines whether the set of transition instances (specified in the list) is impartial, fair or just.