Applying the Mapping

To apply the mapping between the SIP state machine and Q.1204 BCSM, we followed the CMM/SS technique and algorithms listed in Section 5.3. The SIP state machine corresponds to the F domain and the Q.1204 BCSM corresponds to the L domain. The states of FM need to be mapped into L such that we satisfy Equation 5.4. Because F and L contain a different number of states — the Q.1204 PSTN/IN call model consists of 19 states and 35 transitions (11 states and 21 transitions in the originating BCSM, and 8 states and 14 transitions in the terminating one), and the SIP state machine of Figure 5.6 contains 6 states and 8 transitions — there will not be a one-to-one mapping between states.

We now present the mapping from SIP to O_BCSM and T_BCSM, respectively. In the mapping below, our reference to a particular SIP state is in relation to the states listed in Figure 5.6.

5.4.4.1 Mapping SIP to O_BCSM

To map the SIP state machine to O_BCSM, we followed the CMM/SS technique of aligning the two call models on the two yellow bulbs: Calling/Trying for SIP, and O_NULL for O_BCSM. We then established pivot states. For SIP, the set of pivot states consists of

Pivot = {Calling/Trying, Proceeding, Terminated, Ended} For O_BCSM, the set of pivot states consists of

Pivot = {O_NULL, O_Exception, Call_Sent, O_Active, O_Disconnect}

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 CMM/SS 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/Trying state.

Figure 5.9 provides a visual mapping from the SIP state machine to the originating half of the IN call model. Note that the service-state handoffs occur at appropriate times, resulting in control of the session setup shuttling between the SIP machine and the IN O_BCSM call model. The SIP Calling/Trying state has enough functionality to absorb the seven PICs as described below:

