Transcription
Hindawi Publishing CorporationJournal of Computer Networks and CommunicationsVolume 2014, Article ID 352071, 11 pageshttp://dx.doi.org/10.1155/2014/352071Research ArticleA Mechanically Proved and an Incremental Development ofthe Session Initiation Protocol INVITE TransactionRajaa Filali and Mohamed BouhdadiLMPHE laboratory, Faculty of sciences, University of Mohammed V, 4 Street Ibn Batouta, PB 1014 RP Rabat, MoroccoCorrespondence should be addressed to Rajaa Filali; rajaa.filali@gmail.comReceived 31 May 2014; Revised 25 September 2014; Accepted 19 October 2014; Published 19 November 2014Academic Editor: Kyandoghere KyamakyaCopyright 2014 R. Filali and M. Bouhdadi. This is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.The Session Initiation Protocol (SIP) is an application layer signaling protocol used to create, manage, and terminate sessions in anIP based network. SIP is considered as a transactional protocol. There are two main SIP transactions, the INVITE transaction andthe non-INVITE transaction. The SIP INVITE transaction specification is described in an informal way in Request for Comments(RFC) 3261 and modified in RFC 6026. In this paper we focus on the INVITE transaction of SIP, over reliable and unreliabletransport mediums, which is used to initiate a session. In order to ensure the correctness of SIP, the INVITE transaction is modeledand verified using event-B method and its Rodin platform. The Event-B refinement concept allows an incremental developmentby defining the studied system at different levels of abstraction, and Rodin discharges almost all proof obligations at each level.This interaction between modeling and proving reduces the complexity and helps in assuring that the INVITE transaction SIPspecification is correct, unambiguous, and easy to understand.1. IntroductionSession Initiation Protocol is a network communicationsprotocol commonly employed for Voice over IP (VoIP)signaling. It is based on request/response transaction model.Each transaction consists of a client request that invokes aparticular method on the server and at least one response.The two main SIP transactions are the INVITE transactionfor setting up a session, and the non-INVITE transaction formaintaining and closing down a session. Their specificationsare defined in Request for Comments (RFC) 3261 [1] and theyhave been modified in RFC 6026 [2].A large number of the practical protocols have onlyinformal specifications. Several formal methods have beenapplied to analyze these protocols, such as model checking[3] and theorem proving [4]. However, only a few papers onanalyzing SIP using Colored Petri Nets (CPNs) have beenpublished [5–8]. CPNs are based on model checking whichverifies the implementation of the system.Recently a new method Event-B [9] has been developedby Abrial who has developed the B method [10] and the Zlanguage [11]. In this paper, we use Event-B to model andprove the SIP INVITE transaction over reliable and unreliabletransport medium. The most important benefit of usingEvent-B is its capability to use abstraction and refinement[12]. Indeed, in this approach the modeling process startswith an abstraction of the system which specifies the goalsof the system. The abstract level of our Event-B model showsthese goals in a very general way, and then during refinementlevels features of the protocol are modeled and the goals areachieved in a detailed way. Moreover the Rodin tool [13]permits an automated proof of the different models of thesystem.In this paper, we use Event-B to model and prove theSNMP protocol. The most important benefit of using Event-Bis its capability to use abstraction and refinement [7].The remainder of the paper is organized as follows.Section 2 gives a brief overview of Event-B. Section 3 providesthe requirements which are informally defined. A refinementstrategy is proposed in Section 4. Finally, in Section 5, theformal development is presented.2. Overview of Event-BBefore Event-B is a formal method for specifying, modeling,and reasoning about systems, especially complex systems
2Journal of Computer Networks and Communicationssuch as an electronic circuit, an airline seat booking system,a PC operating system, a network routing program, a nuclearplant control system, and a Smartcard electronic purse.Event-B has evolved from classical B.Key features of Event-B are the use of set theory as amodeling notation, the use of refinement to represent systemsat different abstraction levels and the use of mathematicalproof to verify consistency between refinement levels. From agiven model M1, a new model M2 can be built as a refinementof M1. In this case, model M1 is called an abstraction of M2,and model M2 is said to be a concrete version of M1. Aconcrete model is said to refine its abstraction. Each event ofa concrete machine refines an abstract event or refines skip.An event that refines skip is referred to as a new event since ithas no counterpart in the abstract model. An Event-B modelhas two parts, context and machine. Each context specifiesthe static properties of the system, including sets, axioms, andconstants. Each machine specifies the dynamic part of thesystem, including variables, invariants, and events. Variablesrepresent the current state of the system and invariantsspecify the global specification of the variables and systembehaviors.An event is defined by the syntax: EVENT e WHEN GTHEN S END, where G is the guard, expressed as a firstorder logical formula in the state variables and S is anynumber of generalized substitutions, defined by the syntax𝑆 :: 𝑥 : 𝐸 (V) 𝑥 : 𝑧 : 𝑃(𝑧). The deterministicsubstitution, 𝑥 : 𝐸(V), assigns to variable 𝑥 the value ofexpression 𝐸(V), defined over set of state variables V. In anondeterministic substitution, 𝑥 : 𝑧 : 𝑃(𝑧), it is possibleto choose nondeterministically local variables, 𝑧, that willrender the predicate 𝑃(𝑧) true. If this is the case, then thesubstitution, 𝑥 : 𝑧, can be applied, otherwise nothinghappens.The Rodin is the tool of the Event-B. It allows formalEvent-B models to be created with an editor. It generates proofobligations that can be discharged either automatically orinteractively. Rodin is modular software and many extensionsare available. These include alternative editors, documentgenerators, team support, and extensions (called plugins)some of which include support decomposition and records.3. Informal Description ofSIP INVITE TransactionThe INVITE client and server transactions are defined in RFC3261 and its modifications are presented in RFC 6026 usingtwo state machines.3.1. INVITE Client Transaction. When Transaction User(TU) at the client side wants to initiate a session, it createsan INVITE client transaction and passes an INVITE requestto the transaction.(i) An INVITE client transaction has five different states:(1) calling, (2) proceeding, (3) accepted, (4), completed,and (5) terminated.(ii) The initial state, calling, must be entered when theTU initiates a new client transaction with an INVITErequest.(iii) For any transport (reliable or unreliable), the clienttransaction must start timer B with a value of 64 T1seconds (Timer B controls transaction timeouts).(iv) If an unreliable transport is being used, the clienttransaction must start timer A with a value of T1(Timer A controls request retransmissions).(v) When timer A fires, the client transaction mustretransmit the request by passing it to the transportlayer and must reset the timer with a value of 2 T1.When timer A fires 2 T1 seconds later, the requestmust be retransmitted again.(vi) If the client transaction is still in the calling state whentimer B fires, the client transaction should inform theTU that a timeout has occurred.(vii) If the client transaction receives a provisionalresponse while in the calling state, it transitions tothe proceeding state.(viii) If a Transport Err (Error) occurs or timer B expires,the client transaction moves to the terminated stateand informs its TU immediately.(ix) In the proceeding state, the client transaction shouldnot retransmit the request any longer. Furthermore,the provisional response must be passed to the TU.Any further provisional responses must be passed upto the TU while in the proceeding state.(x) When in either the calling or proceeding states, reception of a response with status code from 300–699must cause the client transaction to transition tocompleted.(xi) The client transaction should start timer D when itenters the completed state, with a value of at least 32seconds for unreliable transports, and a value of zeroseconds for reliable transports. Timer D reflects theamount of time that the server transaction can remainin the completed state when unreliable transports areused. This is equal to timer H in the INVITE servertransaction, whose default is 64 T1.(xii) If timer D fires while the client transaction is in thecompleted state, the client transaction must move tothe terminated state. When in either the calling orproceeding states, reception of a 2xx response mustcause the client transaction to enter the accepted state.(xiii) The purpose of the accepted state, which presents thecorrection of INVITE client transaction accordingto RFC 6026, is to allow the client transaction tocontinue to exist to receive and pass to its TU anyretransmissions of the 2xx response. When this stateis entered, timer M must be started. This timerreflects the amount of time that the TU will wait forretransmissions of the 2xx responses. When timer Mfires, transaction enters the terminated state.
Journal of Computer Networks and Communications3.2. INVITE Server Transaction. The INVITE server transaction is created by TU on the server side when it receives anINVITE request.(i) The INVITE server transaction can enter five differentstates: (1) proceeding, (2) accepted, (3) completed, (4)confirmed, and (5) terminated.(ii) Initially, the INVITE server transaction enters theproceeding state when it is created.(iii) The server transaction must generate a 100 (Trying)response unless it knows that the TU will generate aprovisional or final response within 200 ms, in whichcase it may generate a 100 (Trying) response.(iv) While in the proceeding state, if the TU passes aresponse with status code from 300 to 699 to theserver transaction, the response must be passed tothe transport layer for transmission, and the statemachine must enter the completed state.(v) When the TU on the server side forwards a finalsuccess response (2xx) to the server transaction, thetransaction delivers this response to the transportlayer for transmission and enters the accepted state.Retransmissions of the 2xx response are handled byTU, not by the server transaction.(vi) The purpose of the accepted state, which presents themodification of INVITE server transaction accordingto RFC 6026, is to absorb retransmissions of anaccepted INVITE request. Any such retransmissionsare absorbed entirely within the server transaction.(vii) Timer L is started when the accepted state is entered.This timer reflects the wait time for retransmissions of2xx responses. When timer L fires, transaction entersthe terminated state.(viii) For unreliable transports, the server transaction muststart timer G to control the time for each retransmission.(ix) If timer G fires, the response is passed to the transportlayer once more for retransmission, and timer G is setto fire in min (2 T1, T2) seconds. From then on, whentimer G fires, the response is passed to the transportagain for transmission, and timer G is reset with avalue that doubles, unless that value exceeds T2, inwhich case it is reset with the value of T2.(x) When the completed state is entered, timer H must beset to fire in 64 T1 seconds for all transports. TimerH determines when the server transaction abandonsretransmitting the response.(xi) If an ACK is received while the server transactionis in the completed state, the server transaction musttransition to the confirmed state. As timer G is ignoredin this state, any retransmissions of the response willcease.(xii) If timer H fires while in the completed state, it impliesthat the ACK was never received. In this case, theserver transaction must transition to the terminated3SETSREQUESTSRESPONSESBox 1VARIABLEScl sentsr got,sr sentcl gotBox 2state, and must indicate to the TU that a transactionfailure has occurred.(xiii) The purpose of the confirmed state is to absorb anyadditional ACK messages that arrive, triggered fromretransmissions of the final response. Once timer Ifires, the server must transition to the terminatedstate.4. Refinement StrategyThe development is made of an initial model followed bysome refinements.The initial model is high level abstraction showing thatthe transaction has a client side and a server side; the clientand the server can both send and receive a message.The first refinement: in this model we specify the requestsand the responses sent by the client and the server, respectively; we introduce also their different states.The second refinement contains the introduction of thetimer constraints for reliable transport.The third refinement contains the introduction of thetimer constraints for unreliable transport.5. Formal Development5.1. Initial Model. In this initial model, we just formalizea communication between client and server by means ofmessages (Algorithm 1).First, we define two carrier sets REQUESTS andRESPONSES: they describe, respectively, the set of messageswhich can be sent by the client and the set of messages whichcan be sent by the server (see Box 1).Then the variables cl sent, sr got, sr sent, and cl got areintroduced to define, respectively, the set of requests sent bythe client, the requests received successfully by the server, theset of responses sent by the server, and successfully receivedresponses by the client (see Box 2).We now define the invariants. In invariants (inv1 andinv2), the set cl sent and sr got are simply typed as subset ofREQUESTS. As expected in invariants (inv3 and inv4), theset sr sent and cl got are defined as a subset of RESPONSES.
4Journal of Computer Networks and CommunicationsINVARIANTSinv1: cl sent REQUESTSinv2: sr got REQUESTSinv3: sr sent RESPONSESinv4: cl got RESPONSESinv5: m m REQUESTS m cl sent m sr gotinv6: l l RESPONSES l sr sent l cl gotBox 3 client Send ANYmsgWHEREgrd4: msg REQUESTSgrd3: msg cl sentTHENact6: cl sent : cl sent {msg}END server Receive ANYmsgWHEREgrd5: msg REQUESTSgrd6: msg cl sentTHENact5: sr got : sr got {msg}END server send ANYmsgWHEREgrd1: msg RESPONSESgrd2: msg sr sentgrd3: sr got ̸ 0THENact2: sr sent : sr sent {msg}END client Receive ANYmsgWHEREgrd5: msg RESPONSESgrd6: msg sr sentTHENact5: cl got : cl got {msg}ENDAlgorithm 1: Events of initial model.The invariant (inv5) denotes that if any message is not in theset cl sent, it must not be in the set sr got. The same for (inv6)(see Box 3).Finally, we define four events in our abstract model. Anevent client send represents the sending request from theclient to the server. An event server receive represents therequest received successful by the server, guards of this tedConfirmedTerminatedINVITEACKr2xxr3xx r699r1xxBox 4state that a message should be in the set cl sent. An eventserver send represents the response sent from the server tothe client, the guard of this event state that the set sr gotshould not be empty. The last event client got represents theresponse received successful by the client.Proofs. In this initial model, there are 6 invariant preservationproofs, with 2 of them proved interactively.5.2. First Refinement. In this first refinement, we introducespecific requests (INVITE, ACK) and responses (1xx, 2xx,3xx-699). We introduce also the different states of the clientand the server. First we define the context which contains thecarrier set STATES. It represents the different states of clientand server. We define also the constants in the context andtheir associated axioms by the agent (see Box 4).In order to manipulate states we introduce two newvariables (See Box 5):c st denotes the current state of client,s st denotes the current state of server.We are now ready to define our events (Algorithm 2).(i) Client send INVITE refining the abstract event clientsend: the client sends an INVITE and the state callingmust be entered.(ii) Server receive INVITE refining the abstract eventServer receive: the server receives the INVITE and itenters in proceeding state.(iii) Server send 1xx refining the abstract eventserver send: after receiving the request INVITE,the server sends a provisional response (1xx) to aclient and it remains in proceeding state(iv) Client receive 1xx refining the abstract eventclient receive: the client receives the response1xx and the state proceeding must be entered.(v) Server send 2xx refining the abstract event serversend: while the server is in proceeding it can sendthe final success response to a client and it enters inaccepted state.
Journal of Computer Networks and Communications5VARIABLESs stc stINVARIANTSinv1: s st STATESinv2: c st STATESinv3: c st Calling INVITE cl sentinv4: s st Proceeding INVITE sr got r1xx sr sentinv5: c st Proceeding r1xx cl gotinv6: s st Accepted r2xx sr sentinv7: c st Accepted r2xx cl gotinv8: s st Completed r3xx r699 sr sentinv9: c st Completed r3xx r699 cl got ACK cl sentinv10: s st Confirmed ACK sr gotBox 5(vi) Client receive 2xx refining the abstract eventclient receive: the client receives the final successresponse 2xx and the state proceeding must beentered.(vii) Server send 3xx-699 refining the abstract eventserver receive: when the server sends the finalnonsuccess response, it enters in completed state.(viii) Client receive 3xx-699 refining the abstract eventserver receive: while the client is in calling or proceeding state and it receives the nonsuccess response3xx-6xx, the state completed must be entered.(ix) Client send ACK refining the abstract eventclient send: the client sends an acknowledgment(ACK) to the server after receiving the nonsuccessresponse.(x) Server receive ACK refining the abstract eventserver receive: the server receives the ACK and itenters in confirmed state.(xi) We add two new events client final state and server final state as anticipated events.Proofs. The proof obligation generator of the Rodin Platformproduces 49 proof obligations, with 7 of them proved interactively.5.3. Second Refinement. In this refinement, we introduce thetime constraints for reliable transport. We add six timers B, H,D, I, L, and M: timer B controls transaction timeouts, timerH determines when the server transaction abandons retransmitting the response, timer D reflects the amount of timethat the server transaction can remain in the “completed”state, timer I determines the server state from confirmed toterminated, timer M reflects the amount of time that theTU will wait for retransmissions of the 2xx responses, andtimer L reflects the wait time for retransmissions of 2xxresponses. For modeling these timers, we define six variablesthat represent each of them, and others six Boolean variablesfor whether the timer is held or not (see Box 6).VARIABLESHBIDTemp BTemp HTemp DTemp ITemp MTemp LBox 6Concerning events, we add six new events Expire B,Expire D, Expire H, Expire I, Expire M, and Expire L; theyrepresent when each timer will expire. We add also six timeprogression events: Tick Tock B, Tick Tock D, Tick Tock H,Tick Tock I, Tick Tock L, and Tick Tock M (Algorithm 3).We refine some events:Client send INVITE, client receive 1xx, server send 3xx699, client receive 3xx-699, server receive ACK, client receive 2xx, server send 2xx.When the client transaction sends an invite, the clienttransaction must start timer B (we refine the abstract eventclient send INVITE by adding the action temp B : TRUE). Ifthe client transaction is still in the calling state when timerB fires, the client transaction should pass to the final stateterminated. If the client transaction receives a provisionalresponse while in the calling state, it transitions to theproceeding state; then the timer B must turn off (we refine theabstract event client receive 1xx by adding the action temp B: FALSE). The client transaction should start timer D whenit enters the completed state, so we add temp D : TRUEas action in the event client receive 3xx-699. If timer D fireswhile the client transaction is in the completed state, the clienttransaction must move to the terminated state.When the completed state is entered, timer H must be setto fire (we refine the abstract event server send 3xx 699 by
6Journal of Computer Networks and Communications INITIALISATION BEGINact7: cl sent : 0act8: cl got : 0act9: sr sent : 0act10: sr got : 0act11: c st : Readyact12: s st : ReadyEND client Send INVITE REFINESclient SendANYmsgWHEREgrd4: msg REQUESTSgrd3: msg cl sentgrd5: msg INVITEgrd6: c st ReadyTHENact6: cl sent : cl sent {msg}act7: c st : CallingEND server receive INVITE REFINESserver ReceiveANYmsgWHEREgrd5: msg REQUESTSgrd6: msg cl sentgrd7: msg INVITEgrd8: s st ReadyTHENact5: sr got : sr got {msg}act6: s st : ProceedingEND server send 1xx REFINESserver sendANYmsgWHEREgrd1: msg RESPONSESgrd2: msg sr sentgrd3: sr got ̸ 0grd4: msg r1xxgrd5: s st ProceedingTHENact2: sr sent : sr sent {msg}act3: s st : ProceedingEND client Receive 1xx REFINESclient ReceiveANYmsgAlgorithm 2: Continued.
Journal of Computer Networks and CommunicationsWHEREgrd5: msg RESPONSESgrd6: msg sr sentgrd7: msg r1xxgrd8: c st CallingTHENact5: cl got : cl got {msg}act6: c st : ProceedingEND server send 2xx REFINESserver sendANYmsgWHEREgrd1: msg RESPONSESgrd2: msg sr sentgrd3: sr got ̸ 0grd4: msg r2xxgrd5: s st ProceedingTHENact2: sr sent : sr sent {msg}act3: s st : AcceptedEND client Receive 2xx REFINESclient ReceiveANYmsgWHEREgrd5: msg RESPONSESgrd6: msg sr sentgrd7: msg r2xxgrd8: c st Calling c st ProceedingTHENact5: cl got: cl got {msg}act6: c st : AcceptedEND server send 3xx-699 REFINESserver sendANYmsgWHEREgrd1: msg RESPONSESgrd2: msg sr sentgrd3: sr got ̸ 0grd4: msg r3xx r699grd5: s st ProceedingTHENact2: sr sent : sr sent {msg}act3: s st : CompletedEND client Receive 3xx-699 REFINESclient ReceiveANYmsgAlgorithm 2: Continued.7
8Journal of Computer Networks and CommunicationsWHEREgrd5: msg RESPONSESgrd6: msg sr sentgrd7: msg r3xx r699grd8: c st Calling c st ProceedingTHENact5: cl got : cl got {msg}act6: c st : CompletedEND client send ACK REFINESclient SendANYmsgWHEREgrd4: msg REQUESTSgrd3: msg cl sentgrd5: msg ACKgrd6: c st CompletedTHENact6: cl sent : cl sent {msg}act7: c st : CompletedEND server Receive ACK REFINESserver ReceiveANYmsgWHEREgrd5: msg REQUESTSgrd6: msg cl sentgrd7: msg ACKgrd8: s st CompletedTHENact5: sr got : sr got {msg}act6: s st : ConfirmedEND Client final state STATUSanticipatedBEGINact1: c st : TerminatedEND Server final state STATUSanticipatedBEGINact1: s st : TerminatedENDAlgorithm 2: Events of first refinement.adding the action temp H : TRUE). If timer H fires whilein the completed state, it implies that the ACK was neverreceived. In this case, the server transaction must transitionto the terminated state and must indicate to the TU that atransaction failure has occurred.When confirmed state is entered, timer I is set to fire inzero seconds for reliable transports. We add temp (I : TRUE)as action in the refined event server receive ACK. Once timerI fires, the server MUST transition to the terminated state.Timer L is started when the accepted state is entered.When timer L fires, transaction enters the terminated state.When accepted state is entered, timer M must be started.When timer M fires, transaction enters the terminatedstate.Proofs. There are 10 invariant preservation proofs. They are allstraightforward and easily proved automatically by the Rodinplatform prover.
Journal of Computer Networks and Communications9 Exipre B REFINESclient final stateWHENgrd3: r1xx cl gotgrd1: B 64 cstgrd4: c st CallingTHENact1: c st : Terminatedact2: B : 0act3: Temp B : FALSEEND Expire H REFINESserver final stateWHENgrd3: ACK sr gotgrd1: H 64 cstgrd2: s st CompletedTHENact1: s st : Terminatedact2: H : 0act3: Temp H : FALSEEND Expire D REFINESclient final stateWHENgrd1: Temp D TRUEgrd2: c st CompletedTHENact1: c st : Terminatedact2: Temp D : FALSEEND Expire I REFINESServer final stateWHENgrd2: Temp I TRUEgrd1: s st ConfirmedTHENact1: s st : Terminatedact2: Temp I : FALSEEND Expire M REFINESClient final stateWHENgrd2: Temp M TRUEgrd1: c st AcceptedTHENact1: c st : Terminatedact2: Temp M : FALSEEND Expire L REFINESServer final stateAlgorithm 3: Continued.
10Journal of Computer Networks and CommunicationsWHENgrd2: Temp L TRUEgrd1: s st AcceptedTHENact1: s st : Terminatedact2: Temp L : FALSEENDAlgorithm 3: Events of second refinement.Table 1: Proof statistics. Resend INVITE WHENgrd1: c st Callinggrd2: A T1THENact1: T1 : 2 T1act2: cl sent : cl sent {INVITE}act3: c st : Callingact4: A : 0END Resend 3xx-699 ANYdataWHEREgrd1: data T1grd2: G min ({data, T2})grd3: s st CompletedTHENact1: sr sent : sr sent {r3xx r699}act2: s st : Completedact3: T1 : 2 T1act4: G : 0ENDAlgorithm 4: Events of third refienement.5.4. Third Refinement. In this last refinement, we introducethe time constraints for unreliable transport. New variablesare declared, “A” as the timer that controls request retransmissions, “G” controls the time for each retransmission, andtwo Boolean variables temp A and temp G for whether thetimer is held or not. We add also two new events.Resend INVITE. When timer A fires, the client transactionmust retransmit the request INVITE and must reset the timerwith a value of 2 T1. When timer A fires 2 T1 seconds later,the request must be retransmitted again.Resend 3xx-699. If timer G fires, the response 3xx-699 ispassed to the transport layer once more for retransmission,and timer G is set to fire in min (2 T1, T2) seconds. From thenon, when timer G fires, the response is passed to the transportagain for transmission, and timer G is reset with a value thatdoubles, unless that value exceeds T2, in which case it is resetwith the value of T2 (Algorithm 4).Total numberof POsAutomaticProofInteractiveProofInitial modelFirst 010014131Total7969 (87%)10 (13%)ModelWe refine the events expire I, expire M, expire L, andexpire D by adding, respectively, the actions d 32, I 10 cst, M 64 cst, and L 64 cst, where cst 500 ms.Proofs. This refinement requires 14 proofs, all proved automatically except one.5.5. Proof Statistics. Table 1 describes the proof statistics ofthe formal development of SIP INVITE transaction in theRodin tool. These statistics measure the size of the model,the proof obligations generated and discharged by the Rodinplatform, and those that are interactively proved.6. ConclusionIn this paper, we have modeled and proved SIP INVITEtransaction over reliable and unreliable transport mediumusing Event-BWe have explained our approach using refinement, whichallows us to achieve a very high degree of automatic proof.The powerful support is provided by the Rodin tool. Rodinproof is used to generate the proof obligations and todischarge those obligations automatically and interactively.Modeling and analyzing SIP specification using formal methods can help in assuring correctness, unambiguity, and clarityof the SIP protocol. Since a well-defined and verified protocolspecification can reduce the cost for its implementation andmaintenance, modeling and analysis are important steps ofthe protocol development life-cycle from the point view ofprotocol engineering.In the future work, we would model and prove the nonINVITE transaction over reliable and unreliable mediums.
Journal of Computer Networks and CommunicationsConflict of InterestsThe authors declare that there is no conflict of interestsregarding the publication of this paper.References[1] J. Rosenberg, H. Schulzrinne, G. Camarillo et al., “Sip: sessioninitiation protocol,” Tech. Rep. RFC 3261, Internet EngineeringTask Force, 2002.[2] R. Sparks and T. Zourzouvillys, “Correct transaction handlingfor 2xx responses to session initiation protocol (sip) inviterequests,” RFC 6026, 2010, http://www.ietf.org/rfc/rfc6026.txt.[3] E. M. Clarke, O. Grumberg, and D. Peled, Model Checking, MITPress, Cambridge, Mass, USA, 1999.[4] C.-L. Chang, Symbolic Logic and Mechanical Theorem Proving,Academic Press, 1973.[5] L. G. Ding and L. Liu, Modeling and Analysis of the INVITETransaction of the Session Initiation Protocol Using Colored PetriNets, Springer, 2008.[6] L. Liu, “Verification of the sip transaction using colored Petrinets,” in Proceedings of the 23nd Australasian Conference onComputer Science, vol. 91, pp. 75–84, Australian ComputerSociety, 2009.[7] S. Kızmaz and M. Kırcı, “Verification of session initiation protocol using timed colored petri net,” International Journal ofCommunications, Network & System Sciences, vol. 4, no. 3, pp.170–179, 2011.[8] S. Barakovic, D. Jevtic, and J. Barakovic Husic, “Modeling ofsession initiation protocol invite transaction using colored Petrinets,” in Proceedings of the 8th International Conference onModeling and Simulation (ICMS ’12), 2012.[9] J. R. Abrial, Modeling in Event-B: System and Software Engineering, Cambridge University Press, 2010.[10] J. R. Abrial, The B-Book: Assigning Programs to Meanings,Cambridge University Press, Cambridge,
transaction must start timer B with a value of T seconds (Timer B controls transactiontimeouts). (iv) If an unreliable transport is being used, the client transaction must start timer A with a value of T (Timer A controlsrequest retransmissions). (v) When timer A r es, the client transaction must retransmit the request by passing it to the .
