and processes it as a UAS. It also acts as a UAC and generates
requests to determine how the incoming request is to be
answered. A B2BUA maintains complete dialog state and must
participate in all requests sent within the dialog.
4.2. IN Service Control Based on the SIN Approach
Figure 4 depicts the possibility of IN service control based on the
SIN approach. On both the originating and terminating ends, a SIN-
capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O
SIP" entity is required for outgoing calls that require support for
existing IN services. Likewise, on the callee’s side (or terminating
side), an equally configured entity ("T SIP") will be required to
provide terminating side services. Note that the "O SIP" and "T SIP"
entities correspond, respectively, to the IN O_BCSM and T_BCSM halves
of the IN call model.
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
O SIP: Originating SIP entity
T SIP: Terminating SIP entity
Figure 4. Overall SIN Architecture
5. Mapping of the SIP State Machine to the IN State Model
This section establishes the mapping of the SIP protocol state
machine to the IN generic basic call state model (BCSM) [2],
independent of any capability sets [8, 9]. The BCSM is divided into
two halves: an originating call model (O_BCSM) and a terminating call
model (T_BCSM). There are a total of 19 PICs and 35 DPs between both
the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for
T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call’s
progress in terms of the basic call model. The basic call model
provides a common context for communication about a call.
O_BCSM has 11 PICs:
O_NULL: Starting state; call does not exist yet.
AUTH_ORIG_ATTEMPT: Switch detects a call setup request.
COLLECT_INFO: Switch collects the dial string from the calling party.
ANALYZE_INFO: Complete dial string is translated into a routing
address.
SELECT_ROUTE: Physical route is selected, based on the routing
address.
AUTH_CALL_SETUP: Switch ensures the calling party is authorized to
place the call.
CALL_SENT: Control of call sent to terminating side.
O_ALERTING: Switch waits for the called party to answer.
O_ACTIVE: Connection established; communications ensue.
O_DISCONNECT: Connection torn down.
O_EXCEPTION: Switch detects an exceptional condition.
T_BCSM has 8 PICS:
T_NULL: Starting state; call does not exist yet.
AUTH_TERM_ATT: Switch verifies whether the call can be sent to
terminating party.
SELECT_FACILITY: Switch picks a terminating resource to send the call
on.
PRESENT_CALL: Call is being presented to the called party.
T_ALERTING: Switch alerts the called party, e.g., by ringing the
line.
T_ACTIVE: Connection established; communications ensue.
T_DISCONNECT: Connection torn down.
T_EXCEPTION: Switch detects an exceptional condition.
The state machine for O_BCSM and T_BCSM is provided in [1] on pages
98 and 103, respectively. This state machine will be used for
subsequent discussion when the IN call states are mapped into SIP.
The next two sections contain the mapping of the SIP protocol state
machine to the IN BCSMs. Explaining all PICs and DPs in an IN call
model is beyond the scope of this document. It is assumed that the
reader has some familiarity with the PICs and DPs of the IN call
model. More information can be found in [1]. For a quick reference,
Appendix A contains a mapping of the DPs to the SIP response codes as
discussed in the next two sections.
5.1. Mapping SIP Protocol State Machine to O_BCSM
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE
message) arrives from an upstream SIP client to an originating SIN-
enabled SIP entity running the IN call model. This entity will
create an O_BCSM object and initialize it in the O_NULL PIC. The
next seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO,
ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all
be mapped to the SIP "Calling" state.
Figure 5 provides a visual map from the SIP protocol state machine to
the originating half of the IN call model. Note that control of the
call shuttles between the SIP protocol machine and the IN O_BCSM call
model while it is being serviced.
SIP O_BCSM
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
Figure 5. Mapping from SIP to O_BCSM
The SIP "Calling" protocol state has enough functionality to absorb
the seven PICs as described below:
O_NULL: This PIC is basically a fall through state to the next
PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
AUTHORIZE_ORIGINATION_ATTEMPT: In this PIC, the IN layer has
detected that someone wishes to make a call. Under some
circumstances (e.g., if the user is not allowed to make calls
during certain hours), such a call cannot be placed. SIP can
authorize the calling party by using a set of policy directives
configured by the SIP administrator. If the called party is
authorized to place the call, the IN layer is instructed to enter
the next PIC, COLLECT_INFO through DP 3
(Origination_Attempt_Authorized). If for some reason the call
cannot be authorized, DP 2 (Origination_Denied) is processed, and
control transfers to the SIP state machine. The SIP state machine
must format and send a non-2xx final response (possibly 403) to
the upstream entity.
COLLECT_INFO: This PIC is responsible for collecting a dial string
from the calling party and verifying the format of the string. If
overlap dialing is being used, this PIC can invoke DP 4
(Collect_Timeout) and transfer control to the SIP state machine,
which will format and send a non-2xx final response (possibly a
484). If the dial string is valid, DP 5 (Collected_Info) is
processed, and the IN layer is instructed to enter the next PIC,
ANALYZE_INFO.
ANALYZE_INFO: This PIC is responsible for translating the dial
string to a routing number. Many IN services, such as freephone,
LNP (Local Number Portability), and OCS (Originating Call
Screening) occur during this PIC. The IN layer can use the R-URI
of the SIP INVITE request for analysis. If the analysis succeeds,
the IN layer is instructed to enter the next PIC, SELECT_ROUTE.
If the analysis fails, DP 6 (Invalid_Info) is processed, and the
control transfers to the SIP state machine, which will generate a
non-2xx final response (possibly 400, 401, 403, 404, 405, 406,
410, 414, 415, 416, 485, or 488) and send it to the upstream
entity.
SELECT_ROUTE: In the circuit-switched network, the actual physical
route has to be selected at this point. The SIP analogue would be
to determine the next hop SIP server. This could be chosen by a
variety of means. For instance, if the Request URI in the
incoming INVITE request is an E.164 number, the SIP entity can use
a protocol like TRIP [10] to find the best gateway to egress the
request onto the PSTN. If a successful route is selected, the IN
call model moves to PIC AUTH_CALL_SETUP via DP 9 (Route_Selected).
Otherwise, the control transfers to the SIP state machine via DP 8
(Route_Select_Failure), which will generate a non-2xx final
response (possibly 488) and send it to the upstream entity.
AUTH_CALL_SETUP: Certain service features restrict the type of
call that may originate on a given line or trunk. This PIC is the
point at which relevant restrictions are examined. If no such
restrictions are encountered, the IN call model moves to PIC
CALL_SENT via DP 11 (Origination_Authorized). If a restriction is
encountered that prohibits further processing of the call, DP 10
(Authorization_Failure) is processed, and control is transferred
to the SIP state machine, which will generate a non-2xx final
response (possibly 404, 488, or 502). Otherwise, DP 11
(Origination_Authorized) is processed, and the IN layer is
instructed to enter the next PIC, CALL_SENT.
CALL_SENT: At this point, the request needs to be sent to the
downstream entity. The IN layer waits for a signal confirming
either that the call has been presented to the called party or
that a called party cannot be reached for a particular reason.
The control is transferred to the SIP state machine. The SIP
state machine should now send the call to the next downstream
server determined in PIC SELECT_ROUTE. The IN call model now
blocks until unblocked by the SIP state machine.
If the above seven PICs have been successfully negotiated, the
SIN-enabled SIP entity now sends the SIP INVITE message to the
next hop server. Further processing now depends on the
provisional responses (if any) and the final response received by
the SIP protocol state machine. The core SIP specification does
not guarantee the delivery of 1xx responses; thus special
processing is needed at the IN layer to transition to the next PIC
(O_ALERTING) from the CALL_SENT PIC. The special processing
needed for responses while the SIP state machine is in the
"Proceeding" state and the IN layer is in the "CALL_SENT" state is
described next.
A 100 response received at the SIP state machine elicits no
special behavior in the IN layer.
A 180 response received at the SIP entity enables the
processing of DP 14 (O_Term_Seized), however, a state
transition to O_ALERTING is not undertaken yet. Instead, the
IN layer is instructed to remain in the CALL_SENT PIC until a
final response is received.
A 2xx response received at the SIP entity enables the
processing of DP 14 (O_Term_Seized), and the immediate
transition to the next state, O_ALERTING (processing in
O_ALERTING is described later).
A 3xx response received at the SIP entity enables the
processing of DP 12 (Route_Failure). The IN call model from
this point goes back to the SELECT_ROUTE PIC to select a new
route for the contacts in the 3xx final response (not shown in
Figure 5 for brevity).
A 486 (Busy Here) response received at the SIP entity enables
the processing of DP 13 (O_Called_Party_Busy) and resources for
the call are released at the IN call model.
If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or
6xx final response, DP 21 (O_Calling_Party_Disconnect &
O_Abandon) is processed and control passes to the SIP state
machine. Since a call was not successfully established, both
the IN layer and the SIP state machine can release resources
for the call.
O_ALERTING - This PIC will be entered as a result of receiving a
200-class response. Since a 200-class response to an INVITE
indicates acceptance, this PIC is mostly a fall through to the
next PIC, O_ACTIVE via DP 16 (O_Answer).
O_ACTIVE - At this point, the call is active. Once in this state,
the call may get disconnected only when one of the following three
events occur: (1) the network connection fails, (2) the called
party disconnects the call, or (3) the calling party disconnects
the call. If event (1) occurs, DP 17 (O_Connection_Failure) is
processed and call control is transferred to the SIP protocol
state machine. Since the network failed, there is not much sense
in attempting to send a BYE request; thus, both the SIP protocol
state machine and the IN call layer should release all resources
associated with the call and initialize themselves to the null
state. Event (2) results in the processing of DP 19
(O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event
(3) occurs if the calling party deliberately terminated the call.
In this case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) will
be processed, and control will be passed to the SIP protocol state
machine. The SIP protocol state machine must send a BYE request
and wait for a final response. The IN layer releases all of its
resources and initializes itself to the null state.
O_DISCONNECT: When the SIP entity receives a BYE request, the IN
layer is instructed to move to the last PIC, O_DISCONNECT via DP
19. A final response for the BYE is generated and transmitted by
the SIP entity, and the call resources are freed by both the SIP
protocol state machine and the IN layer.
5.2. Mapping SIP Protocol State Machine to T_BCSM
The T_BCSM object is created when a SIP INVITE message makes its way
to the terminating SIN-enabled SIP entity. This entity creates the
T_BCSM object and initializes it to the T_NULL PIC.
Figure 6 provides a visual map from the SIP protocol state machine to
the terminating half of the IN call model: