SIP T_BCSM
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
Figure 6. Mapping from SIP to T_BCSM
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: At this PIC, it is ascertained that
the called party wishes to receive the call 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 protocol state machine. The SIP protocol
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: In circuit switched networks, this PIC is
intended to select a line or trunk to reach the called party. As
lines or trunks are not applicable in an IP network, a SIN-enabled
SIP entity can use this PIC to interface with a PSTN gateway and
select a line/trunk to route the call. If the called party is
busy, or if a line/trunk cannot be seized, the processing of DP 25
(T_Called_Party_Busy) is invoked, and the call goes to the SIP
protocol state machine. The SIP protocol state machine must
format and send a non-2xx final response (possibly 486 or 600).
If a line/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 being presented (via the
ISUP ACM message, or Q.931 Alerting message, or simply by ringing
a POTS phone). If there was an error presenting the call, the
processing of DP 27 (Presentation_Failure) is invoked, and the
call control is transferred to the SIP protocol state machine,
which 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 being "alerted".
Control now passes momentarily to the SIP protocol state machine
so that it can generate and send a "180 Ringing" response to its
peer. Furthermore, since 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 protocol state machine, which 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.
After the above five PICs have been negotiated, the rest are mapped
as follows:
T_ACTIVE: The call is now active. Once this state is reached, the
call may become inactive 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
protocol state machine. Since the network failed, there is little
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 33
(T_Disconnect) and a transition to the next PIC, T_DISCONNECT.
Event (3) occurs at the receipt of a BYE request at the SIP
protocol state machine (not shown in Figure 6). Resources for the
call should be deallocated, and the SIP protocol state machine
must send a 200 OK for the BYE request (not shown in Figure 6).
T_DISCONNECT: In this PIC, the disconnect treatment associated
with the called party’s having disconnected the call is performed
at the IN layer. The SIP protocol state machine sends out a BYE
and awaits a final response for the BYE (not shown in Figure 6).
6. Examples of Call Flows
Two examples are provided here to show how SIP protocol state machine
and the IN call model work synchronously with each other.
In the first example, a SIP UAC originates a call request destined to
an 800 freephone number:
INVITE sip:18005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
The request makes its way to the originating SIP network server
running an IN call model. The SIP network server hands, at the very
least, the To: field and the From: field to the IN layer for
freephone number translation. The IN layer proceeds through its PICs
and at the ANALYSE_INFO PIC consults the SCP for freephone
translation. The translated number is returned to the SIP network
server, which forwards the message to the next hop SIP proxy, with
the freephone number replaced by the translated number:
INVITE sip:18475551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP ext-stn2.example.net
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
In the next example, a SIP UAC originates a call request destined to
a 900 number:
INVITE sip:19005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
The request makes its way to the originating SIP network server
running an IN call model. The SIP network server hands, at the very
least, the To: field and the From: field to the IN layer for 900
number translation. The IN layer proceeds through its PICs and at
the ANALYSE_INFO PIC consults the SCP for the translation. During
the translation, the SCP detects that the originating party is not
allowed to make 900 calls. It passes this information to the
originating SIP network server, which informs the SIP UAC by using a
SIP "403 Forbidden" response status code:
SIP/2.0 403 Forbidden
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com;tag=78K-909II
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
7. Security Considerations
Security considerations for SIN services cover both networks being
used, namely, the PSTN and the Internet. SIN uses the security
measures in place for both the networks. With reference to Figure 2,
the INAP messages between the SCP and the SIN-enabled SIP entity must
be secured by the signaling transport used between the SCP and the
SIN-enabled entity. Likewise, the requests coming into the SIN-
enabled SIP entity must first be authenticated and, if need be,
encrypted as well, using the means and procedures defined in [3] for
SIP requests.
8. References
8.1. Normative References
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to Services,"
McGraw-Hill, 1997.
[2] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
Distributed Functional Plane Architecture," International
Telecommunications Union Standardization Section, Geneva.
[3] 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.
8.2. Informative References
[4] ITU-T Q.1208: "General aspects of the Intelligent Network
Application protocol"
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[8] ITU-T Q.1218: "Interface Recommendation for Intelligent Network
Capability Set 1".
[9] ITU-T Q.1228: "Interface Recommendation for Intelligent Network
Capability Set 2".
[10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points
The mapping of error codes 4xx-6xx responses in SIP to the possible
Detection Points in PIC Originating and Terminating Call Handling is
indicated in the table below. The reason phrase in the 4xx-6xx
response is reproduced from [3].
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, 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 Type 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 21
Acknowledgments
Special acknowledgment is due to Hui-Lan Lu for acting as the chair
of the SIN DT and ensuring that the focus of the DT did not veer too
far. The authors would also like to give special thanks to Mr. Ray
C. Forbes from Marconi Communications Limited for his valuable
contribution on the system and network architectural aspects as co-
chair in the ETSI SPAN. Thanks also to Doris Lebovits, Kamlesh
Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev
Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all
contributed to the discussions on the relationship of IN and SIP call
models.
Author’s Addresses
Vijay K. Gurbani
Lucent Technologies, Inc.
2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566
USA
Phone: +1 630 224 0216
EMail: vkg@lucent.com
Frans Haerens
Alcatel Bell
Francis Welles Plein,1
Belgium
Phone: +32 3 240 9034
EMail: frans.haerens@alcatel.be
Vidhi Rastogi
Wipro Technologies
Plot No.72, Keonics Electronics City,
Hosur Main Road,
Bangalore 226 560 100
Phone: +91 80 51381869
EMail: vidhi.rastogi@wipro.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
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.
Intellectual Property
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 ISOC’s procedures with respect to rights in ISOC 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.