Internet DRAFT - draft-cuda-sipping-ua-fsm
draft-cuda-sipping-ua-fsm
Network Working Group A. Cuda
Internet-Draft E. Marocco
Expires: July 20, 2006 Telecom Italia
January 16, 2006
A Formal Model for Media Negotiation between SIP User Agents
draft-cuda-sipping-ua-fsm-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides a formal description of the interactions
between two SIP User Agents establishing a multimedia session,
describing the negotiation of the two parties as an exchange of
signals between two instances of networks of Finite State Machines
(FSMs).
The goal is to provide a common reference model for both SIP
extensions and User Agent implementations: two flows that can be
Cuda & Marocco Expires July 20, 2006 [Page 1]
Internet-Draft A Formal Model for Media Negotiation January 2006
implemented by using the external interface of the FSMs are
guaranteed not to conflict to each other. On the other hand a
reference model for User Agents is expected to improve
interoperability between different implementations and help
implementors to model their software in a way that makes SIP
extensions conforming to this document easier to implement.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Scope and Purposes of This Document . . . . . . . . . . . . . 4
3. Naming and Conventions . . . . . . . . . . . . . . . . . . . . 5
4. State Machines Interfaces . . . . . . . . . . . . . . . . . . 8
4.1. External Interfaces . . . . . . . . . . . . . . . . . . . 8
4.1.1. Grouping Events into Interfaces . . . . . . . . . . . 8
4.1.2. FSM Tasks . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. The Signalling Interface (ifcS) . . . . . . . . . . . 12
4.1.4. The Session Interface (ifcI) . . . . . . . . . . . . . 13
4.1.5. The Negotiation Interfaces (ifcN) . . . . . . . . . . 14
4.1.6. Rules of Composition . . . . . . . . . . . . . . . . . 15
4.2. Internal Interfaces . . . . . . . . . . . . . . . . . . . 17
4.2.1. Which Interactions are Needed . . . . . . . . . . . . 17
4.2.2. Synchronization-Signalling Interface (ifcU) . . . . . 17
4.2.3. Session-Synchronization Interface (ifcA) . . . . . . . 19
4.3. Session-Negotiation Interface (ifcV) . . . . . . . . . . . 19
5. State Machine Definition . . . . . . . . . . . . . . . . . . . 21
5.1. Session State Machine . . . . . . . . . . . . . . . . . . 21
5.2. Negotiation State Machine . . . . . . . . . . . . . . . . 22
5.3. Synchronization State Machine . . . . . . . . . . . . . . 24
5.4. Signalling State Machine . . . . . . . . . . . . . . . . . 27
5.4.1. Overall State Machine . . . . . . . . . . . . . . . . 27
5.4.2. Scope State Machine . . . . . . . . . . . . . . . . . 30
5.4.3. Prop State Machine . . . . . . . . . . . . . . . . . . 37
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42
Cuda & Marocco Expires July 20, 2006 [Page 2]
Internet-Draft A Formal Model for Media Negotiation January 2006
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Cuda & Marocco Expires July 20, 2006 [Page 3]
Internet-Draft A Formal Model for Media Negotiation January 2006
2. Scope and Purposes of This Document
SIP [RFC3261] is a protocol that allows to establish, control and
terminate multimedia sessions. As such, negotiation (specified in
[RFC3264]) is one of its most fundamental tasks, and the need to
provide features like resource reservation or early media streaming
makes the protocol operations quite hard to design. For these
purposes, a number of SIP mechanisms have been added to the baseline
protocol, like UPDATE ([RFC3311]) and PRACK ([RFC3262]). All these
RFCs leave many options to implementors and, despite the effort to
define the best current practices ([I-D.sawada-sipping-sip-
offeranswer]) this represents a serious threat for interoperability
and a challenge for User Agent implementors.
The purpose of this document is to provide a formal description of
the SIP negotiation process, which can be used as a guideline for
both SIP extensions authors and for User Agent implementors, as well
as a base for SIP test suites. The formalism chosen for this
document is a network of Finite State Machines communicating each
other through signals: as such, it models a software layer between
the SIP transaction layer (see [RFC3261]), and the application
controlling the negotiation. However, the purpose is not to specify
a negotiation API, nor to give a formal description of the
interactions between the Transaction User and the Transaction Layer:
these aspects are treated just in the measure that is needed to
define a number of signals between the State Machines and the
Transaction Layer and between the State Machines and the Application.
Finally, even though this document tries to keep the negotiation
interface as SIP-unaware as possible, it is not meant to provide a
protocol-independent negotiation mechanism.
Cuda & Marocco Expires July 20, 2006 [Page 4]
Internet-Draft A Formal Model for Media Negotiation January 2006
3. Naming and Conventions
The following paragraphs will build the State Machine network
starting from its external interfaces and breaking the overall system
into subsystem as new functional entities are isolated. Subsystems
are modeled as Finite State Machines and interactions between them
are represented by messages received from an external interface or
generated by a state transition and fed to another state machine or
sent towards an external interface. The system may therefore be
depicted as follows:
| FSM Network |
|||||||||||||||||||||||||||
| : ifcB |
ifcA | <-:-> | ifcC
<-+-> FSM : <-+->
| A : |
| : FSM |
Application |...........: B | Transaction
Layer | : | Layer
| : |
| /// : |
| : |
| : |
|||||||||||||||||||||||||||
| |
Figure 1
In the figure above ifcA and ifcC are external interfaces, while ifcB
is an internal interface. An internal interface is uniquely
identified by the couple of FSMs it is connected to. An external
interface is identified by the layer (i.e. application or
transaction) and the FSM it connects to.
Event propagation happens atomically and transactionally through all
the interfaces. Suppose, for instance, that an event through ifcA
causes a transition in FSM A and triggers an event through ifcB. If
that event is illegal in the current state of FSM B, the transition
in FSM A does not take place and the event in ifcA fails too. This
property greately simplifies interactions between FSMs, however if a
state transition triggers multiple events, it can be quite hard to
keep track all the events indirectly generated and be prepared to
roll back all of them if someone fails. This can be a source of
ambiguities, so it will be avoided as much as possible and introduced
only when the very nature of SIP negotiation mandates them. An
explanatory note will be added whenever this happens, to describe how
the rollback procedure should behave.
Cuda & Marocco Expires July 20, 2006 [Page 5]
Internet-Draft A Formal Model for Media Negotiation January 2006
An event is a message sent and or received by a FSM. It belongs to
one and only one interface and it is identified by a string in the
form:
<ifc><direction>_<name>
where:
o ifc is a single letter which uniquely identifies the interface
o direction identifies the direction of the signal. It can be
either "u" (upstream), if moving from the transaction layer
towards the application layer or "d" (downstream) if moving in the
opposite direction.
o name is the name of the event
In some cases, it is not possible to give an event a definite
direction. For instance if two state machines should synchronize
each other in order to generate a composite event, they need to
generate events that do not fall in a "downstream" nor in an
"upstream" category. These events' direction flag will therefore be
"x", i.e. their label will be in the form:
<ifc>x_<name>
These events have different nature than those whose direction can be
clearly identified, so in the remainder of this document we well
refer to them as "non-negotiation" events, in contrast to
"negotiation" events whose direction of propagation can unambiguously
defined to be upstream or downstream.
Events belonging to the interface between the FSM networks and the
transaction layer will be defined in couples sharing the same "name"
identifier: one event moving upstream and the other moving
downstream. When, as a result of the interconnection of two User
Agents, their respective FSM networks (n1 and n2) are connected to
each other, a downstream event generated by n1 towards the
transaction layer, will cause the transaction layer of n2 to deliver
the upstream event to n2, and vice versa. In the example of figure
Figure 1, if n1 generates the event "cd_example" (belonging to
interface ifcC), then n2 will receive an event "cu_example".
This property can be extended to all the negotiation events, and it
is useful as a consistency check: all the FSMs must be built in a way
that if two networks are interconnected to each other an event "Xd_Y"
on one network must (directly or indirectly) originate an event
"Xu_Y" on the other network. Note, however, that this does not hold
Cuda & Marocco Expires July 20, 2006 [Page 6]
Internet-Draft A Formal Model for Media Negotiation January 2006
true for non-negotiation signals.
[TODO: Explain better difference between negotiation and non-
negotiation events]
Cuda & Marocco Expires July 20, 2006 [Page 7]
Internet-Draft A Formal Model for Media Negotiation January 2006
4. State Machines Interfaces
4.1. External Interfaces
4.1.1. Grouping Events into Interfaces
The first step is to identify which events are needed to interact
with the two networks. Events need be grouped into interfaces
according to which FSMs they are delivered to, so choosing to group
signals according to different arrangements leads to different FSM
configurations. In particular, it is important that events related
to the same set of transactions belong to the same interface. In
addition, to keep state machines as simple as possible, events
related to different sets of transactions must belong to different
interfaces.
Strictly speaking, this document only relates to the negotiation
state machine, so on the application side, only events related to
negotiation should be considered. It is true, however, that in SIP
negotiation and session establishement are so intimately related
(since they are provided by the same method, i.e. INVITE) that also
session related events should be taken into consideration.
The strong liaison between session negotiation and session
establishement is however just a feature of the protocol, so while
the two sets of events simply can't be separated on the Transaction
Layer side, it is an useful abstraction to keep them on different
interfaces on the Application side. If we accept these design
choices, a first sketch of the system is:
| FSM Network |
||||||||||||||||||||||||||||||||
| : |
ifcI | : | ifcS
<-+-> Session : <-+->
| FSM : Signalling |
| : FSM |
Application |.............: | Transaction
Layer | : | Layer
| Negotiation : |
ifcN | FSM : |
<-+-> : |
| : |
|||||||||||||||||||||||||||||||||
| |
Figure 4
Cuda & Marocco Expires July 20, 2006 [Page 8]
Internet-Draft A Formal Model for Media Negotiation January 2006
Where mutual relationships between state machines, i.e. internal
interfaces, are deliberately left out.
4.1.2. FSM Tasks
It is important, at this stage, to define clearly which tasks these
FSMs must accomplish, and which ones they must not, to avoid gaps and
overlaps in their interfaces and behaviour. As a general rule:
o The Signalling State machine must handle all the events coming
from the Transaction Layer, translating them into events that are
as least SIP-related as possible. In doing this, however, it must
not take decisions that could affect the negotiation process. For
instance, it must not automatically send an ACK request when
receiving an 2xx INVITE response because the Negotiation FSM might
need to insert a session descriptor to complete negotiation
exchanges;
o The Session State Machine must translate events coming from the
Signalling State Machine into pure session-related events (i.e.
without any negotiation implications) and vice versa. As such, it
is part of its core logic processing the initial INVITE
transaction, the BYE transaction and other session-related
messages;
o The Negotiation State Machine must translate events coming from
the Signalling State Machine into pure negotiation-related events
(i.e. without any session-related implications) and vice versa.
As such, it is part of its core logic processing session
descriptors contained in re-INVITE, PRACK and UPDATE messages;
One questionable point is whether the Session State Machine must be
involved when processing re-INVITEs or not. From a purely functional
point of view, the answer should be "no", since a re-INVITE is not
relevant for session life (e.g. if it fails, the communication is not
torn down). However, everything which is allowed inside of an INVITE
request (like UPDATE, PRACK) is also allowed in re-INVITEs, so having
the session state machine process them simplifies the state machines
because it can avoid some redundancy by reusing part of the logic.
This is therefore the approach we will follow in this document.
When trying to put the three state machines together, the most
relevant issue to solve is how to combine session and negotiation
events into a single signalling event. For instance, when sending
the initial INVITE, if a session descriptor must be provided, the
session and negotiation events must be properly coordinated in order
to build the initial INVITE request.
Cuda & Marocco Expires July 20, 2006 [Page 9]
Internet-Draft A Formal Model for Media Negotiation January 2006
+-------+ +-------+ +-------+
| ifc I | | ifc N | | ifc S |
+-------+ +-------+ +-------+
| | |
Formulate an offer | ^^^^^^^^^^^^^^^^^^^. |
------------------------>| { Synchronization } |
Place a call | | { Logic } |
------------>| | { } |
| | vvvvvvvvvvvvvvvvvvv | INVITE + SD
| | |-------->
Figure 5
The same happens on the UAS side: if an incoming INVITE is received,
there must be a way for the application to reply 200 with a session
descriptor:
+-------+ +-------+ +-------+
| ifc I | | ifc N | | ifc S |
+-------+ +-------+ +-------+
| | |
| | |
| | | INVITE
| (Events get propagated) |<-----------
Incoming call|<=================================>|
<------------| | |
| | |
Formulate an offer | ^^^^^^^^^^^^^^^^^^^. |
------------------------>| { Synchronization } |
Accept call | | { Logic } |
------------>| | { } |
| | vvvvvvvvvvvvvvvvvvv | 200 Ok + SD
| | |------------>
Figure 6
Here the problem is even more complex, since there must be a way for
the application to choose whether to put the session descriptor into
the 2xx response or in some provisional response sent beforehand.
The complexity comes from the fact that the two events from the
Application are the same as the ones in the previous scenario.
Cuda & Marocco Expires July 20, 2006 [Page 10]
Internet-Draft A Formal Model for Media Negotiation January 2006
+-------+ +-------+ +-------+
| ifc I | | ifc N | | ifc S |
+-------+ +-------+ +-------+
| | |
| | |
| | | INVITE
| (Events get propagated) |<-----------
Incoming call|<=================================>|
<------------| | |
| | |
Formulate an offer | ^^^^^^^^^^^^^^^^^^^. |
------------------------>| { Synchronization } | 183 + SD
Accept call | | { Logic } |------------>
------------>| | { } |
| | vvvvvvvvvvvvvvvvvvv | 200 Ok + SD
| | |------------>
Figure 7
A possible solution of this problem is to put the synchronization
logic into the application, and define events into ifcI that affect
both session and negotiation. Another option consists in putting the
synchronization inside of the FSM network and defining a convention
on the order in which events are generated.
Both solutions are viable, but they suffer from a common
disadvantage: they inevitably put some negotiation logic into the
session FSM and/or some session logic into the negotiation. The
first approach leads to a simpler interface for the application
because there are no sequencing rules apart from those that are
intrinsic to the negotiation process. The other approach, on the
other hand, requires some extra conventions on the Application side,
however the resulting state machines are simpler and less redundant.
Keeping state machines as simple as possible is one of the primary
goals of this document, so the second apporach looks more promising,
however another important goal is to avoid as much as possible the
situation in which a task is partly performed by a state machine and
partly in another. To mitigate this, a new state machine whose only
task is to synchronize and compose outbound events, as well as to
decomponse inbound events is added.
Cuda & Marocco Expires July 20, 2006 [Page 11]
Internet-Draft A Formal Model for Media Negotiation January 2006
| FSM Network |
|||||||||||||||||||||||||||||||||||||||||||
| : |
ifcI | : Signalling | ifcS
<-+-> Session : FSM <-+->
| FSM : |
| ................... |
| : : |
| : Synchronization : |
Application |.........: FSM : | Transaction
Layer | : : | Layer
| :.................: |
| : |
| Negotiation : |
ifcN | FSM : |
<-+-> : |
| : |
|||||||||||||||||||||||||||||||||||||||||||
| |
Figure 8
Having done this, it is important to define this "extra" protocol
between the Application and the state machines, i.e. what's the order
of signals applied to the ifcI and ifcN interfaces that will be
interpreted by the FSM network as a request to send a specific event
(e.g. issue an INVITE request with a session descriptor), or another
(e.g. issue an INVITE request without session descriptor). This
can't be done at this point because events are not defined yet: it
will be however discussed right after defining external interfaces
(see Section 4.1.6).
4.1.3. The Signalling Interface (ifcS)
The ifcS interface is the easiest to define, since it is just an
event-oriented abstraction of the interface between the Transaction
Layer and the Transaction User Layer, which is defined in [RFC3261].
It is not a complete mapping, of course , and most of the details are
out of scope, so the following events suffice for our purposes:
Cuda & Marocco Expires July 20, 2006 [Page 12]
Internet-Draft A Formal Model for Media Negotiation January 2006
+------------------------+-----------------+------------------------+
| event | With proposal | Without proposal |
+------------------------+-----------------+------------------------+
| INVITE | s[du]_invite_sd | s[du]_invite |
| | | |
| reINVITE | s[du]_invite_sd | s[du]_invite |
| | | |
| INVITE provisional | s[du]_1xxi_sd | n/a |
| answer | | |
| | | |
| INVITE success | s[du]_2xxi_sd | s[du]_2xxi |
| response | | |
| | | |
| INVITE failure | n/a | s[du]_Xxxi |
| response | | |
| | | |
| ACK | s[du]_ack_sd | s[du]_ack |
| | | |
| PRACK | s[du]_prack_sd | s[du]_prack |
| | | |
| PRACK success response | s[du]_2xxp_sd | s[du]_2xxp |
| | | |
| PRACK failure response | n/a | s[du]_Xxxp |
| | | |
| UPDATE | s[du]_update_sd | n/a |
| | | |
| UPDATE success | s[du]_2xxu_sd | UPDATE failure |
| response | | response |
| | | |
| n/a | s[du]_Xxxu | CANCEL |
| | | |
| n/a | s[du]_cancel | BYE |
| | | |
| n/a | s[du]_bye | |
+------------------------+-----------------+------------------------+
The most common form of proposal is an SDP body inside of a message
body. However the format needs not be SDP and some other kind of
negotiation may be implied by future extensions of the SIP protocol
without affecting the model.
4.1.4. The Session Interface (ifcI)
On the application side, events are not that straightforward to
define, since this interface is outside the scope of the SIP core
specification, and also the separation between the session interface
and the negotiation interface is convenient but in some ways
arbitrary.
Cuda & Marocco Expires July 20, 2006 [Page 13]
Internet-Draft A Formal Model for Media Negotiation January 2006
The set of events we propose for IfcI is:
+--------------------+--------------+
| Event | Name |
+--------------------+--------------+
| Open a new session | i[du]_create |
| | |
| Close a session | i[du]_close |
| | |
| Accept a session | i[du]_accept |
+--------------------+--------------+
4.1.5. The Negotiation Interfaces (ifcN)
The negotiation handshake is essentially a sequence of offers and
answers, so this interface allows to formulate offers and reply with
answers. Once an offer is received, the Application must react
immediately, by rejecting it or answering with a new session
descriptor.
Given the flexibility in SIP negotiation, an offer and an answer can
be urgent or not:
An urgent offer or answer is immediately delivered to the other
party;
A non-urgent offer is deferred until the session is established.
The scenario in which this distinction is most clear is when an
INVITE request is received: if it contains a session descriptor, the
Application might already be able to formulate an answer, but this
does not necessarily mean that it is willing to send it immediately.
Depending on the fact that the answer is tagged as "urgent" or not,
the session descriptor will be encapsulated into an ad-hoc 183
reliable response or it is deferred until the user answers (i.e. it
will be encapsulated into the 2xx response).
Non-urgent proposals may be updated by an urgent proposal, or by
another non-urgent proposal. The former event "clears" the proposal
and forces delivery of the proposal to the other endpoint. The
latter does not cause a state switch but it only updates the session
descriptor.
Urgency of offers is a purely applicative characteristic, and cannot
be stated independently by the Negotiation state machine, therefore
some specific events need to be introduced:
Cuda & Marocco Expires July 20, 2006 [Page 14]
Internet-Draft A Formal Model for Media Negotiation January 2006
+-------------------------------------------+------------------+
| Event | Name |
+-------------------------------------------+------------------+
| Make an urgent offer | n[du]_urg_offer |
| | |
| Make an offer | n[du]_offer |
| | |
| Make an interactive offer | n[du]_int_offer |
| | |
| Accept an offer and send an urgent answer | n[du]_urg_answer |
| | |
| Accept an offer and send an answer | n[du]_answer |
| | |
| Accept an answer | n[du]_accept |
| | |
| Reject an offer | n[du]_reject |
+-------------------------------------------+------------------+
The difference between an interactive offer and a non interactive
offer is in whether the session update request must be approved by
the other endpoint's user or not. An interactive offer must be
mapped into an INVITE transaction and a non-interactive proposal into
an UPDATE transaction. Interactive negotiations can only happen once
the session has been fully established, and are always urgent (since
they immediately generate a re-INVITE request).
Accepting an answer by sending nd_accept acknowledges its reception.
This event is needed because, in SIP, transaction related messages
can carry session descriptors. For instance, if a 18x INVITE
response containing a session descriptor is received, the Signalling
State Machine must be able to tell whether the PRACK request shall
contain a session descriptor or not. If, as a result of delivering
the vu_answer event to the application, it receives a vd_offer event,
it will encapsulate a session descriptor in the PRACK request. If it
receives an vd_accept event, the PRACK request won't contain any
session descriptor.
[TODO: Clarify with example]
4.1.6. Rules of Composition
As anticipated in Section 4.1.2, the interface between the FSM
network and the external world is ambiguous unless complemented by a
set of rules describing when and how session and negotiation events
must be composed into a single signalling event.
Cases that could raise ambiguities are summarized in the table below:
Cuda & Marocco Expires July 20, 2006 [Page 15]
Internet-Draft A Formal Model for Media Negotiation January 2006
+---+-----------+-------------+--------------+
| | Session | Negotiation | Signalling |
+---+-----------+-------------+--------------+
| 1 | id_create | nd_offer | sd_invite_sd |
| | | | |
| 2 | id_create | - | sd_invite |
| | | | |
| 3 | id_accept | nd_* | sd_2xxi_sd |
| | | | |
| 4 | - | nd_* | sd_1xxi_sd |
+---+-----------+-------------+--------------+
Table 4
Cases (1) and (2) happen when establishing an outbount call, in the
scenario of Figure 5. There is no such ambiguity when sending a re-
INVITE, because it is triggered by a single event (nd_int_offer), so
the simplest solution seems to give a meaning to the order in which
signalling and negotiation events are generated:
+---+---------------------+--------------+
| | Events | Signalling |
+---+---------------------+--------------+
| 1 | nd_offer, id_create | sd_invite_sd |
| | | |
| 2 | id_create | sd_invite |
+---+---------------------+--------------+
The difference between an urgent proposal and a non-urgent proposal
is meaningless in case (1), so it seems natural to forbid urgent
proposals at this stage.
Cases (3) and (4), instead, can be disambiguated thanks to the
"urgency mechanism": an urgent answer will immediately trigger a 183
response (Figure 7, while a non urgent answer will wait for the
id_accept event to be composed with:
+-----+----------------------+------------+
| | Events | Signalling |
+-----+----------------------+------------+
| 3' | nd_offer, id_accept | sd_2xxi_sd |
| | | |
| 3'' | nd_answer, id_accept | sd_2xxi_sd |
| | | |
| 4' | nd_urg_offer | sd_1xxi_sd |
| | | |
| 4'' | nd_urg_answer | sd_1xxi_sd |
+-----+----------------------+------------+
Cuda & Marocco Expires July 20, 2006 [Page 16]
Internet-Draft A Formal Model for Media Negotiation January 2006
4.2. Internal Interfaces
4.2.1. Which Interactions are Needed
In the FSM network, the Synchronization State Machine plays a central
role: it must receive events from the Session and Negotiation State
Machines, compose them if necessarily and deliver the resulting
events to the Signalling State Machine. Conversely, it must receive
composite events from the Signalling State Machine and break them
into pure session and negotiation events.
To accomplish these tasks, the Synchronization State Machine needs an
interface towards each other state machine. It seems therefore
natural to treat this FSM as an hub, delivering all the events
(including those that do not need composition nor descomposition)
from one FSM to another. Following this approach, the internal
structure becomes:
| FSM Network |
|||||||||||||||||||||||||||||||||||||||||||
| : |
ifcI | : Signalling | ifcS
<-+-> Session : FSM <-+->
| FSM : |
| ................... |
| <-+-> : |
| IfcA : Synchronization : |
Application |.........: FSM : IfcU | Transaction
Layer | <-+-> <-+-> | Layer
| IfcV :.................: |
| : |
| Negotiation : |
ifcN | FSM : |
<-+-> : |
| : |
|||||||||||||||||||||||||||||||||||||||||||
| |
Figure 9
4.2.2. Synchronization-Signalling Interface (ifcU)
The ifcU interface is primarly the interface that the Signalling FSM
exposes, so the events that should be exchanged there provide the
highest possible abstraction of SIP transactions without knowledge of
the distinction between the session and the negotiation part.
In the model we propose, offers and answers (collectively called
Cuda & Marocco Expires July 20, 2006 [Page 17]
Internet-Draft A Formal Model for Media Negotiation January 2006
"proposals" from now on) may be exchanged inside or outside of a
"negotiation scope". Negotiation scopes carry no semantic meaning:
proposals belonging to the same scope do not need having anything in
common, however they must complete before the scope is closed. On
the transaction layer interface, negotiation scopes map to INVITE and
reINVITE transactions, while negotiations map to UPDATE and PRACK
transactions. This abstraction is useful to define the life of an
instance of the Signalling state machine, which spans the life of
negotiation scope or a single negotiation in case scopes are not
used. There is actually an important difference between a
negotiation scope created by an INVITE and one created by a reINVITE,
since the former has some additional limitations in messages that can
be exchanged until a confirmed dialog is established. To inform the
Signalling State machine about this difference, specific events for
the dialog-establishing negotiation scopes and for in-dialog
negotiation scopes are defined.
Given that, this is the list of events which are needed on the ifcU
interface:
+------------------------------------------------+------------------+
| Event | Name |
+------------------------------------------------+------------------+
| Create the negotiation scope and establish | u[du]_open |
| dialog | |
| | |
| Create a negotiation scope, make proposal and | u[du]_open_pro |
| establish dialog | |
| | |
| Create in dialog negotiation scope | u[du]_reopen |
| | |
| Create in dialog negotiation scope and make | u[du]_reopen_pro |
| proposal | |
| | |
| Close a negotiation scope | u[du]_close |
| | |
| Close a negotiation scope and make a proposal | u[du]_close_pro |
| | |
| Abort an outbound negotiation scope | u[du]_cancel |
| | |
| Abort an inbound negotiation scope | u[du]_decline |
| | |
| Send a proposal | u[du]_propose |
| | |
| Accept a proposal | u[du]_accept |
| | |
| Reject a proposal | u[du]_reject |
| | |
Cuda & Marocco Expires July 20, 2006 [Page 18]
Internet-Draft A Formal Model for Media Negotiation January 2006
| Terminate session | u[du]_end_sesson |
+------------------------------------------------+------------------+
Accepting a proposal by sending ud_accept carries the same meaning of
the corresponding signal in the ifcN interface.
4.2.3. Session-Synchronization Interface (ifcA)
The ifcA interface is the result of the decomposition of the events
of the ifcU interface operated by the Synchronization State Machine.
In particular, it must contain:
+------------------------------------------------+------------------+
| Event | Name |
+------------------------------------------------+------------------+
| Create a negotiation scope and establish | a[du]_open |
| dialog | |
| | |
| Create an in dialog negotiation scope | a[du]_reopen |
| | |
| Close a negotiation scope | a[du]_close |
| | |
| Abort an outbound negotiation scope | a[du]_cancel |
| | |
| Abort an inbound negotiation scope | a[du]_decline |
| | |
| Terminate session | a[du]_end_sesson |
+------------------------------------------------+------------------+
The meaning of these events is the same of the couterparts in the
ifcU interface.
4.3. Session-Negotiation Interface (ifcV)
By applying the same rule, this interface can be made to comprise
very few events. To keep the model as simple as possible, there is
not even a distinction between an offer and an answer: all the events
are generic proposals. It will be up to the negotiation state
machine to make sure that offers are properly coupled with answers:
Cuda & Marocco Expires July 20, 2006 [Page 19]
Internet-Draft A Formal Model for Media Negotiation January 2006
+------------------------------------+-------------------+
| Event | Name |
+------------------------------------+-------------------+
| Make or receive a proposal | v[du]_propose |
| | |
| Make or receive an urgent proposal | v[du]_urg_propose |
| | |
| Accept a proposal | v[du]_accept |
| | |
| Reject a proposal | v[du]_reject |
+------------------------------------+-------------------+
The definition of urgent answer (and offer) also applies to
proposals.
Cuda & Marocco Expires July 20, 2006 [Page 20]
Internet-Draft A Formal Model for Media Negotiation January 2006
5. State Machine Definition
5.1. Session State Machine
A Session State Machine is created:
o By the Application, when establishing an outgoing call;
o By the Synchronization State Machine, when an inbound call request
is received
In both cases, the initial state of this state machine is INIT. When
servicing an inbound call, the state machine enters the INBOUND
state; when an outbound call is attempted, the state machine enters
the OUTBOUND state instead. Depending on the outcome of the inbound
or outbound call, it can enter the ESTABLISHED or the TERM state.
A graphical representation of this state machine is:
+---------+
| INIT |
+---------+
| |
+-------+ +-------+
| |
v v
+----------+ +---------+
| OUTBOUND | | INBOUND |
+----------+ +---------+
| |
+-------+ +-------+
| | | |
| v v |
| +-------------+ |
| | ESTABLISHED | |
| +-------------+ |
| | |
| v |
| +-------------+ |
+-->| TERM |<--+
+-------------+
Cuda & Marocco Expires July 20, 2006 [Page 21]
Internet-Draft A Formal Model for Media Negotiation January 2006
+-----------+-------------+-------------+-------------+-------------+
| | INIT | INBOUND | OUTBOUND | ESTAB |
+-----------+-------------+-------------+-------------+-------------+
| id_create | OUTBOUND / | - / e(500) | - / e(500) | - / e(500) |
| | ad_open | | | |
| | | | | |
| id_close | - / e(481) | TERM / | TERM / | TERM / |
| | | ad_decline | ad_cancel | ad_hangup |
| | | | | |
| id_accept | - / e(481) | ESTAB / | - / e(500) | - / e(500) |
| | | ad_close | | |
+-----------+-------------+-------------+-------------+-------------+
State transition table for events coming from ifcI
+------------+--------------+-----------+--------------+------------+
| | INIT | INBOUND | OUTBOUND | ESTAB |
+------------+--------------+-----------+--------------+------------+
| au_open | INBOUND / | - / | - / e(491) | - / E |
| | iu_create | e(500) | | |
| | | | | |
| au_reopen | - / E(481) | - / | - / e(491) | - / |
| | | e(500) | | [t.b.i] |
| | | | | |
| au_close | - / e(481) | - / E | ESTAB / | - / E |
| | | | iu_accept | |
| | | | | |
| au_cancel | - / e(481) | TERM / | - / e(481) | - / E |
| | | iu_close | | |
| | | | | |
| au_decline | - / e(481) | - / | TERM / | - / E |
| | | e(481) | iu_close | |
| | | | | |
| au_hangup | - / e(481) | TERM / | TERM / | TERM / |
| | | iu_close | iu_close | iu_close |
+------------+--------------+-----------+--------------+------------+
State transition table for events coming from ifcA
5.2. Negotiation State Machine
A Session State Machine does not need to last longer than an offer,
since its main task is to keep track of offers and couple them with
their corresponding answers. It is therefore created:
o By the Application, when formulating a new offer;
Cuda & Marocco Expires July 20, 2006 [Page 22]
Internet-Draft A Formal Model for Media Negotiation January 2006
o By the Signalling State Machine, when an inbound offer is received
When created, it enters the INIT state, immediately switching the the
OFFERING or ANSWERING state depending on the direction of the offer.
When the negotiation completes, the FSM enters the TERM state and is
destroyed.
+---------+
| INIT |
+---------+
| |
+-------+ +-------+
| |
v |
+----------+ |
| OFFERING |-----+ v
+----------+ | +-----------+
| ^ | | ANSWERING |
v | | +-----------+
+----------+ | |
| CLOSING | | |
+----------+ | |
| | |
+-------+ | +-------+
| | |
v v v
+-------------+
| TERM |
+-------------+
+--------------+-------------+----------+-------------+-------------+
| | INIT | OFFERING | ANSWERING | CLOSING |
+--------------+-------------+----------+-------------+-------------+
| nd_offer | OFFERING / | - / | - / e(491) | OFFERING / |
| | vd_prop | e(500) | | vd_prop |
| | | | | |
| nd_answer | - / e(481) | - / | TERM / | - / e(481) |
| | | e(481) | vd_prop | |
| | | | | |
| nd_accept | - / e(481) | - / | - / e(481) | TERM / |
| | | e(481) | | vd_accept |
| | | | | |
| nd_reject | - / e(481) | - / | TERM / | - / e(481) |
| | | e(481) | vd_reject | |
| | | | | |
| nd_urg_offer | OFFERING / | - / | - / e(491) | OFFERING / |
| | vd_urg_prop | e(500) | | vd_urg_prop |
| | | | | |
Cuda & Marocco Expires July 20, 2006 [Page 23]
Internet-Draft A Formal Model for Media Negotiation January 2006
| nd_urg_answ | - / e(481) | - / | TERM / | - / e(481) |
| | | e(481) | vd_urg_prop | |
+--------------+-------------+----------+-------------+-------------+
State transition table for events coming from ifcN
+------------+----------------+---------------+-----------+---------+
| | INIT | OFFERING | ANSWERING | CLOSING |
+------------+----------------+---------------+-----------+---------+
| vu_propose | ANSWERING / | CLOSING / | - / | - / |
| | nu_offer | nu_answer | e(491) | e(500) |
| | | | | |
| vu_urg_pro | ANSWERING / | TERM / | - / | - / |
| | nu_offer | nu_answer | e(500) | e(500) |
| | | | | |
| vu_accept | - / - | - / E | - / | - / |
| | | | e(500) | e(500) |
| | | | | |
| vu_reject | - / E | TERM / | - / | - / |
| | | nu_reject | e(500) | e(500) |
+------------+----------------+---------------+-----------+---------+
State transition table for events coming from ifcV
5.3. Synchronization State Machine
The Synchronization State Machine is created:
o By the Session State Machiine when establishing an outgoing call;
o By the Signalling State Machine, when an inbound call request is
received
The only task of this state machine is to compose and decompose
events. Decomposing events does not imply synchronization, therefore
it does not cause any state switch. On the other hand, composition
is needed only before the dialog has been completely established.
That's why, once session is established, there is no further need for
synchronization, and events are simply "tunnelled" from Session and
Negotiation State Machines towards the Signalling State Machine, and
vice versa.
The resulting state machine is fairly simple: when created it enters
the IDLE state. The state machine must be prepared to receive non-
urgent proposals before session is established. In that case it must
"buffer" the session descriptor, waiting for an outbound message
which can vehicle it. To keep track of this, the state machine
enters the PROPOSAL state until the session is established.
Cuda & Marocco Expires July 20, 2006 [Page 24]
Internet-Draft A Formal Model for Media Negotiation January 2006
Disambiguation of cases in Table 4 is operated in the same way: cases
(1) and (3) are seen as non-urgent proposals formulated before
session is fully established, so they cause a switch to the PROPOSAL
state. The difference between the two cases only lies in the ifcI
event that clears the state, which is an outbound call attempt for
case (1) and an inbound call answer for case (3).
+---------+
| IDLE |
+---------+
| ^
| |
+-------+ +-------+
| |
v v
+----------+ +----------+
| RELAY |<---------| PROPOSAL |
+----------+ +----------+
+------------+----------------+---------------------+---------------+
| | IDLE | PROPOSAL | RELAY |
+------------+----------------+---------------------+---------------+
| ad_open | - / ud_open | IDLE / ud_open_pro | - / ud_open |
| | | | |
| ad_reopen | - / ud_reopen | IDLE / | - / ud_reopen |
| | | ud_reopen_pro | |
| | | | |
| ad_close | RELAY / | RELAY / | - / ud_close |
| | ud_close | ud_close_pro | |
| | | | |
| ad_cancel | - / ud_cancel | - / ud_cancel | - / ud_cancel |
| | | | |
| ad_decline | - / ud_decline | - / ud_decline | - / |
| | | | ud_decline |
| | | | |
| ad_hangup | - / ud_hangup | - / ud_hangup | - / ud_hangup |
+------------+----------------+---------------------+---------------+
State transition table for events coming from ifcA
Cuda & Marocco Expires July 20, 2006 [Page 25]
Internet-Draft A Formal Model for Media Negotiation January 2006
+----------------+----------------+---------------+----------------+
| | IDLE | PROPOSAL | RELAY |
+----------------+----------------+---------------+----------------+
| vd_propose | PROPOSAL / - | - / e(500) | - / ud_propose |
| | | | |
| vd_urg_propose | - / ud_propose | - / e(500) | - / ud_propose |
| | | | |
| vd_accept | - / ud_accept | - / ud_accept | - / ud_accept |
| | | | |
| vd_reject | - / ud_reject | - / ud_reject | - / ud_reject |
+----------------+----------------+---------------+----------------+
State transition table for events coming from ifcV
+---------------+------------------+---------------+----------------+
| | IDLE | PROPOSAL | RELAY |
+---------------+------------------+---------------+----------------+
| uu_open | - / au_open | - / au_open | - / au_open |
| | | | |
| uu_reopen | - / au_reopen | - / au_reopen | - / au_reopen |
| | | | |
| uu_open_pro | - / vu_propose, | - / | - / |
| | au_open | vu_propose, | vu_propose, |
| | | au_open | au_open |
| | | | |
| uu_reopen_pro | - / | - / | - / |
| | au_reopen_pro | au_reopen_pro | au_reopen_pro |
| | | | |
| uu_close | RELAY / au_close | - / e(491) | - / au_close |
| | | | |
| uu_close_pro | RELAY / | - / e(419) | - / |
| | vu_propose, | | vu_propose, |
| | au_close | | au_close |
| | | | |
| uu_cancel | - / au_cancel | - / au_cancel | - / au_cancel |
| | | | |
| uu_decline | - / au_decline | - / | - / au_decline |
| | | au_decline | |
| | | | |
| uu_propose | - / vu_propose | - / | - / vu_propose |
| | | vu_propose | |
| | | | |
| uu_accept | - / vu_accept | - / vu_accept | - / vu_accept |
| | | | |
| uu_reject | - / vu_reject | - / vu_reject | - / vu_reject |
| | | | |
| uu_hangup | - / au_hangup | - / au_hangup | - / au_hangup |
+---------------+------------------+---------------+----------------+
Cuda & Marocco Expires July 20, 2006 [Page 26]
Internet-Draft A Formal Model for Media Negotiation January 2006
State transition table for events coming from ifcU
5.4. Signalling State Machine
5.4.1. Overall State Machine
The Signalling State Machine is created:
o By the Session State Machine when establishing an outgoing call;
o By the Transaction Layer, when an inbound INVITE request is
received
If this FSM is created to exchange proposals inside of a negotiation
scope, its life is limited to that negotiation scope. If it is
created to exchange proposals outside of a negotiation scope, it is
limited to that proposal.
Though the behaviour is essentially the same, this distinction leads
to two different state machines, which are discussed separately for
clarity purposes. The overall machine can however be sketched like
this:
+----------+
| INIITIAL |
+----------+
| |
| |
+-------+ +-------+
| |
v v
+===========+ +==========+
| SCOPE_FSM | | PROP_FSM |
+===========+ +==========+
Cuda & Marocco Expires July 20, 2006 [Page 27]
Internet-Draft A Formal Model for Media Negotiation January 2006
+---------------+---------------------------------+
| | INIT |
+---------------+---------------------------------+
| ud_open | SCOPE_FSM.INIT / sd_invite |
| | |
| ud_open_pro | SCOPE_FSM.INIT / sd_invite_sd |
| | |
| ud_reopen | SCOPE_FSM.IDLE / sd_reinvite |
| | |
| ud_reopen_pro | SCOPE_FSM.IDLE / sd_reinvite_sd |
| | |
| ud_close | - / e(481) |
| | |
| ud_close_pro | - / e(481) |
| | |
| ud_cancel | - / e(481) |
| | |
| ud_decline | - / e(481) |
| | |
| ud_propose | PROP_FSM.INIT / sd_update_sd |
| | |
| ud_accept | - / e(481) |
| | |
| ud_reject | - / e (481) |
| | |
| ud_hangup | TERM / sd_bye |
+---------------+---------------------------------+
State transition table for events coming from ifcU.
+----------------+------------------------------+
| | INIT |
+----------------+------------------------------+
| su_invite_sd | SCOPE_FSM.INIT / uu_open_pro |
| | |
| su_invite | SCOPE_FSM.INIT / uu_open |
| | |
| su_reinvite_sd | SCOPE_FSM.IDLE / uu_open_pro |
| | |
| su_reinvite | SCOPE_FSM.IDLE / uu_open |
| | |
| su_1xxi_sd | - / e(481) |
| | |
| su_1xxi | - / e(481) |
| | |
| su_1xxirel_sd | - / e(481) |
| | |
| su_1xxirel | - / e(481) |
Cuda & Marocco Expires July 20, 2006 [Page 28]
Internet-Draft A Formal Model for Media Negotiation January 2006
| su_2xxi_sd | - / e(481) |
| | |
| su_2xxi | - / e(481) |
| | |
| su_Xxxi | - / e(481) |
| | |
| su_ack_sd | - / e(481) |
| | |
| su_ack | - / e(481) |
| | |
| su_prack_sd | - / e(481) |
| | |
| su_prack | - / e(481) |
| | |
| su_2xxp_sd | - / e(481) |
| | |
| su_2xxp | - / e(481) |
| | |
| su_Xxxp | - / e(481) |
| | |
| su_update_sd | PROP_FSM.INIT / uu_propose |
| | |
| su_2xxu_sd | - / e(481) |
| | |
| su_Xxxu | - / e(481) |
| | |
| su_cancel | - / e(481) |
| | |
| su_bye | TERM / uu_hangup |
+----------------+------------------------------+
State transition table for events coming from ifcS.
Cuda & Marocco Expires July 20, 2006 [Page 29]
Internet-Draft A Formal Model for Media Negotiation January 2006
5.4.2. Scope State Machine
+----------+
| INIT |--------------------------+
+----------+ |
| | |
+---------+ +-------+ |
| | |
v v |
+------------+ +-----------+ |
| PROV_OUT | | PRACK_OUT | |
+------------+ +-----------+ |
^ ^ |
| | |
+-------+ +-------+ |
| | |
v v |
+------------+ +---------+ +------------+ |
| UPDATE_IN |<--------->| IDLE |<--------->| UPDATE_OUT | |
+------------+ +---------+ +------------+ |
^ | ^ \_________________ |
| | | | |
+-------+ | +-------+ | |
| | | | |
v | v | |
+-----------+ | +----------+ | |
| PROV_IN | | | PRACK_IN | | |
+-----------+ | +----------+ | |
| | |
v v |
+----------+ +----------+ |
| ACCEPTED |---------->| TERM |<--+
+----------+ +----------+ |
^ |
| |
+--------------------------------+
Cuda & Marocco Expires July 20, 2006 [Page 30]
Internet-Draft A Formal Model for Media Negotiation January 2006
+--------------+----------------+--------------------+--------------+
| | INIT | IDLE | ACCEPTED |
+--------------+----------------+--------------------+--------------+
| ud_open | - / E | - / E | - / E |
| | | | |
| ud_open_pro | - / E | - / E | - / E |
| | | | |
| ud_close | ACCEPTED / | ACCEPTED / sd_2xxi | - / E |
| | sd_2xxi | | |
| | | | |
| ud_close_pro | ACCEPTED / | ACCEPTED / | - / E |
| | sd_2xxi_sd | sd_2xxi_sd | |
| | | | |
| ud_cancel | - / E | TERM / sd_cancel | - / E |
| | | | |
| ud_decline | - / E | TERM / sd_Xxxi | - / E |
| | | | |
| ud_propose | PROV_OUT / | UPDATE_OUT / | TERM / |
| | sd_1xx_sd | sd_update_sd | sd_ack_sd |
| | | | |
| ud_accept | - / E | - / - | TERM / |
| | | | sd_ack |
| | | | |
| ud_reject | - / E | - / e(500) | - / e(488) |
| | | | |
| ud_hangup | - / E | - / E | TERM / |
| | | | sd_bye |
+--------------+----------------+--------------------+--------------+
State transition table for events coming from ifcU (1/3).
Cuda & Marocco Expires July 20, 2006 [Page 31]
Internet-Draft A Formal Model for Media Negotiation January 2006
+--------------+--------------+-----------------+-------------------+
| | PROV_IN | PROV_OUT | PRACK_IN |
+--------------+--------------+-----------------+-------------------+
| ud_open | - / E | - / E | - / E |
| | | | |
| ud_open_pro | - / E | - / E | - / E |
| | | | |
| ud_close | - / E | ACCEPTED / | ACCEPTED / |
| | | sd_2xxi | sd_2xxp, sd_2xxi |
| | | | |
| ud_close_pro | - / E | ACCEPTED / | ACCEPTED / |
| | | sd_2xxi_sd | sd_2xxp, |
| | | | sd_2xxi_sd |
| | | | |
| ud_cancel | TERM / | - / E | - / E |
| | sd_cancel | | |
| | | | |
| ud_decline | - / E | TERM / sd_Xxxi | TERM / sd_Xxxi |
| | | | |
| ud_propose | PRACK_OUT / | UPDATE_OUT / | IDLE / sd_2xxp_sd |
| | sd_prack_sd | sd_update_sd | |
| | | | |
| ud_accept | PRACK_OUT / | - / E | IDLE / sd_2xxp |
| | sd_prack | | |
| | | | |
| ud_reject | - / e(488) | - / E | IDLE / sd_Xxxp |
| | | | |
| ud_hangup | - / e(500) | - / E | - / E |
+--------------+--------------+-----------------+-------------------+
State transition table for events coming from ifcU (2/3).
Cuda & Marocco Expires July 20, 2006 [Page 32]
Internet-Draft A Formal Model for Media Negotiation January 2006
+--------------+----------------+---------------------+-------------+
| | PRACK_OUT | UPDATE_IN | UPDATE_OUT |
+--------------+----------------+---------------------+-------------+
| ud_open | - / E | - / E | - / E |
| | | | |
| ud_open_pro | - / E | - / E | - / E |
| | | | |
| ud_close | - / E | ACCEPTED / sd_Xxxu, | ACCEPTED / |
| | | sd_2xxi | sd_2xxi |
| | | | |
| ud_close_pro | - / E | ACCEPTED / | - / E |
| | | sd_2xxu_sd, | |
| | | sd_2xxi, | |
| | | | |
| ud_cancel | TERM / | TERM / sd_Xxxu, | TERM / |
| | sd_cancel | sd_cancel | sd_cancel |
| | | | |
| ud_decline | - / E | TERM / sd_Xxxu, | TERM / |
| | | sd_Xxxi | sd_Xxxi |
| | | | |
| ud_propose | UPDATE_OUT / | IDLE / sd_2xxu_sd | - / E |
| | sd_update_sd | | |
| | | | |
| ud_accept | - / E | - / e(488) | - / E |
| | | | |
| ud_reject | - / E | IDLE / sd_Xxxu | - / E |
| | | | |
| ud_hangup | - / E | - / E | - / E |
+--------------+----------------+---------------------+-------------+
State transition table for events coming from ifcU (3/3).
Cuda & Marocco Expires July 20, 2006 [Page 33]
Internet-Draft A Formal Model for Media Negotiation January 2006
+--------------+------------------+------------------+--------------+
| | INIT | IDLE | ACCEPTED |
+--------------+------------------+------------------+--------------+
| su_invite_sd | - / E | - / e(500) | - / E |
| | | | |
| su_invite | - / E | - / e(500) | - / E |
| | | | |
| su_2xxi_sd | ACCEPTED / | ACCEPTED / | - / E |
| | uu_close_pro | uu_close_pro | |
| | | | |
| su_2xxi | TERM / uu_close, | TERM / uu_close, | - / E |
| | sd_ack | sd_ack | |
| | | | |
| su_Xxxi | TERM / | TERM / | - / E |
| | uu_decline | uu_decline | |
| | | | |
| su_ack_sd | - / e(488) | - / e(488) | TERM / |
| | | | uu_propose |
| | | | |
| su_ack | - / e(488) | - / e(488) | TERM / - |
| | | | |
| su_prack_sd | PRACK_IN / | PRACK_IN / | - / E |
| | uu_propose | uu_propose | |
| | | | |
| su_prack | IDLE / sd_2xxp | IDLE / sd_2xxp | - / E |
| | | | |
| su_2xxp_sd | PRACK_IN / | PRACK_IN / | - / E |
| | uu_propose | uu_propose | |
| | | | |
| su_2xxp | IDLE / - | IDLE / - | - / E |
| | | | |
| su_Xxxp | IDLE / - | IDLE / - | - / E |
| | | | |
| su_update_sd | UPDATE_IN / | UPDATE_IN / | - / e(488) |
| | uu_propose | uu_propose | |
| | | | |
| su_2xxu_sd | ACCEPTED / | ACCEPTED / | - / E |
| | uu_propose | uu_propose | |
| | | | |
| su_cancel | TERM / uu_cancel | TERM / uu_cancel | - / E |
| | | | |
| su_bye | - / E | - / E | - / E |
| | | | |
| su_1xxi_sd | PROV_IN / | PROV_IN / | - / E |
| | uu_propose | uu_propose | |
| | | | |
| su_Xxxu | - / E | - / E | - / E |
+--------------+------------------+------------------+--------------+
Cuda & Marocco Expires July 20, 2006 [Page 34]
Internet-Draft A Formal Model for Media Negotiation January 2006
State transition table for events coming from ifcS (1/3).
+--------------+------------------+------------------+--------------+
| | PROV_IN | PROV_OUT | PRACK_IN |
+--------------+------------------+------------------+--------------+
| su_invite_sd | - / E | - / E | - / E |
| | | | |
| su_invite | - / E | - / E | - / E |
| | | | |
| su_2xxi_sd | ACCEPTED / | - / e(481) | - / e(481) |
| | uu_close_pro | | |
| | | | |
| su_2xxi | TERM / uu_close, | - / e(481) | - / e(481) |
| | sd_ack | | |
| | | | |
| su_Xxxi | TERM / | - / e(481) | - / e(481) |
| | uu_decline | | |
| | | | |
| su_ack_sd | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_ack | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_prack_sd | - / e(481) | IDLE / | - / e(481) |
| | | uu_propose | |
| | | | |
| su_prack | - / e(481) | IDLE / sd_2xxp | - / e(481) |
| | | | |
| su_2xxp_sd | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_2xxp | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_Xxxp | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_update_sd | UPDATE_IN / | UPDATE_IN / | - / e(488) |
| | su_prack | uu_propose | |
| | | | |
| su_2xxu_sd | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_cancel | - / e(481) | TERM / uu_cancel | TERM / |
| | | | uu_cancel |
| | | | |
| su_bye | - / e(481) | TERM / uu_cancel | TERM / |
| | | | uu_cancel |
| | | | |
| su_1xxi_sd | - / (E) sd_prack | - / E | - / E |
| | | | |
| su_Xxxu | - / E | - / E | - / E |
+--------------+------------------+------------------+--------------+
Cuda & Marocco Expires July 20, 2006 [Page 35]
Internet-Draft A Formal Model for Media Negotiation January 2006
State transition table for events coming from ifcS (2/3).
+--------------+---------------+-------------------+----------------+
| | PRACK_OUT | UPDATE_IN | UPDATE_OUT |
+--------------+---------------+-------------------+----------------+
| su_invite_sd | - / E | - / E | - / E |
| | | | |
| su_invite | - / E | - / E | - / E |
| | | | |
| su_2xxi_sd | TERM / | TERM / sd_Xxxu, | TERM / |
| | uu_close_pro | uu_close_pro | uu_close |
| | | | |
| su_2xxi | TERM / | - / uu_close, | TERM / |
| | uu_close, | sd_ack | uu_close, |
| | sd_ack | | sd_ack |
| | | | |
| su_Xxxi | TERM / | - / e(481) | TERM / |
| | uu_decline | | uu_decline |
| | | | |
| su_ack_sd | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_ack | - / e(481) | - / e(481) | - / e(481) |
| | | | |
| su_prack_sd | - / e(481) | - / uu_propose, | - / |
| | | sd_2xxp | uu_propose, |
| | | | sd_2xxp |
| | | | |
| su_prack | - / e(481) | - / sd_2xxp | - / sd_2xxp |
| | | | |
| su_2xxp_sd | IDLE / | - / e(481) | - / e(481) |
| | uu_propose | | |
| | | | |
| su_2xxp | IDLE / - | - / e(481) | - / e(481) |
| | | | |
| su_Xxxp | TERM / - | - / e(481) | - / e(481) |
| | | | |
| su_update_sd | UPDATE_IN / | - / e(500) | - / e(491) |
| | uu_propose | | |
| | | | |
| su_2xxu_sd | - / e(481) | - / e(481) | IDLE / |
| | | | uu_propose |
| | | | |
| su_cancel | - / e(481) | TERM / sd_Xxxu, | TERM / |
| | | uu_decline | uu_decline |
| | | | |
| su_bye | - / e(481) | TERM / sd_Xxxu, | TERM / |
| | | uu_decline | uu_decline |
| | | | |
Cuda & Marocco Expires July 20, 2006 [Page 36]
Internet-Draft A Formal Model for Media Negotiation January 2006
| su_1xxi_sd | - / (E) | - / (E) sd_prack | - / (E) |
| | sd_prack | | sd_prack |
| | | | |
| su_Xxxu | - / E | - / E | - / E |
+--------------+---------------+-------------------+----------------+
State transition table for events coming from ifcS (3/3).
5.4.3. Prop State Machine
+---------+
| INIT |
+---------+
| |
+-------+ +-------+
| |
v v
+-----------+ +------------+
| UPDATE_IN | | UPDATE_OUT |
+-----------+ +------------+
| |
+-------+ +-------+
| |
v v
+-------------+
| TERM |
+-------------+
+------------+-----------------------+-----------------+------------+
| | INIT | UPDATE_IN | UPDATE_OUT |
+------------+-----------------------+-----------------+------------+
| ud_propose | UPDATE_OUT / | TERM / | - / e(500) |
| | sd_update_sd | sd_2xxu_sd | |
| | | | |
| ud_accept | - / E | TERM/ sd_Xxxu | - / e(481) |
| | | | |
| ud_reject | - / E | TERM / sd_Xxxu | - / e(481) |
+------------+-----------------------+-----------------+------------+
State transition table for allowed events coming from ifcU.
Cuda & Marocco Expires July 20, 2006 [Page 37]
Internet-Draft A Formal Model for Media Negotiation January 2006
+--------------+---------------------+-----------------+------------+
| | INIT | UPDATE_IN | UPDATE_OUT |
+--------------+---------------------+-----------------+------------+
| su_update_sd | UPDATE_IN / | - / uu_propose | - / e(488) |
| | uu_propose | | |
| | | | |
| su_2xxu_sd | TERM / uu_propose | TERM / | - / E |
| | | uu_propose | |
+--------------+---------------------+-----------------+------------+
State transition table for allowed events coming from ifcS.
Cuda & Marocco Expires July 20, 2006 [Page 38]
Internet-Draft A Formal Model for Media Negotiation January 2006
6. Open Issues
A number of issues are still to be closed. Some of them are
limitations introduced by the model: it is important to tell whether
they are acceptable or not. Others are just cases that are not
covered yet.
o There's a limited support for non-reliable provisional responses.
In particular the UA can't generate them (however, we are
interested only in negotiation events, so it should be ok);
o Offers (in opposite to answers) can only be sent through UPDATE,
INVITE requests and INVITE final responses;
o All the events are defined as negotiation events. Some of them
aren't ([vu]_accept), they must be found and fixed;
o Probably we need some mechanism to make sure that when a
negotiation scope has been closed, there are not outstanding
offers. For instance, now the sequence INVITE(SDP1) / 200(SDP2) /
ACK(SDP3) brings UAs to an inconsistent state;
o It is not possible to send two different provisional responses
simultaneously;
o Transition tables currently do not deal with reINVITEs and UPDATEs
yet;
o Error conditions should be classified better;
o When a composite action (X[du]_ev1, X[du]_ev2) is introduced, no
rollback/commit procedure has been detailed. Shall be added as
soon as the transition tables become stable enough;
o Some diagrams miss some arcs.
Cuda & Marocco Expires July 20, 2006 [Page 39]
Internet-Draft A Formal Model for Media Negotiation January 2006
7. Security Considerations
This memo does not raise security issues.
8. References
[I-D.sawada-sipping-sip-offeranswer]
Sawada, T. and P. Kyzivat, "Best Current Practice for SIP
(Session Initiation Protocol) Usage of Offer/Answer
Model", draft-sawada-sipping-sip-offeranswer-00 (work in
progress), October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
Cuda & Marocco Expires July 20, 2006 [Page 40]
Internet-Draft A Formal Model for Media Negotiation January 2006
Authors' Addresses
Alberto Cuda
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
Phone: +39 011 228 7026
Email: alberto.cuda@telecomitalia.it
Enrico Marocco
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
Phone: +39 011 228 5029
Email: enrico.marocco@telecomitalia.it
Cuda & Marocco Expires July 20, 2006 [Page 41]
Internet-Draft A Formal Model for Media Negotiation January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cuda & Marocco Expires July 20, 2006 [Page 42]