Figure 5.9 Mapping from SIP to O_BCSM.

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., the user is not allowed to make calls during certain hours), such a call cannot be placed. SIP has the ability to authorize the calling party 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 UAC.

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 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 (800 number), Local Number Portability (LNP), Originating Call Screening (OCS), etc., occur during this PIC. The IN layer can use the Request-Uniform Resource Identifier (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 control transfers to the SIP state machine, which will generate a non-2xx final response (possibly one of 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 analog of this would be to determine the next-hop SIP server. The next-hop SIP server could be chosen by a variety of means. For instance, if the R-URI in the incoming INVITE request is an E.164 number, the SIP entity can use a protocol like Telephony Routing over Internet Protocol (TRIP) [ROS02a\ 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 UAC.

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, and 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 now 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.

If the above seven PICs have been successfully negotiated, the CMM/SS 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 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 CMM/SS 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.9 for brevity). A 486 (Busy Here) response received at the CMM/SS 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 CMM/SS 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. Because 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. Because 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 occurs: (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 state machine. Because the network failed, there is not much sense in attempting to send a BYE request; thus, both the SIP state machine and the IN call layer should release all resources associated with the call and initialize themselves to the null state. The occurrence of event 2 results in the processing of DP 19 (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event 3 would be caused by the calling party proactively terminating the call. In this case, DP 21 (O_Abandon_&_O_Calling_Party_Disconnect) will be processed and control passed to the SIP state machine. The SIP state machine must send a BYE request and wait for a final response. The IN layer releases all its resources and initializes itself to the null state.

A salient point about PIC O_ACTIVE is that all mid-call SIP-related signaling arriving at the CMM/SS entity forces a servicestate handoff to this IN state. The IN BCSM can apply the appropriate mid-call service treatment to the session and execute a service-state handoff back to the IN layer.

O_DISCONNECT: When the SIP entity gets 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 CMM/SS entity, and the call resources are de-allocated by the SIP state machine as well as the IN layer.

5.4.4.2 Mapping SIP to T_BCSM

To map the SIP state machine to T_BCSM, we followed the CMM/SS technique of aligning the call models on the two yellow bulbs: "Proceeding" for SIP, and T_NULL for T_BCSM. As before, we then established pivot states. For SIP, the set of pivot states consists of

Pivot = {Proceeding, Terminated, Ended}

For O_BCSM, the set of pivot states consists of

Pivot = {T_NULL, T_Exception, T_Active, T_Disconnect}

The T_BCSM object is created when a SIP INVITE message makes its way to the terminating CMM/SS entity, which creates the T_BCSM object and initializes it to the T_NULL PIC. The mapping of 8 states and 14 transitions of the terminating half of the Q.1204 BCSM into an equivalent SIP state machine is reproduced in Figure 5.10.

The SIP "Proceeding" state has enough functionality to absorb the first five PICS — T_Null, Authorize_Termination_Attempt, Select_Facility, Present_Call, T_Alerting — as described below:

T_NULL: At this PIC, the terminating end creates the call at the IN layer. The incoming call results in the processing of DP 22, Termination_Attempt, and a transition to the next PIC, AUTHORIZE_TERMINATION_ATTEMPT, takes place. AUTHORIZE_TERMINATION_ATTEMPT: In this PIC, the fact that the called party wishes to receive the call is ascertained and that the facilities of the called party are compatible with those of the calling party. If any of these conditions is not met, DP 23 (Termination_Denied) is invoked and the call control is transferred to the SIP state machine. The SIP state machine can format and send a non-2xx final response (possibly 403, 405, 415, or 480). If the conditions of the PIC are met, processing of DP 24 (Termination_Authorized) is invoked and a transition to the next PIC, SELECT_FACILITY, takes place.

SELECT_FACILITY: The intent of this PIC in circuit-switched networks is to select a line or trunk to reach the called party. Because lines or trunks are not applicable in an IP network, a CMM/SS entity can use this PIC to interface with a PSTN gateway and select a line or trunk to route the call. If the called party is busy, or a line or trunk cannot be seized, the processing of DP 25 (T_Called_Party_Busy) is invoked, followed by a transition of the call to the SIP state machine. The SIP state machine must format and send a non-2xx final response (possibly 486 or 600). If a line or trunk was successfully seized, the processing of DP 26 (Terminating_Resource_Available) is invoked and a transition to the next PIC, PRESENT_CALL, takes place.

PRESENT_CALL: At this point, the call is presented (via an appropriate PSTN signaling protocol such as the ISDN User Part (ISUP) Association for Computing Machinery (ACM) message or Q.931 alerting message, or simply by ringing a PSTN phone). If there was an error presenting

Figure 5.10 Mapping from SIP to T_BCSM.

the call, the processing of DP 27 (Presentation_Failure) is invoked and the call control is transferred to the SIP state machine. The SIP state machine must format and send a non-2xx final response (possibly 480). If the call was successfully presented, the processing of DP 28 (T_Term_Seized) is invoked and a transition to the next PIC, T_ALERTING, takes place.

T_ALERTING: At this point, the called party is alerted. Control is now passed momentarily to the SIP state machine, so it can generate and send a "180 Ringing" response to its peer. Furthermore, because network resources have been allocated for the call, timers are set to prevent indefinite holding of such resources. The expiration of the relevant timers results in the processing of DP 29 (T_No_Answer) and the call control is transferred to the SIP state machine. The SIP state machine must format and send a non-2xx final response (possibly 408). If the called party answers, then DP 30 (T_Answer) is processed, followed by a transition to the next PIC, T_ACTIVE.

The rest of the PICs after the above five have been negotiated are mapped as follows:

T_ACTIVE: The call is now active. Once this state is reached, the call may become inactive only under one of the following three conditions: (1) the network fails the connection, (2) the called party disconnects the call, or (3) the calling party disconnects the call. Event 1 results in the processing of DP 31 (T_Connection_Failure) and call control is transferred to the SIP state machine. Because the network failed, there is not much sense in attempting to send a BYE request; thus, both the SIP 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 33 (T_Disconnect) and a transition to the next PIC, T_DISCONNECT. Event 3 would be caused by the receipt of a BYE request at the SIP state machine. Resources for the call should be de-allocated and the SIP state machine must send a 200 OK for the BYE request (not shown in Figure 5.10).

A salient point about T_ACTIVE PIC is the treatment of mid-call signaling. Once the session has been established, an IN service may perform mid-call signaling. If this happens, a service-state transfer occurs to the SIP "Terminated" state and a SIP method appropriate to the mid-call signaling is sent out. Upon receipt of a response, another service-state transfer will occur, putting the control back in the IN layer.

T_DISCONNECT: In this PIC, the disconnect treatment associated with the called party's having disconnected the call is performed at the IN layer. A service-state transfer occurs to the SIP "Terminated" state with enough information passed in sG to aid the SIP state machine in sending a BYE request out.

As part of the mapping of the SIP state machine to the two halves of Q.1204 BCSM, Figure 5.9 and Figure 5.10 indicate a relation between the

Table 5.1 Correlating SIP Response Codes with DPs

SIP Response Code

IN DP

200 OK

DP 14

3xx Redirection

DP 12

403 Forbidden

DP 2, DP 21, DP 23

484 Address Incomplete

DP 4, DP 21

400 Bad Request

DP 6, DP 21

401 Unauthorized

DP 6, DP 21

404 Not Found

DP 6, DP 10, DP 21

405 Method Not Allowed

DP 6, DP 21, DP 23

406 Not Acceptable

DP 6, DP 21

408 Request Timeout

DP 29

410 Gone

DP 6, DP 21

414 Request-URI Too Long

DP 6, DP 21

415 Unsupported Media Types

DP 6, DP 21, DP 23

416 Unsupported URI Scheme

DP 6, DP 21

480 Temporarily Unavailable

DP 23, DP 27

485 Ambiguous

DP 6, DP 21

486 Busy Here

DP 13, DP 21, DP 25

488 Not Acceptable Here

DP 6, DP 8, DP 10, DP 21

502 Bad Gateway

DP 10, DP 21

600 Busy Everywhere

DP 21, DP 25

DPs and SIP response codes. The processing of a certain DP may result in the SIP state machine sending out an appropriate SIP response. Table 5.1 contains a mapping of SIP responses (2xx to 6xx) to their appropriate DPs.

Our work in call model mapping between SIP and the two halves of Q.1204 BCSM outlined in Figure 5.9 and Figure 5.10 has been a subject of an Internet Engineering Task Force (IETF) Informational Request for Comment (RFC) document [GUR02]. The RFC series is the official publication channel for Internet standards documents and other publications of the Internet community [BRA96]. As of this writing, [GUR02] has been peer-reviewed by the SIP-related working groups in the IETF and is in the RFC editor's queue, waiting on an assignment of an RFC number for final publication.

0 0

Post a comment