3GPP TS 23.278 Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2; IM CN Interworking

3GPP TS 23.278 V9.0.0 (2009-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Customised Applications for Mobile network Enhanced Logic
(CAMEL) Phase 4; Stage 2;
IM CN Interworking
(Release 9)


	 EMBED Word.Picture.8  
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	 
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	 
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.


Keywords
LTE, UMTS, GSM, CAMEL, Stage 2, Network, interworking

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

©2009, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc217183619 \h 7
1	Scope	 PAGEREF _Toc217183620 \h 8
2	References	 PAGEREF _Toc217183621 \h 8
3	Definitions and abbreviations	 PAGEREF _Toc217183622 \h 9
3.1	Definitions	 PAGEREF _Toc217183623 \h 9
3.2	Abbreviations	 PAGEREF _Toc217183624 \h 9
4	CAMEL/IP Multimedia Core Network Interworking	 PAGEREF _Toc217183625 \h 10
4.1	Architecture	 PAGEREF _Toc217183626 \h 10
4.1.1	Functional Entities used for CAMEL at IP Multimedia Registration	 PAGEREF _Toc217183627 \h 10
4.1.2	Functional Entities used for CAMEL for MO and MT IP Multimedia session	 PAGEREF _Toc217183628 \h 11
4.2	Interfaces defined for an IM‑SSF based Application Server	 PAGEREF _Toc217183629 \h 11
4.2.1	CSCF – IM‑SSF interface	 PAGEREF _Toc217183630 \h 11
4.2.2	IM‑SSF - gsmSCF interface	 PAGEREF _Toc217183631 \h 11
4.2.3	HSS – IM-SSF interface	 PAGEREF _Toc217183632 \h 11
4.3	Detection Points (DPs)	 PAGEREF _Toc217183633 \h 11
4.3.1	Arming/Disarming mechanism	 PAGEREF _Toc217183634 \h 12
4.3.2	Criteria	 PAGEREF _Toc217183635 \h 12
4.3.2.1	Criteria at Collected_Info	 PAGEREF _Toc217183636 \h 13
4.3.2.2	Criteria at DP Analysed_Information	 PAGEREF _Toc217183637 \h 13
4.3.2.2.1	General	 PAGEREF _Toc217183638 \h 13
4.3.2.2.2	Number comparison	 PAGEREF _Toc217183639 \h 14
4.3.2.3	Criteria at DP Route_Select_Failure	 PAGEREF _Toc217183640 \h 14
4.3.2.4	Criteria at DP T_Busy and T_No_Answer	 PAGEREF _Toc217183641 \h 15
4.4	Description of CAMEL Subscriber Data	 PAGEREF _Toc217183642 \h 15
4.4.1	IP Multimedia CAMEL Subscription Information (IM‑CSI)	 PAGEREF _Toc217183643 \h 15
4.4.1.1	Originating IP Multimedia CAMEL Subscription Information (O‑IM‑CSI)	 PAGEREF _Toc217183644 \h 15
4.4.1.1.1	gsmSCF Address	 PAGEREF _Toc217183645 \h 15
4.4.1.1.2	Service Key	 PAGEREF _Toc217183646 \h 15
4.4.1.1.3	Default Call Handling	 PAGEREF _Toc217183647 \h 15
4.4.1.1.4	TDP List	 PAGEREF _Toc217183648 \h 15
4.4.1.1.5	CAMEL Capability Handling	 PAGEREF _Toc217183649 \h 15
4.4.1.1.6	CSI Status	 PAGEREF _Toc217183650 \h 15
4.4.1.1.7	Notification Flag	 PAGEREF _Toc217183651 \h 15
4.4.1.1.8	DP Criteria	 PAGEREF _Toc217183652 \h 16
4.4.1.2	Dialled Services IP Multimedia CAMEL Subscription Information (D‑IM‑CSI)	 PAGEREF _Toc217183653 \h 16
4.4.1.2.1	gsmSCF Address	 PAGEREF _Toc217183654 \h 16
4.4.1.2.2	Service Key	 PAGEREF _Toc217183655 \h 16
4.4.1.2.3	Default Call Handling	 PAGEREF _Toc217183656 \h 16
4.4.1.2.4	CAMEL Capability Handling	 PAGEREF _Toc217183657 \h 16
4.4.1.2.5	CSI Status	 PAGEREF _Toc217183658 \h 16
4.4.1.2.6	Notification Flag	 PAGEREF _Toc217183659 \h 16
4.4.1.2.7	DP Criteria	 PAGEREF _Toc217183660 \h 16
4.4.1.3	Terminating IP Multimedia CAMEL Subscription Information (VT‑IM‑CSI)	 PAGEREF _Toc217183661 \h 16
4.4.1.3.1	gsmSCF Address	 PAGEREF _Toc217183662 \h 16
4.4.1.3.2	Service Key	 PAGEREF _Toc217183663 \h 16
4.4.1.3.3	Default Call Handling	 PAGEREF _Toc217183664 \h 16
4.4.1.3.4	TDP List	 PAGEREF _Toc217183665 \h 16
4.4.1.3.5	CAMEL Capability Handling	 PAGEREF _Toc217183666 \h 17
4.4.1.3.6	CSI Status	 PAGEREF _Toc217183667 \h 17
4.4.1.3.7	Notification Flag	 PAGEREF _Toc217183668 \h 17
4.4.1.3.8	DP Criteria	 PAGEREF _Toc217183669 \h 17
4.4.1.4	Other CAMEL Data	 PAGEREF _Toc217183670 \h 17
4.4.1.4.1	gsmSCF address list for CSI	 PAGEREF _Toc217183671 \h 17
4.5	Description of CAMEL State Models	 PAGEREF _Toc217183672 \h 17
4.5.1	General Handling	 PAGEREF _Toc217183673 \h 17
4.5.2	Originating CAMEL Basic Call State Model (O‑IM‑BCSM)	 PAGEREF _Toc217183674 \h 18
4.5.2.1	Description of the O‑IM‑BCSM	 PAGEREF _Toc217183675 \h 18
4.5.2.2	Description of Points In Call	 PAGEREF _Toc217183676 \h 19
4.5.2.2.1	O_Null & Authorise_Origination_Attempt_Collect_Info	 PAGEREF _Toc217183677 \h 19
4.5.2.2.2	Analyse_Information	 PAGEREF _Toc217183678 \h 20
4.5.2.2.3	Routing and Alerting	 PAGEREF _Toc217183679 \h 20
4.5.2.2.4	O_Active	 PAGEREF _Toc217183680 \h 20
4.5.2.2.5	O_Exception	 PAGEREF _Toc217183681 \h 21
4.5.3	Mapping of SIP Method/Response to O‑IM-BCSM Detection Points	 PAGEREF _Toc217183682 \h 21
4.5.4	Terminating CAMEL Basic Call State Model (T‑IM‑BCSM)	 PAGEREF _Toc217183683 \h 22
4.5.4.1	Description of the T‑IM‑BCSM	 PAGEREF _Toc217183684 \h 22
4.5.4.2	Description of Points In Call	 PAGEREF _Toc217183685 \h 23
4.5.4.2.1	T_Null	 PAGEREF _Toc217183686 \h 23
4.5.4.2.2	Terminating Call Handling	 PAGEREF _Toc217183687 \h 23
4.5.4.2.3	T_Active	 PAGEREF _Toc217183688 \h 24
4.5.4.2.4	T_Exception	 PAGEREF _Toc217183689 \h 24
4.5.5	Mapping of SIP Method/Response to T‑IM‑BCSM Detection Points	 PAGEREF _Toc217183690 \h 25
4.6	Procedures for IM‑SSF Application Server	 PAGEREF _Toc217183691 \h 25
4.6.1	 Overall SDL Architecture	 PAGEREF _Toc217183692 \h 26
4.6.1.1	Handling of Registration and De-registration in the IM‑SSF	 PAGEREF _Toc217183693 \h 27
4.6.1.1.1	Procedure CAMEL_IMCN_Register	 PAGEREF _Toc217183694 \h 27
4.6.1.2	Handling of Notify Subscriber Data Change	 PAGEREF _Toc217183695 \h 30
4.6.1.3	Handling of Mobile Originated Calls in the IM‑SSF	 PAGEREF _Toc217183696 \h 33
4.6.1.3.1	Actions of the IM‑SSF on receipt of Int_Error	 PAGEREF _Toc217183697 \h 33
4.6.1.3.2	Actions of the IM‑SSF on receipt of Int_Continue	 PAGEREF _Toc217183698 \h 33
4.6.1.3.3	Actions of the IM‑SSF on receipt of Int_Continue_With_Argument	 PAGEREF _Toc217183699 \h 33
4.6.1.3.4	Actions of the IM‑SSF on receipt of Int_Connect	 PAGEREF _Toc217183700 \h 33
4.6.1.3.5	Actions of the IM‑SSF on receipt of Int_Release_Call	 PAGEREF _Toc217183701 \h 33
4.6.1.3.6	Handling of procedure CAMEL_OCH_CTR, sheet 1	 PAGEREF _Toc217183702 \h 33
4.6.1.3.7	Handling of procedure CAMEL_OCH_CTR, sheet 5	 PAGEREF _Toc217183703 \h 34
4.6.1.3.8	Receipt of 100 Trying Provisional Response (Process MO_IM_SSF)	 PAGEREF _Toc217183704 \h 34
4.6.1.3.9 Handling of internal timers in Process MO_IM_SSF	 PAGEREF _Toc217183705 \h 34
4.6.1.4	Handling of Mobile Terminated IP Multimedia sessions in the IM‑SSF	 PAGEREF _Toc217183706 \h 64
4.6.1.4.1	Actions of the IM‑SSF on receipt of Int_Error	 PAGEREF _Toc217183707 \h 64
4.6.1.4.2	Actions of the IM‑SSF on receipt of Int_Release_Call	 PAGEREF _Toc217183708 \h 64
4.6.1.4.3	Actions of the IM‑SSF on receipt of Int_Continue_With_Argument	 PAGEREF _Toc217183709 \h 64
4.6.1.4.4	Actions of IM‑SSF in procedure CAMEL_IMCN_MT_INVITE for Unregistered Subscriber	 PAGEREF _Toc217183710 \h 64
4.6.1.4.5	Handling of procedure CAMEL_MT_CTR, sheet 1	 PAGEREF _Toc217183711 \h 64
4.6.1.4.6	Handling of procedure CAMEL_MT_CTR, sheet 5	 PAGEREF _Toc217183712 \h 65
4.6.1.4.7	Receipt of 100 Trying Provisional Response (Process MT_IM_SSF)	 PAGEREF _Toc217183713 \h 65
4.6.1.4.8	Handling of internal timers in Process MT_IM_SSF	 PAGEREF _Toc217183714 \h 65
4.6.1.5	Handling of call in the imcnSSF	 PAGEREF _Toc217183715 \h 95
4.6.1.5.1	Process imcnSSF	 PAGEREF _Toc217183716 \h 95
4.6.1.6	Process imcn_SSME_SSF and procedures	 PAGEREF _Toc217183717 \h 126
4.7	Descriptions of information Flows	 PAGEREF _Toc217183718 \h 129
4.7.1	IM‑SSF to gsmSCF information flows	 PAGEREF _Toc217183719 \h 129
4.7.1.1	Activity Test ack	 PAGEREF _Toc217183720 \h 129
4.7.1.1.1	Description	 PAGEREF _Toc217183721 \h 129
4.7.1.1.2	Information Elements	 PAGEREF _Toc217183722 \h 129
4.7.1.2	Apply Charging Report	 PAGEREF _Toc217183723 \h 129
4.7.1.2.1	Description	 PAGEREF _Toc217183724 \h 129
4.7.1.2.2	Information Elements	 PAGEREF _Toc217183725 \h 129
4.7.1.3 	Call Gap	 PAGEREF _Toc217183726 \h 131
4.7.1.3.1	Description	 PAGEREF _Toc217183727 \h 131
4.7.1.3.2	Information Elements	 PAGEREF _Toc217183728 \h 131
4.7.1.4	Call Information Report	 PAGEREF _Toc217183729 \h 133
4.7.1.4.1	Description	 PAGEREF _Toc217183730 \h 133
4.7.1.4.2	Information Elements	 PAGEREF _Toc217183731 \h 133
4.7.1.5	Event Report BCSM	 PAGEREF _Toc217183732 \h 133
4.71.5.1	Description	 PAGEREF _Toc217183733 \h 133
4.7.1.5.2	Information Elements	 PAGEREF _Toc217183734 \h 133
4.7.1.6	Initial DP	 PAGEREF _Toc217183735 \h 134
4.7.1.6.1	Description	 PAGEREF _Toc217183736 \h 134
4.7.1.6.2	Information Elements	 PAGEREF _Toc217183737 \h 135
4.7.1.7	Specialized Resource Report	 PAGEREF _Toc217183738 \h 136
4.7.1.7.1	Description	 PAGEREF _Toc217183739 \h 136
4.7.1.7.2	Information Elements	 PAGEREF _Toc217183740 \h 136
4.7.2	gsmSCF to IM‑SSF information flows	 PAGEREF _Toc217183741 \h 137
4.7.2.1	Activity Test	 PAGEREF _Toc217183742 \h 137
4.7.2.1.1	Description	 PAGEREF _Toc217183743 \h 137
4.7.2.1.2	Information Elements	 PAGEREF _Toc217183744 \h 137
4.7.2.2	Apply Charging	 PAGEREF _Toc217183745 \h 137
4.7.2.2.1	Description	 PAGEREF _Toc217183746 \h 137
4.7.2.2.2	Information Elements	 PAGEREF _Toc217183747 \h 137
4.7.2.3	Call Information Request	 PAGEREF _Toc217183748 \h 138
4.7.2.3.1	Description	 PAGEREF _Toc217183749 \h 138
4.7.2.3.2	Information Elements	 PAGEREF _Toc217183750 \h 138
4.7.2.4	Cancel	 PAGEREF _Toc217183751 \h 138
4.7.2.4.1	Description	 PAGEREF _Toc217183752 \h 138
4.7.2.4.2	Information Elements	 PAGEREF _Toc217183753 \h 138
4.7.2.5	Connect	 PAGEREF _Toc217183754 \h 139
4.7.2.5.1	Description	 PAGEREF _Toc217183755 \h 139
4.7.2.5.2	Information Elements	 PAGEREF _Toc217183756 \h 139
4.7.2.6	Connect To Resource	 PAGEREF _Toc217183757 \h 139
4.7.2.6.1	Description	 PAGEREF _Toc217183758 \h 139
4.7.2.6.2	Information Elements	 PAGEREF _Toc217183759 \h 139
4.7.2.7	Continue	 PAGEREF _Toc217183760 \h 139
4.7.2.7.1	Description	 PAGEREF _Toc217183761 \h 139
4.7.2.7.2	Information Elements	 PAGEREF _Toc217183762 \h 139
4.7.2.8	Continue With Argument	 PAGEREF _Toc217183763 \h 140
4.7.2.8.1	Description	 PAGEREF _Toc217183764 \h 140
4.7.2.8.2	Information Elements	 PAGEREF _Toc217183765 \h 140
4.7.2.9	Disconnect Forward Connection	 PAGEREF _Toc217183766 \h 140
4.7.2.9.1	Description	 PAGEREF _Toc217183767 \h 140
4.7.2.9.2	Information Elements	 PAGEREF _Toc217183768 \h 140
4.7.2.10	Furnish Charging Information	 PAGEREF _Toc217183769 \h 140
4.7.2.10.1	Description	 PAGEREF _Toc217183770 \h 140
4.7.2.10.2	Information Elements	 PAGEREF _Toc217183771 \h 140
4.7.2.11	Release Call	 PAGEREF _Toc217183772 \h 141
4.7.2.11.1	Description	 PAGEREF _Toc217183773 \h 141
4.7.2.11.2	Information Elements	 PAGEREF _Toc217183774 \h 141
4.7.2.12	Request Report BCSM Event	 PAGEREF _Toc217183775 \h 141
4.7.2.12.1	Description	 PAGEREF _Toc217183776 \h 141
4.7.2.12.2	Information Elements	 PAGEREF _Toc217183777 \h 141
4.7.2.13	Reset Timer	 PAGEREF _Toc217183778 \h 142
4.7.2.13.1	Description	 PAGEREF _Toc217183779 \h 142
4.7.2.13.2	Information Elements	 PAGEREF _Toc217183780 \h 142
4.7.3	gsmSCF – IM‑SSF information flows for MRFC related operations	 PAGEREF _Toc217183781 \h 142
4.7.3.1	Cancel	 PAGEREF _Toc217183782 \h 142
4.7.3.1.1	Description	 PAGEREF _Toc217183783 \h 142
4.7.3.1.2	Information Elements	 PAGEREF _Toc217183784 \h 143
4.7.3.2	Play Announcement	 PAGEREF _Toc217183785 \h 143
4.7.3.2.1	Description	 PAGEREF _Toc217183786 \h 143
4.7.3.2.2	Information Elements	 PAGEREF _Toc217183787 \h 143
4.7.3.3	Prompt And Collect User Information (received information)	 PAGEREF _Toc217183788 \h 144
4.7.3.3.1	Description	 PAGEREF _Toc217183789 \h 144
4.7.3.3.2	Information Elements	 PAGEREF _Toc217183790 \h 144
4.7.3.4	Prompt And Collect User Information ack (received information)	 PAGEREF _Toc217183791 \h 145
4.7.3.4.1	Description	 PAGEREF _Toc217183792 \h 145
4.7.3.4.2	Information Elements	 PAGEREF _Toc217183793 \h 145
4.7.3.5	Specialized Resource Report	 PAGEREF _Toc217183794 \h 146
4.7.3.5.1	Description	 PAGEREF _Toc217183795 \h 146
4.7.3.5.2	Information Elements	 PAGEREF _Toc217183796 \h 146
4.7.4	IM‑SSF to HSS information flows	 PAGEREF _Toc217183797 \h 146
4.7.4.1	Any Time Subscription Interrogation request	 PAGEREF _Toc217183798 \h 146
4.7.4.1.1	Description	 PAGEREF _Toc217183799 \h 146
4.7.4.1.2	Information Elements	 PAGEREF _Toc217183800 \h 146
4.7.4.2	Notify Subscriber Data Change ack	 PAGEREF _Toc217183801 \h 146
4.7.4.2.1	Description	 PAGEREF _Toc217183802 \h 146
4.7.4.2.2	Information Elements	 PAGEREF _Toc217183803 \h 146
4.7.5	HSS to IM‑SSF information flows	 PAGEREF _Toc217183804 \h 146
4.7.5.1	Any Time Subscription Interrogation ack	 PAGEREF _Toc217183805 \h 146
4.7.5.1.1	Description	 PAGEREF _Toc217183806 \h 146
4.7.5.1.2	Information Elements	 PAGEREF _Toc217183807 \h 147
4.7.5.2	Notify Subscriber Data Change	 PAGEREF _Toc217183808 \h 147
4.7.5.2.1	Description	 PAGEREF _Toc217183809 \h 147
4.7.5.2.2	Information Elements	 PAGEREF _Toc217183810 \h 147
5	Control and interrogation of subscription data	 PAGEREF _Toc217183811 \h 148
5.1	Architecture	 PAGEREF _Toc217183812 \h 148
5.2	Procedures for CAMEL	 PAGEREF _Toc217183813 \h 148
5.2.1	Any Time Subscription Interrogation	 PAGEREF _Toc217183814 \h 148
5.2.2	Any Time Modification	 PAGEREF _Toc217183815 \h 148
5.2.3	Notify Subscriber Data Change	 PAGEREF _Toc217183816 \h 148
5.3	Description of information flows	 PAGEREF _Toc217183817 \h 148
5.3.1	gsmSCF to HSS information flows	 PAGEREF _Toc217183818 \h 149
5.3.1.1	Any Time Modification Request	 PAGEREF _Toc217183819 \h 149
5.3.1.1.1	Description	 PAGEREF _Toc217183820 \h 149
5.3.1.2	Any Time Subscription Interrogation Request	 PAGEREF _Toc217183821 \h 149
5.3.1.2.1	Description	 PAGEREF _Toc217183822 \h 149
5.3.1.2.2	Information Elements	 PAGEREF _Toc217183823 \h 149
5.3.1.3	Notify Subscriber Data Change response	 PAGEREF _Toc217183824 \h 149
5.3.1.3.1	Description	 PAGEREF _Toc217183825 \h 149
5.3.2	HSS to gsmSCF information flows	 PAGEREF _Toc217183826 \h 149
5.3.2.1	Any Time Modification ack	 PAGEREF _Toc217183827 \h 149
5.3.2.1.1	Description	 PAGEREF _Toc217183828 \h 149
5.3.2.1.2	Information Elements	 PAGEREF _Toc217183829 \h 149
5.3.2.2	Any Time Subscription Interrogation ack	 PAGEREF _Toc217183830 \h 150
5.3.2.2.1	Description	 PAGEREF _Toc217183831 \h 150
5.3.2.2.2	Information Elements	 PAGEREF _Toc217183832 \h 150
5.3.2.3	Notify Subscriber Data Change	 PAGEREF _Toc217183833 \h 150
5.3.2.3.1	Description	 PAGEREF _Toc217183834 \h 150
5.3.2.3.2	Information Elements	 PAGEREF _Toc217183835 \h 150
6	Subscriber Location and State retrieval	 PAGEREF _Toc217183836 \h 150
6.1	Architecture	 PAGEREF _Toc217183837 \h 150
6.2	Procedures for CAMEL	 PAGEREF _Toc217183838 \h 150
6.2.1	Any Time Interrogation	 PAGEREF _Toc217183839 \h 150
6.3	Description of information flows	 PAGEREF _Toc217183840 \h 151
6.3.1	gsmSCF to HSS information flows	 PAGEREF _Toc217183841 \h 151
6.3.1.1	Any Time Interrogation Request	 PAGEREF _Toc217183842 \h 151
6.3.1.1.1	Description	 PAGEREF _Toc217183843 \h 151
6.3.2	HSS to gsmSCF information flows	 PAGEREF _Toc217183844 \h 151
6.3.2.1	Any Time Interrogation ack	 PAGEREF _Toc217183845 \h 151
6.3.2.1.1	Description	 PAGEREF _Toc217183846 \h 151
Annex A (informative):	Change history	 PAGEREF _Toc217183847 \h 152

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The present document specifies the stage 2 description for the fourth phase (see 3GPP TS 22.078 [2]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature within the 3GPP system.
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
1	Scope
The present document specifies the stage 2 description for the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature which provides the mechanisms to support services for the IP Multimedia Core Network (IM CN) Subsystem.
2	References
The following documents contain provisions, which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]	3GPP TR 21.905: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications".
[2]	3GPP TS 22.078: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Customised Applications for Mobile network Enhanced Logic (CAMEL); Service description, Stage 1".
[3]	3GPP TS 22.228: "3rd Generation Partnership Project; Technical Specification Group Systems Aspects; IP Multimedia (IM) Subsystem –Stage 1".
[4]	3GPP TS 23.078: "3rd Generation Partnership Project; Technical Specification Group Core Networks; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 Stage 2 specification (Release 99)".
[5]	3GPP TS 23.218: "3rd Generation Partnership Project; Technical Specification Group Core Networks; IP Multimedia (IM) Session Handling; IP Multimedia Call Model.
[6]	3GPP TS 23.228: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) Stage 2".
[7]	Void
[8]	3GPP TS 24.229: "3rd Generation Partnership Project; Technical Specification Group Core Networks; IP Multimedia Call Control Protocol based o SIP and SDP; Stage 3".
[9]	3GPP TS 29.002: "3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification".
[10]	3GPP TS 29.229: "3rd Generation Partnership Project; Technical Specification Group Core Networks; Cx and Dx Interfaces Based on the Diameter Protocol; Protocol details".
[11]	3GPP TS 29.278: "3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4 CAMEL Application Part (CAP) specification for IP Multimedia Subsystems (IMS)".
 3	Definitions and abbreviations
3.1	Definitions
Home Subscriber Server (HSS):  Functional entity containing the subscription related information to support the network entities actually handling calls/sessions. For subscribers requiring CAMEL support, the HSS includes some functionality that was present in the HLR in previous 3GPP releases for storing the information relevant to the current subscription regarding CAMEL Subscription Information for IMS. The HSS sends IM CAMEL Subscription Information data to the IM‑SSF and CSE using a MAP interface.
IP Multimedia Service Switching Function (IM‑SSF): CAMEL functional entity that provides the interworking between SIP session control and the CAMEL state models. The IM‑SSF also provides the CAMEL interface to HSS for downloading the subscriber's CAMEL Subscription Information data for IMS.
IP Multimedia Basic Call State Model (IM‑BCSM): IM‑BCSM provides a high-level model of CSCF activities required to establish and maintain communication paths for users. As such, it identifies a set of basic call activities in a CSCF and shows how these activities are joined together to process a basic call.
IP Multimedia CAMEL Subscription Information (IM‑CSI): IM‑CSI identifies the subscriber as having IP Multimedia CAMEL services.
IP Multimedia session: IP Multimedia session and IP Multimedia call are treated as equivalent in this specification.
Originating IP Multimedia Basic Call State Model (O‑IM‑BCSM): originating half of the IM‑BCSM. The O‑IM‑BCSM corresponds to that portion of the IM‑BCSM associated with the originating party.
Originating IP Multimedia CAMEL Subscription Information (O‑IM‑CSI): O‑IM‑CSI identifies the subscriber as having originating IP Multimedia CAMEL services.
Terminating IP Multimedia Basic Call State Model (T‑IM‑BCSM): terminating half of the IM‑BCSM. The T‑IM‑BCSM corresponds to that portion of the IM‑BCSM associated with the terminating party.
Terminating IP Multimedia CAMEL Subscription Information (T‑IM‑CSI): T‑IM‑CSI identifies the subscriber as having terminating IP Multimedia CAMEL services.
3.2	Abbreviations
Abbreviations used in the present document are listed in 3GPP TR 21.905 [1].
For the purposes of the present document, the following abbreviations apply:
BCSM	Basic Call State Model
CAMEL	Customized Applications for Mobile network Enhanced Logic
CAP	CAMEL Application Part
CSCF	Call State Control Function
DP	Detection Point
D‑IM‑CSI	Dialled Service IP Multimedia CAMEL Subscription Information 
EDP	Event Detection Point
FTN	Forwarded To Number
GPRS	General Packet Radio Service
gsmSCF	GSM Service Control Function
gsmSRF	GSM Specialised Resource Function
gsmSSF	GSM Service Switching Function
HPLMN	Home PLMN
HSS	Home Subscriber Server
IE	Information Element
IF	Information Flow
IP	Internet Protocol
ISC	IM‑CN Service Control
I‑CSCF	Interrogating CSCF
IM	IP Multimedia
IM‑BCSM	IP Multimedia Basic Call State Model
IMCN	IP Multimedia Core Network
imcnSSF	IM CN Service Switching Function
IM‑CSI	IP Multimedia CAMEL Subscription Information 
IM‑SSF	IP Multimedia Service Switching Function 
IPLMN	Interrogating PLMN
MGCF	Media Gateway Control Function
MO	Mobile Originating
MT	Mobile Terminating
NNI	Network Node Interface
O‑IM‑BCSM	Originating IP Multimedia Basic Call State Model
O‑IM‑CSI	Originating IP Multimedia CAMEL Subscription Information
PIC	Point In Call
PLMN	Public Land Mobile Network
P‑CSCF	Proxy CSCF
SIP	Session Initiation Protocol
S‑CSCF	Serving CSCF
SSME	Service Switching Function Management Entity  
T‑IM‑BCSM	Terminating IP Multimedia Basic Call State Model
VT‑IM‑CSI	Terminating IP Multimedia CAMEL Subscription Information 
TDP	Trigger Detection Point
UNI	User Network Interface
VPLMN	Visited PLMN

4	CAMEL/IP Multimedia Core Network Interworking	
4.1	Architecture
This subclause describes the functional architecture needed to support CAMEL interactions with the S‑CSCF in the IP Multimedia Subsystem. The IM‑SSF is a SIP Application Server that interfaces SIP to CAP. The generic SIP Application Server behaviour of the IM‑SSF is specified in 3GPP TS 23.218 [5].
4.1.1	Functional Entities used for CAMEL at IP Multimedia Registration
Figure 4.1 shows the functional entities involved when an MS registers for IP Multimedia session requiring CAMEL support. General registration procedure is detailed in 3GPP TS 23.228 [6]. Upon notification of a UE's registration, the IM‑SSF requests O‑IM‑CSI, D‑IM‑CSI, VT‑IM‑CSI data from the HSS over the Si interface.

Figure 4.1: Functional architecture for support of CAMEL when mobile registers for IP Multimedia session
4.1.2	Functional Entities used for CAMEL for MO and MT IP Multimedia session
Figure 4.2 shows the functional entities involved in a Mobile Originated IP Multimedia session requiring CAMEL support. The same functional architecture applies in a Mobile Terminated IP Multimedia session for CAMEL.


Figure 4.2: Functional architecture for support of CAMEL control of a MO IP Multimedia session
4.2	Interfaces defined for an IM‑SSF based Application Server
4.2.1	CSCF – IM‑SSF interface
This interface is the IP Multimedia Service Control interface (ISC). This interface shall be based on SIP as detailed in 3GPP TS 24.229 [8].
4.2.2	IM‑SSF - gsmSCF interface
This interface is used by the gsmSCF to control an IP Multimedia  session in a certain IM‑SSF. Relationships between the IM‑SSF and the gsmSCF on this interface are opened as a result of the IM‑SSF sending a request for instructions to the gsmSCF.  This interface shall be based on 3GPP TS 29.278 [11].
4.2.3	HSS – IM-SSF interface
This interface is the Si interface and is used to send CAMEL related subscriber data to the IM-SSF, e.g. IM-CSI.  This interface shall be a MAP interface as described in 3GPP TS 29.002 [9].
4.3	Detection Points (DPs)
Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected.
A DP can be armed in order to notify the gsmSCF that the DP was encountered, and potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement.
Three different types of DPs are identified:
-	Trigger Detection Point - Request (TDP‑R).
	This detection point is statically armed and initiates a CAMEL control relationship when encountered and there is no existing relationship due to the same CSI. Processing is suspended when the DP is encountered.
-	Event Detection Point - Request (EDP‑R).
	This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is suspended when encountering the DP and the IM‑SSF waits for instructions from the gsmSCF.
-	Event Detection Point - Notification (EDP‑N).
	This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is not suspended when encountering the DP.
The DPs are characterized in the following clauses.
4.3.1	Arming/Disarming mechanism
A DP may be statically armed or dynamically armed.  
The following arming rules apply:
-	DP for a mobile originating call handling is statically armed in the IM‑SSF as a result of O‑IM‑CSI and D‑IM‑CSI data delivery from the HSS. Likewise, DP for mobile terminating call handling is statically armed in the IM‑SSF as a result of VT‑IM‑CSI data delivery from the HSS. Static arming of DPs in the IM‑SSF occurs during the UE's registration in the IMS CN. Basically, when the IM‑SSF is notified of the UE's initial registration, the IM‑SSF queries the HSS for the subscriber's CAMEL Subscription Information via the Si interface.
-	A DP is dynamically armed by the gsmSCF within the context of a CAMEL control relationship as a result of IM‑SSF receiving the RequestReportBCSMEvent operation. 
-	A Request Report BCSM Event information flow for a detection point for a leg overwrites any previous Request Report BCSM Event information flow for that detection point for that leg.

The following disarming rules apply:
-	A statically armed DP is disarmed when the IP Multimedia CSI data is withdrawn in the HSS. Only TDP‑Rs can be disarmed using this mechanism.
-	If an armed EDP is met, then it is disarmed.
-	If an EDP is met that causes the release of the related leg, then all EDPs related to that leg are disarmed.
-	If a call session is released, then all EDPs related to that call session are disarmed.
-	If an EDP is met, then other EDPS are disarmed, in accordance with the implicit disarming rule table specified in TS 23.078 Rel‑99 4 (refer to the section for "Rules for Implicit Disarming of Event Detection Points').
If an EDP is armed, it can be explicitly disarmed by the gsmSCF by means of the RequestReportBCSMEvent information flow.
4.3.2	Criteria
Criteria are the conditions that must be met in order for the IM‑SSF to request instructions from the gsmSCF. 
DP criteria are checked in the IM‑SSF. Criteria for originating DPs (i.e. Collected_Info, Analysed_Information, and Route_Select_Failure TDPs ) are checked in the IM‑SSF associated with the originating UE's S‑CSCF.  Criteria for terminating DPs (i.e. T_Busy and T_No_Answer) are checked in the IM‑SSF associated with the terminating UE's S‑CSCF.   
Based on the Initial Filter Criteria information, the S‑CSCF forwards the SIP message to the IM‑SSF.  The DP encountered is identified based on the SIP message received from the S‑CSCF. Refer to table 4.2 and table 4.4 for mapping of SIP messages to CAMEL IM‑BCSM Detection Points.
4.3.2.1	Criteria at Collected_Info
The following criteria are applicable for DP Collected_Info:
-	Destination number triggering criterion: The HSS may store a list of up to 10 destination numbers and/or up to 3 number lengths. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. This criterion may be defined to be either "enabling" or "inhibiting". This criterion does not match when the destination number received from the S-CSCF is not an ISDN number. In this case, a dialogue with the gsmSCF may or may not be established depending on whether the criterion is inhibiting or enabling respectively.
Triggering at DP Collected_Info shall be strictly based on the destination number received from the S‑CSCF.  
The destination number received from the S‑CSCF shall not be modified before conditional triggering check takes place.
If the destination number triggering criterion is enabling, then the IM‑SSF may establish a dialogue with the gsmSCF if:
-	the destination number matches one of the destination number strings defined in the list; or
-	the length of the destination number matches one of the destination number lengths defined in the list.
In this test the destination number matches one of the destination number strings in the list if:
-	the nature of address of destination number is the same as the nature of address of the destination number string;
-	the destination number is at least as long as the destination number string in the list; and
-	all the digits in the destination number string in the list match the leading digits of the destination number.
If the destination number triggering criterion is inhibiting, then the IM‑SSF may establish a dialogue with the gsmSCF if:
-	the destination number does not match any of the destination number strings defined in the list; and
-	the length of the destination number does not match any of the destination number lengths defined in the list.
In this test the destination number matches one of the destination number strings in the list if:
-	the nature of address of destination number is the same as the nature of address of the destination number string;
-	the destination number is at least as long as the destination number string in the list; and
-	all the digits in the destination number string in the list match the leading digits of the destination number.
4.3.2.2	Criteria at DP Analysed_Information
4.3.2.2.1	General
The following criteria are applicable for DP Analysed_Information:
Destination number triggering criterion: The HSS may store a list of up to 10 destination numbers. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. This criterion does not match when the destination number received from the S-CSCF or the gsmSCF is not an ISDN number.
NOTE: 	The order in which the destination number criteria are checked in the IM‑SSF is not determined. Hence, overlapping destination number criteria (e.g. use of "0800" and "0800123" for two different services) should be avoided, because they lead to unpredictable behaviour (i.e. either service might be triggered).
Triggering at DP Analysed_Info shall be based on the destination number received in the Connect operation from the gsmSCF during a Mobile Originating CAMEL Service.
4.3.2.2.2	Number comparison
The following procedure shall be performed for the comparison of the destination number triggering criterion and the address information in the given order.
1.	The numbering plan indicators of both numbers are ignored.
2.	The type of number/nature of address indicators of both numbers are compared. If there is a match of the type of number indicator, then the check shall be performed by comparing the digits as defined in step 6. If there is no match of the type of number the comparison procedure shall continue as follows.
3.	If either or both of the address information and destination number triggering criterion includes a type of number/nature of address indicator other than "unknown", "national (significant) number" or "international number" then the destination number does not match the destination number triggering criterion. Otherwise the comparison procedure shall continue as follows.
4.	If there is a number (address information or destination number triggering criterion) with type of number/nature of address "unknown" this number shall be translated based on the numbering plan of the serving entity in either of the following ways:
-	if the leading digits refer to an international prefix, those digits shall be removed and the type of number/nature of address shall be set to "international number".
-	if the leading digits refer to a national (trunk) prefix, those digits shall be removed and the type of number/nature of address shall be set to "national (significant) number".
If the leading digits refer neither to an international prefix nor to a national (trunk) prefix, then the destination number does not match the destination number triggering criterion.
If there is a match of the type of number/nature of address indicator after this number modification, then the check shall be performed by comparing the digits as defined in step 6, otherwise the comparison procedure shall continue as follows.
5.	If the type of number/nature of address of the address information or of the destination number triggering criterion is "national (significant) number" this number shall be translated based on the numbering plan of the serving entity to international format by adding the country code of the serving entity to the number string. After this modification both numbers shall be in international format and shall be checked by comparing the digits as defined in step 6.
6	If the number digits of the address information are compared with the number digits of the destination number triggering criterion, then there is a match if:
-	the destination number is at least as long as the destination number string of the destination number triggering criterion; and
-	all the digits in the destination number string of the destination number triggering criterion match the leading digits of the destination number.
The check described in this clause shall be repeated for every number contained in the destination number triggering criterion of the D‑IM‑CSI until a match is recognised and DP Analysed_Info is triggered, or until all the destination numbers have been checked without a match being recognised. In the latter case DP Analysed_Info is not triggered.
4.3.2.3	Criteria at DP Route_Select_Failure
The HSS may store a list of up to 5 cause values.
The following criteria are applicable for DP Route_Select_Failure:
-	Release cause code.
The trigger criteria is met if the cause code received from the terminating party's network (could be a PSTN or an IMS network) is equal to at least one of the cause codes in the trigger criteria list.  
If a O‑IM‑BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated.
4.3.2.4	Criteria at DP T_Busy and T_No_Answer
The HSS may store a list of up to 5 cause values.
The triggering is based on the release cause code received from terminating UE's P‑CSCF.
The following criteria are applicable for DP T_Busy and T_No_Answer:
-	Release cause code.
The trigger criteria are met if the cause code received from the terminating UE's P‑CSCF is equal to at least one of the cause codes in the trigger criteria list. 
If trigger criteria are satisfied, then the corresponding Service Logic shall be invoked.
4.4	Description of CAMEL Subscriber Data
4.4.1	IP Multimedia CAMEL Subscription Information (IM‑CSI)
This subclause defines the contents of the IP Multimedia CAMEL Subscription Information.  IM‑CSI data are provisioned in the HSS for subscribers having originating and/or terminating IP Multimedia CAMEL services. This information shall be sent by the HSS to the IM‑SSF via the Si Interface. The IM‑CSI data contains the O‑IM‑CSI, D‑IM‑CSI, and VT‑IM‑CSI.
4.4.1.1	Originating IP Multimedia CAMEL Subscription Information (O‑IM‑CSI)
4.4.1.1.1	gsmSCF Address
Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing.
4.4.1.1.2	Service Key
The Service Key identifies to the gsmSCF the service logic that shall apply. 
4.4.1.1.3	Default Call Handling
The Default Call Handling indicates whether the IP Multimedia session shall be released or continued as requested in case of error in the IM‑SSF to gsmSCF dialogue.
4.4.1.1.4	TDP List
The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DP Collected_Info and DP Route_Select_Failure.
4.4.1.1.5	CAMEL Capability Handling
CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service.  
4.4.1.1.6	CSI Status
The CSI state indicates whether the O‑IM‑CSI is active or not.
4.4.1.1.7	Notification Flag
The notification flag indicates whether changes of the O‑IM‑CSI shall trigger the Notification on Change of Subscriber Data. In order to update the IM‑SSF of IM CSI changes, this flag shall be set to yes.  
4.4.1.1.8	DP Criteria
The DP criteria indicate whether the IM‑SSF shall request the gsmSCF for instructions.
4.4.1.2	Dialled Services IP Multimedia CAMEL Subscription Information (D‑IM‑CSI)
4.4.1.2.1	gsmSCF Address
Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing.
4.4.1.2.2	Service Key
The Service Key identifies to the gsmSCF the service logic that shall apply.
4.4.1.2.3	Default Call Handling
The Default Call Handling indicates whether the IP Multimedia session shall be released or continued as requested in case of error in the IM‑SSF to gsmSCF dialogue.
4.4.1.2.4	CAMEL Capability Handling
CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service.  
4.4.1.2.5	CSI Status
The CSI state indicates whether the D‑IM‑CSI is active or not.
4.4.1.2.6	Notification Flag
The notification flag indicates whether changes of the D‑IM‑CSI shall trigger the Notification on Change of Subscriber Data. In order to update the IM‑SSF of IM CSI changes, this flag shall be set to yes.  
4.4.1.2.7	DP Criteria
The DP criteria indicate whether the IM‑SSF shall request the gsmSCF for instructions.
4.4.1.3	Terminating IP Multimedia CAMEL Subscription Information (VT‑IM‑CSI)
4.4.1.3.1	gsmSCF Address
Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing.
4.4.1.3.2	Service Key
The Service Key identifies to the gsmSCF the service logic that shall apply.
4.4.1.3.3	Default Call Handling
The Default Call Handling indicates whether the IP Multimedia session shall be released or continued as requested in case of error in the IM‑SSF to gsmSCF dialogue.
4.4.1.3.4	TDP List
The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are allowed: DP Terminating_Attempt_Authorised, DP T_Busy, and DP T_No_Answer.
4.4.1.3.5	CAMEL Capability Handling
CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service.  
4.4.1.3.6	CSI Status
The CSI state indicates whether the VT‑IM‑CSI is active or not.
4.4.1.3.7	Notification Flag
The notification flag indicates whether changes of the VT‑IM‑CSI shall trigger the Notification on Change of Subscriber Data. In order to update the IM‑SSF of IM CSI changes, this flag shall be set to yes.  
4.4.1.3.8	DP Criteria
The DP criteria indicate whether the IM‑SSF shall request the gsmSCF for instructions.
4.4.1.4	Other CAMEL Data
4.4.1.4.1	gsmSCF address list for CSI
The gsmSCF address list for CSI indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent.  In order to provide Notification on Change of Subscriber Data to the IM‑SSF, the IM‑SSF address shall be included in the gsmSCF address list.
The IM‑SSF address is added to the address list for notification in the HSS as described in subclause 4.6.1.2.  
The IM‑SSF shall handle the receipt of the Notification on Change of Subscriber Data using the same procedure as that of a gsmSCF.
4.5	Description of CAMEL State Models
In the IM Subsystem, calls are controlled by the Serving CSCF (S‑CSCF) where a subscriber is registered. A state model describes the call control behaviour of an IM‑SSF.
4.5.1	General Handling
The Basic Call State Model (BCSM) is used to describe the handling of originating and terminating calls. It identifies the points in a call where gsmSCF based service applications is permitted to interact with the call control capabilities of an IM‑SSF. Figure 4.3 illustrates how transitions between states, Detection Points and Points In Call components are shown in the BCSM diagrams.

Figure 4.3: BCSM Components
4.5.2	Originating CAMEL Basic Call State Model (O‑IM‑BCSM)
4.5.2.1	Description of the O‑IM‑BCSM
The O‑IM‑BCSM is used to model the behaviour of an IM‑SSF for an originating call. When an armed DP is encountered, O‑IM‑BCSM processing is suspended at the DP and the IM‑SSF indicates this to the gsmSCF if appropriate.


Figure 4.4: Originating CAMEL Basic Call State Model (O‑IM‑BCSM)
The following table 4.1defines the DPs that apply to originating calls.
Table 4.1: Description of the O‑IM‑BCSM DPs in an IM‑SSF
CAMEL Detection Point:
DP Type
Description:
DP Collected_Info
TDP‑R
Indication that the O‑IM‑CSI is analysed 
DP Analysed_Information
TDP‑R
Availability of routeing address and nature of address.
DP Route_Select_Failure
TDP‑R, EDP‑N, EDP‑R
Indication that the session establishment failed.
DP O_Busy
EDP‑N, EDP‑R
Indication that:
-	a busy indication is received from the terminating party,
- a not reachable event is determined upon a SIP error response.
DP O_No_Answer
EDP‑N, EDP‑R
Indication that:
-	an application timer associated with the O_No_Answer DP expires,
-	a no answer event is determined upon SIP a error response
DP O_Answer
EDP‑N, EDP‑R
Indication that the session is accepted and answered by the terminating party.
DP O_Disconnect
EDP‑N, EDP‑R
A disconnect indication is received from the originating party or from the terminating party.
DP O_Abandon
EDP‑N, EDP‑R
Indication that a disconnect indication is received from the originating party during the session establishment procedure.

4.5.2.2	Description of Points In Call
This subclause describes the Points In Call for originating calls. The entry events, actions and exit events are described for each Point in Call.
4.5.2.2.1	O_Null & Authorise_Origination_Attempt_Collect_Info
Entry events:
-	Disconnection and clearing of a previous call (DP O_Disconnect) or default handling of exceptions by IM‑SSF completed.
-	Abandon event is reported from Analyse_Information or Routing and Alerting PIC.
-	Exception event is reported.
Actions:
-	Interface is idled.
-	Originating call: SIP INVITE request message containing the dialled number is received from MS.
-	Information being analysed e.g., O‑IM‑CSI is analysed.
Exit events:
-	Originating CSI is analysed.
-	An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition: Calling party abandons call.
4.5.2.2.2	Analyse_Information
Entry events:
-	Originating CSI is analysed. (DP Collected Info).
-	New routeing information is received when Busy event (DP O_Busy), Route Select Failure event (DP Route_Select_Failure), Not Reachable event (DP O_Busy) or No Answer event (DP O_No_Answer) is reported from Routing and Alerting PIC.
-	New routeing information is received when Disconnect event is reported from O_Active PIC.
Actions:
-	Compare the called party number with the dialled services information.
Exit events:
-	Availability of routeing address and nature of address. (DP Analysed_Information).
-	An exception condition is encountered (e.g. wrong number)- this leads to the O_Exception PIC.
-	Calling party abandons the call- this leads to the O_Abandon DP.
4.5.2.2.3	Routing and Alerting
Entry events:
-	Availability of routeing address and nature of address. (DP Analysed_Information).
Actions:
-	Information is being analysed and/or translated according to dialling plan to determine routeing address.
-	Routeing address being interpreted.
-	Call is being processed by the terminating half BCSM. Continued processing of SIP call session setup (e.g., ringing) is taking place. Waiting for indication from terminating half BCSM that the call has been answered by terminating party.
Exit events:
-	Indication from the terminating half BCSM that the call is accepted and answered by terminating party (DP O_Answer).
-	An exception condition is encountered - this leads to the O_Exception PIC.
-	Calling party abandons the call- this leads to the O_Abandon DP.
-	A busy indication is received from the terminating party - this leads to the O_Busy DP.
-	A not reachable indication is received from the terminating party - this leads to the O_Busy DP.
-	Attempt to select the route for the call fails - this leads to the Route_Select_Failure DP.
If the no reply timer expires and DP O_No_Answer is armed - this leads to the O_No_Answer DP.
4.5.2.2.4	O_Active
Entry events:
-	Indication from the terminating half BCSM that the call is accepted and answered by the terminating party (DP O_Answer).
Actions:
-	SIP session established between originating party and terminating party. -	Call release is awaited.
Exit events:
-	A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM. (DP - O_Disconnect).
-	An exception condition is encountered.
4.5.2.2.5	O_Exception	
Entry events:
-	An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIC can not be met.
Actions:
-	Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as:
-	If any relationship exists between the IM‑SSF and the gsmSCF, the IM‑SSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion.
-	  Resources made available for setting up the SIP call session are released.
Exit events:
-	Default handling of the exception condition by IM‑SSF completed.
4.5.3	Mapping of SIP Method/Response to O‑IM-BCSM Detection Points
This subclause describes mapping of SIP methods and responses to CAMEL Detection Points.
Table 4.2: Mapping of SIP Method/Response to CAMEL O‑IM-BCSM DPs
CAMEL O‑IM‑BCSM DP:
SIP Method/Response
DP Collected_Info
INVITE
DP Analysed_Information
N/A
DP Route_Select_Failure
4XX (except 401, 407, 408, 480, 486),
5xx, and 6xx (except 600, 603)
DP O_Busy
486 Busy Here
600 Busy Everywhere
DP O_No_Answer
603 Decline
408 Request Timeout
480 Temp Unavailable
DP O_Answer
200 OK
DP O_Disconnect
BYE
DP O_Abandon
CANCEL

4.5.4	Terminating CAMEL Basic Call State Model (T‑IM‑BCSM)
4.5.4.1	Description of the T‑IM‑BCSM
The T‑IM-BCSM is used to model the behaviour of an IM‑SSF for a terminating call. When a DP is encountered, T‑IM-BCSM processing is suspended at the DP and IM‑SSF indicates this to the gsmSCF if appropriate.


Figure 4.5: Terminating CAMEL Basic Call State Model (T‑IM‑BCSM)
The following table 4.3defines the DPs that apply to terminating calls.
Table 4.3: Description of T‑IM‑BCSM DPs in the S‑CSCF
CAMEL DP:
DP Type
Description:
DP Terminating_Attempt_
_Authorised 
TDP‑R	
Indication that the VT‑IM‑CSI is analysed.
DP T_Busy
TDP‑R, EDP‑N, EDP‑R
Indication that:
-	a busy indication is received from the terminating party,
- a not reachable event is determined (e.g. terminating party is not currently registered).
DP T_No_Answer
TDP‑R, EDP‑N, EDP‑R
Indication that an application timer associated with the T_No_Answer DP expires.
DP T_Answer
EDP‑N, EDP‑R
Session is accepted and answered by terminating party.
DP T_Disconnect
EDP‑N, EDP‑R
A disconnect indication is received from the terminating party or from the originating party.
DP T_Abandon
EDP‑N, EDP‑R
A disconnect indication is received from the originating party during the session establishment procedure.

4.5.4.2	Description of Points In Call
This subclause describes the Points In Call for terminating calls. The entry events, actions and exit events are described for each Point in Call.
4.5.4.2.1	T_Null
Entry events:
-	Disconnection and clearing of a previous call (DP T_Disconnect) or default handling of exceptions by IM-SSF completed.
-	Abandon event is reported from Terminating Call Handling PIC.
-	Exception event is reported.
Actions:
-	Interface is idled.
-	SIP INVITE message for terminating call request is received, the appropriate information is analysed.
-	VT‑IM‑CSI is analysed.
Exit events:
-	Terminating CSI is  analysed.
-	An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP.
	Example exception condition is:
-	Calling party abandons call.
4.5.4.2.2	Terminating Call Handling
Entry events:
-	Terminating CSI (if available) is analysed. (DP Terminating_Attempt_Authorised).
-	New routeing information is received when Busy event (DP T_Busy) or No Answer event (DP T_No_Answer) is reported from Terminating Call Handling PIC.
-	New routeing information is received when Disconnect event is reported from T_Active PIC.
-	New routeing information is received when the terminating party not reachable is reported from Terminating Call Handling PIC.
Actions:
-	Routeing address and call type being interpreted. The next route or terminating access is being selected.
-	The terminating party is being alerted. Waiting for the call to be answered by terminating party.
Exit events:
-	Call is accepted and answered by terminating party.
-	An exception condition is encountered - this leads to the T_Exception PIC. Example exception conditions: the SIP call session request  was not successful.
-	Calling party abandons the call - this leads to the T_Abandon DP.
-	A busy indication is received from the terminating party's P‑CSCF - this leads to the T_Busy DP.
-	Not reachable event detected from the terminating party's P‑CSCF - this leads to the T_Busy DP.
-	If no reply timer expires and DP T_No_Answer is armed - this leads to the T_No_Answer DP.
4.5.4.2.3	T_Active
Entry events:
-	Indication that the call is accepted and answered by the terminating party. (DP T_Answer).
Actions:
-	SIP session established between originating party and terminating party. 
-	Call release is awaited.
Exit events:
A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM. (DP T_Disconnect).
An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC can not be met.
4.5.4.2.4	T_Exception
Entry events:
-	An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for PIC cannot be met.
Actions:
-	Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as:
-	If any relationship exists between the IM‑SSF and the gsmSCF, the IM‑SSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion.
-	Resources made available for setting up the SIP call session are released.
Exit events:
-	Default handling of the exception condition by IM‑SSF completed.
4.5.5	Mapping of SIP Method/Response to T‑IM‑BCSM Detection Points
This subclause describes mapping of SIP methods and responses to CAMEL Detection Points.
Table 4.4: Mapping of SIP Method/Response to CAMEL T‑IM‑BCSM DPs
CAMEL T‑IM‑BCSM DP:
SIP Method/Response
DP Terminating_Attempt_
_Authorised 
INVITE
DP T_Busy
4XX (except 401, 407, 408, 480),
5xx, and 6xx (except 603)
DP T_No_Answer
603 Decline
408 Request Timeout
480 Temp Unavailable
DP T_Answer
200 OK 
DP T_Disconnect
BYE
DP T_Abandon
CANCEL

4.6	Procedures for IM‑SSF Application Server
The SDLs in this specification illustrate how CAMEL modifies the normal multimedia call. They do not attempt to show all the details of multimedia handling in all the modes that support CAMEL.  
The text in this clause is a supplement to the definition in the SDL diagrams; it does not duplicate the information in the SDL diagrams.
4.6.1		Overall SDL Architecture


Figure 4.6: SIP Registration into IM‑SSF
 
Figure 4.7: Originating Case 

Figure 4.8: Terminating Case
4.6.1.1	Handling of Registration and De-registration in the IM‑SSF
During the UE registration, the HSS shall send the filter criteria for the IM‑SSF to the S‑CSCF if the subscriber is provisioned with IP Multimedia CAMEL Subscription Information data at the HSS. 
The HSS shall include the IMSI data for the subscriber within the Service Information element of the filter criteria for IM‑SSF. The IMSI shall be used for querying the HSS for CAMEL Subscription Information data via a MAP interface. 
The CAMEL service provider determines the actual format of the data sent within the Service Information element of the filter criteria (e.g. IMSI). The actual format is transparent to the S‑CSCF i.e. CAMEL service information is not processed, analysed, or evaluated by the S‑CSCF. It is, however, known to the IM‑SSF, gsmSCF, and the HSS (for provisioning of the service information data). 
If a registration/de-registration request matches the filter criteria of the IM‑SSF, the S‑CSCF informs the IM‑SSF of the request by performing a third party registration/de-registration i.e. a SIP REGISTER message is sent from the S‑CSCF to the IM‑SSF.
General handling of IP Multimedia registration, re-registration, de-registration and receipt of initial filter criteria at the S‑CSCF is specified in 3GPP TS 23.228 [6] and 23.218 [5].  
The process and the procedures specific to CAMEL are specified in this subclause:
	-		 Process Register_IM_SSF;
Procedure CAMEL_IMCN_Register;
Procedure CAMEL_IMCN_DeRegister.
4.6.1.1.1	Procedure CAMEL_IMCN_Register
When querying the HSS for the subscriber's IM CSI data, the IM‑SSF does not have to wait for the HSS's response on the first query before the subsequent queries are done. i.e Sending of multiple Any Time Interrogation operations can be done in parallel. However, the IM‑SSF shall wait for all the responses from the HSS before it shall send a SIP response message to the S‑CSCF.


Figure 4.9: Process Register_IM_SSF (sheet 1)

Figure 4.10: Procedure CAMEL_IMCN_Register (sheet 1)

Figure 4.11: Procedure CAMEL_IMCN_DeRegister (sheet 1)
4.6.1.2	Handling of Notify Subscriber Data Change 
When the HSS updates the CSI for a subscriber in the IP Multimedia CN subsystem, the HSS shall send a Notify Subscriber Data Change to the IM‑SSF if all of the following conditions are true:
The IM CSI data is marked with the Notification Flag
The IM‑SSF address is included in the gsmSCF address list 
The IM‑SSF address shall be added in the gsmSCF address list at the HSS for notification of IM‑CSI updates if one of the following conditions occurs:
The HSS is notified of the subscriber's registration at the S‑CSCF (via Cx interface), and the subscriber is provisioned with IM CSI data. 
Operator provisions HSS subscriber data with IMS CAMEL service while the subscriber is currently registered in the IMS network i.e. one or more IM CSI data is added to the subscriber's profile in the HSS.
The HSS is notified of mobile termination for an unregistered subscriber (via Cx interface), and the subscriber is provisioned with IM CSI data
The IM‑SSF address shall be deleted from the gsmSCF address list when the HSS initiates, or is notified of, the UE's deregistration. 
The IM‑SSF address in the gsmSCF address list may be changed when the HSS receives a notification of a registration for a UE with a S‑CSCF name different from the previously assigned S‑CSCF name (i.e. re-registration from HSS point of  view). The HSS shall overwrite the existing IM‑SSF address with the IM‑SSF address associated with the new S‑CSCF name. 
The HSS procedure for sending the Notify Subscriber Data Change to the IM‑SSF is the same procedure used for notifying the gsmSCFs in the Circuit Switched CN. This procedure is described in Procedure CAMEL_NSDC_HLR specified in 3GPP TS 23.078 Rel‑99[4].
The process specific to IM‑SSF's handling of the Notify Subscriber Data Change is specified in this subclause:
	-		  Process Update_CSI

Figure 4.12: Process Update_CSI (sheet 1)
4.6.1.3	Handling of Mobile Originated Calls in the IM‑SSF
The functional behaviour of the S‑CSCF is specified in 3GPP TS 23.218 [5]. The process and the procedures specific to CAMEL are specified in this subclause:
-	Process MO_IM_SSF;
-	Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT;
-	Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT;
-	Procedure CAMEL_IMCN_MO_CANCEL;
-	Procedure CAMEL_IMCN_MO_ANSWER;
-	Procedure CAMEL_IMCN_MO_UNSUCCESSFUL;
-	Procedure CAMEL_IMCN_MO_DISC1;
-	Procedure CAMEL_IMCN_MO_DISC2;
-	Procedure CAMEL_OCH_CTR.
Internal interface indicated with the "Int_SRF_" prefix within this subclause indicates internal interface with the MRFC.
4.6.1.3.1	Actions of the IM‑SSF on receipt of Int_Error
The IM‑SSF checks the default Call Handling parameter in the relevant CSI.
If the default call handling is release, a BYE indication is sent to the MS. The IM‑SSF then releases all resources and the invoked CAMEL procedure ends.
If the call handling is continue, the IM‑SSF continues processing without CAMEL support.
4.6.1.3.2	Actions of the IM‑SSF on receipt of Int_Continue
The IM‑SSF continues processing without any modification of call parameters.
4.6.1.3.3	Actions of the IM‑SSF on receipt of Int_Continue_With_Argument
The IM‑SSF continues processing with modified call parameters. The IM‑SSF shall modify the call parameters by the information received in the Int_Continue_With_Argument message. Call parameters that are not included in the Int_Continue_With_Argument_Message are unchanged.
4.6.1.3.4	Actions of the IM‑SSF on receipt of Int_Connect
The IM-SSF continues processing with modified call parameters. The IM‑SSF shall transparently modify the call parameters with the received information. Call parameters, which are not included in the Int_Connect message, are unchanged.
4.6.1.3.5	Actions of the IM‑SSF on receipt of Int_Release_Call
A BYE is sent to the MS, and a BYE is sent to the destination CSCF. The release cause received in the Int_Release_Call is used. The IM‑SSF then releases all call resources and all CAMEL processing ends.
4.6.1.3.6	Handling of procedure CAMEL_OCH_CTR, sheet 1
The IM‑SSF behaves as a B2BUA (Back‑2‑Back User Agent) when a SIP INVITE is received for an outgoing call and SIP INVITE is sent to the MRFC (via S‑CSCF) as a result of a CAP ConnectToResource request received from the SCF.
A SIP response 100 Trying is sent after each INVITE but is not shown in the SDLs. 
The IM‑SSF shall handle the 200 OK response from the MRFC as specified in 3GPP TS 23.218 [5].
4.6.1.3.7	Handling of procedure CAMEL_OCH_CTR, sheet 5
The specifics on transporting information between the MRFC and the Application Server such as the IM-SSF, has not been standardised in 3GPP Rel‑5 specifications for IMS. i.e. the SIP method to return the Prompt_and_Collect result from the MRFC to the IM‑SSF, the SIP method for sending notification of play announcement completion to the IM‑SSF when a request for a Specialised Resource Report was received, the SIP method  to request the MRFC to play announcement and the SIP method to request the MRFC to prompt and collect user information, are not standardised.
4.6.1.3.8	Receipt of 100 Trying Provisional Response (Process MO_IM_SSF) 
The IM-SSF (acting as B2BUA) uses the S-CSCF as the next-hop server when sending the SIP INVITE to the destination S-CSCF.  The 100 Trying provisional response received in the IM-SSF is actually generated and sent from the S-CSCF to indicate that the INVITE request has been received by the next-hop server (i.e. the S-CSCF) and is currently being processed.
4.6.1.3.9 Handling of internal timers in Process MO_IM_SSF
The SIP B timer defined in 3GPP TS 24.229 [8] is used for IM-SSF handling of no response condition for an INVITE request, similar to the Circuit Switched handling of TNRy Timer for No Reply. The use of B timer in the IM-SSF is indicated in the SDL Process MO_IM_SSF. There are other SIP timers defined in 3GPP TS 24.229 [8] that are not specified in the SDLs for IM-SSF processing. The usage of these timers is based on the network's implementation of the IM-SSF (e.g. choice of UDP or TCP for transport of SIP, and how IM-SSF operates as both a UAS and a UAC - i.e. back-to-back UA).
The following sub-clauses provide additional information on Process MO_IM_SSF's handling of the internal timers:
Sheets 1-2: The inclusion of Expires header field in the INVITE method is optional and is used to indicate the duration of the invitation in seconds. When the timer fires before a final response is generated by the IM-SSF, the INVITE message is considered to be "expired". The IM-SSF shall report a call abandon event to the gsmSCF if requested and return a 487 Request Terminated to the originating S-CSCF.
When the IM-SSF (taking the role of a UAC) sends out the INVITE request, the B timer (i.e. Tb timer) shall be used for the INVITE transaction timeout timer. Refer to 3GPP TS 24.229 [8] for the recommended B timer value.
Sheet 3:  When the IM-SSF (taking the role of a UAS) sends the 200 OK final response to the S-CSCF that sent the INVITE request, the IM-SSF shall start the Tack timer to monitor the receipt of the ACK request. Refer to 3GPP TS 24.229 [8] for the recommended ACK timer value.
Sheet 4: The expiration of Tb timer shall be reported as a no answer event to the gsmSCF if requested.  If the Tinvite timer expires, the IM-SSF shall report a call abandon event to the gsmSCF if requested.
Sheet 5: The expiration of the Tack shall be reported to the gsmSCF as a call disconnect from the originating party if requested.

Figure 4.13-1: Process MO_IM_SSF (sheet 1)

Figure 4.13-2: Process MO_IM_SSF (sheet 2)

Figure 4.13-3: Process MO_IM_SSF (sheet 3)

Figure 4.13-4: Process MO_IM_SSF (sheet 4)

Figure 4.13-5: Process MO_IM_SSF (sheet 5)

Figure 4.13-6: Process MO_IM_SSF (sheet 6)

Figure 4.14-1: Procedure CAMEL_IMCN_MO_ O_IM_CSI_INIT (sheet 1)

 Figure 4.14-2: Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT (sheet 2)

Figure 4.14-3: Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT (sheet 3)


Figure 4.15-1: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 1)

Figure 4.15-2: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 2)

Figure 4.15-3: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 3)

Figure 4.16: Procedure CAMEL_IMCN_MO_CANCEL (sheet 1)

Figure 4.17‑1: Procedure CAMEL_IMCN_MO_ANSWER (sheet 1)

Figure 4.17‑2: Procedure CAMEL_IMCN_MO_ANSWER (sheet 2)

Figure 4.18‑1: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 1)

Figure 4.18‑2: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 2)

Figure 4.18‑3: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 3)

Figure 4.18‑4: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 4)

Figure 4.18‑5: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 5)

Figure 4.18‑6: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 6)


Figure 4.19: Procedure CAMEL_IMCN_MO_DISC1 (sheet 1)

Figure 4.20‑1: Procedure CAMEL_IMCN_MO_DISC2 (sheet 1)

Figure 4.20‑2: Procedure CAMEL_IMCN_MO_DISC2 (sheet 2)

Figure 4.21-1: Procedure CAMEL_OCH_CTR (sheet 1)

Figure 4.21-2: Procedure CAMEL_OCH_CTR (sheet 2)

Figure 4.21-3: Procedure CAMEL_OCH_CTR (sheet 3)

Figure 4.21-4: Procedure CAMEL_OCH_CTR (sheet 4)

Figure 4.21-5: Procedure CAMEL_OCH_CTR (sheet 5)
4.6.1.4	Handling of Mobile Terminated IP Multimedia sessions in the IM‑SSF
The functional behaviour of the S‑CSCF for handling terminating calls is specified in 3GPP TS 23.218[5].The process and the procedures specific to CAMEL are specified in this subclause:
-	Process MT_IM_SSF;
-	Procedure Check_Registration;
-	Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT;
-	Procedure CAMEL_IMCN_MT_RECONNECT;
-	Procedure CAMEL_IMCN_MT_CANCEL;
-	Procedure CAMEL_IMCN_MT_ANSWER;
-	Procedure CAMEL_IMCN_MT_UNSUCCESSFUL;
-	Procedure CAMEL_IMCN_MT_DISC1;
-	Procedure CAMEL_IMCN_MT_DISC2;
-	Procedure CAMEL_CAMEL_MT_CTR.
Internal interface indicated with the "Int_SRF_" prefix within this subclause indicates internal interface with the MRFC.
4.6.1.4.1	Actions of the IM‑SSF on receipt of Int_Error 
The IM‑SSF checks the default Call Handling parameter in the relevant CSI.
If the default call handling is release, a BYE indication is sent to the originating CSCF. The IM‑SSF then releases all resources and the invoked CAMEL procedure ends.
If the call handling is continue, the IM‑SSF continues processing without CAMEL support.
4.6.1.4.2	Actions of the IM‑SSF on receipt of Int_Release_Call 
The IM‑SSF BYE message is sent to the originating CSCF and resources are released.
4.6.1.4.3	Actions of the IM‑SSF on receipt of Int_Continue_With_Argument
The IM‑SSF shall replace the call parameters by the information received in the Int_Continue_With_Argument message. Call parameters that are not included in the Int_Continue_With_Argument_Message are unchanged.
4.6.1.4.4	Actions of IM‑SSF in procedure CAMEL_IMCN_MT_INVITE for Unregistered Subscriber 
When querying the HSS for the subscriber's IM CSI data, the IM‑SSF does not have to wait for the HSS's response on the first query before the subsequent queries are done. i.e. Sending of multiple Any Time Interrogation operations can be done in parallel. However, the IM‑SSF shall wait for all the responses from the HSS before it shall continue with the handling of the terminating IP multimedia session. 
4.6.1.4.5	Handling of procedure CAMEL_MT_CTR, sheet 1
The IM‑SSF behaves as a B2BUA (Back‑2‑Back User Agent) when a SIP INVITE is received for an terminating call and SIP INVITE is sent to the MRFC (via S‑CSCF)  as a result of a CAP ConnectToResource request received from the SCF.
A SIP response 100 Trying is sent after each INVITE but is not shown in the SDLs. 
The IM‑SSF shall handle the 200 OK response from the MRFC as specified in 3GPP TS 23.218 [5].
4.6.1.4.6	Handling of procedure CAMEL_MT_CTR, sheet 5
The specifics on transporting information between the MRFC and the Application Server such as the IM‑SSF, has not been standardised in 3GPP Rel‑5 specifications for IMS. i.e. the SIP method to return Prompt_And_Collect result from the MRFC to the IM‑SSF, the SIP method for sending notification of play announcement completion to the IM‑SSF when a request for a Specialised Resource Report was received, the SIP method  to request the MRFC to play announcement and the SIP method to request the MRFC to prompt and collect user information, are not standardised.
4.6.1.4.7	Receipt of 100 Trying Provisional Response (Process MT_IM_SSF)
The IM-SSF (acting as a B2BUA) uses the S-CSCF as a next-hop server when sending the SIP INVITE to the terminating subscriber.  The 100 Trying provisional response received in the IM-SSF is actually generated and sent from the S-CSCF to indicate that the INVITE request has been received by the next-hop server (i.e. the S-CSCF) and is currently being processed.
4.6.1.4.8	Handling of internal timers in Process MT_IM_SSF
For additional description on usage of internal timers in Process MT_IM_SSF, please refer to the description in clause 4.6.1.3.9.

Figure 4.22-1: Process MT_IM_SSF (sheet 1)

Figure 4.22-2: Process MT_IM_SSF (sheet 2)

Figure 4.22-3: Process MT_IM_SSF (sheet 3)

Figure 4.22-4: Process MT_IM_SSF (sheet 4)

Figure 4.22-5: Process MT_IM_SSF (sheet 5)

Figure 4.22-6: Process MT_IM_SSF (sheet 6)

Figure 4.23: Procedure Check_Registration (sheet 1)

Figure 4.24-1: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 1)

Figure 4.24-2: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 2)

Figure 4.24-3: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 3)

Figure 4.25: Procedure CAMEL_IMCN_MT_RECONNECT (sheet 1)


Figure 4.26: Procedure CAMEL_IMCN_MT_CANCEL (sheet 1) 

Figure 4.27-1: Procedure CAMEL_IMCN_MT_ANSWER (sheet 1)

Figure 4.27-2: Procedure CAMEL_IMCN_MT_ANSWER (sheet 2) 

Figure 4.28-1: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 1)

Figure 4.28-2: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 2)

Figure 4.28-3: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 3)

Figure 4.28-4: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 4)

Figure 4.28-5: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 5)


Figure 4.29: Procedure CAMEL_IMCN_MT_DISC1 (sheet 1)

Figure 4.30-1: Procedure CAMEL_IMCN_MT_DISC2 (sheet 1)

Figure 4.30-2: Procedure CAMEL_IMCN_MT_DISC2 (sheet 2)

Figure 4.31: Procedure CAMEL_Start_TNRy (sheet 1)

Figure 4.32: Procedure CAMEL_Stop_TNRy (sheet 1)

Figure 4.33-1: Procedure CAMEL_MT_CTR (sheet 1)

Figure 4.33-2: Procedure CAMEL_MT_CTR (sheet 2)

Figure 4.33-3: Procedure CAMEL_MT_CTR (sheet 3)

Figure 4.33-4: Procedure CAMEL_MT_CTR (sheet 4)

Figure 4.33-5: Procedure CAMEL_MT_CTR (sheet 5)

4.6.1.5	Handling of call in the imcnSSF
Handling of mobile calls in the imcnSSF may involve the following process and procedures:
-	Process imcnSSF;
Note that the following procedures are specified in 3GPP TS 23.078 Rel-99 [4]. For these procedures, the imcnSSF shall take the role of the gsmSSF.
-	Procedure Check_Criteria_Collected_Info;
-	Procedure Check_Criteria_Analysed_Info;
-	Procedure Check_Criteria_Unsuccessful;
-	Procedure Connect_To_Resource;
-	Procedure Handle_AC;
-	Procedure Handle_ACR;
-	Procedure Handle_CIR;
-	Procedure Handle_CIR_leg;
-	Procedure Complete_FCI_record;
-	Procedure Complete_all_FCI_records;
-	Procedure Handle_O_Answer;
-	Procedure Handle_T_Answer.
The detailed error handling for the process imcnSSF and the associated procedures is specified in 3GPP TS 29.278 [11].
4.6.1.5.1	Process imcnSSF


Figure 4.34-1: Process imcnSSF (sheet 1)

Figure 4.34-2: Process imcnSSF (sheet 2)

Figure 4.34-3: Process imcnSSF (sheet 3)

Figure 4.34-4: Process imcnSSF (sheet 4)

Figure 4.34-5: Process imcnSSF (sheet 5)

Figure 4.34-6: Process imcnSSF (sheet 6)

Figure 4.34-7: Process imcnSSF (sheet 7)

Figure 4.34-8: Process imcnSSF (sheet 8)

Figure 4.34-9: Process imcnSSF (sheet 9)

Figure 4.34-10: Process imcnSSF (sheet 10)

Figure 4.34-11: Process imcnSSF (sheet 11)

Figure 4.34-12: Process imcnSSF (sheet 12)

Figure 4.34-13: Process imcnSSF (sheet 13)

Figure 4.34-14: Process imcnSSF (sheet 14)

Figure 4.34-15: Process imcnSSF (sheet 15)

Figure 4.34-16: Process imcnSSF (sheet 16)

Figure 4.34-17: Process imcnSSF (sheet 17)

Figure 4.34-18: Process imcnSSF (sheet 18)

Figure 4.34-19: Process imcnSSF (sheet 19)

Figure 4.34-20: Process imcnSSF (sheet 20)

Figure 4.34-21: Process imcnSSF (sheet 21)

Figure 4.34-22: Process imcnSSF (sheet 22)

Figure 4.34-23: Process imcnSSF (sheet 23)

Figure 4.34-24: Process imcnSSF (sheet 24)

Figure 4.34-25: Process imcnSSF (sheet 25)

Figure 4.34-26: Process imcnSSF (sheet 26)

Figure 4.34-27: Process imcnSSF (sheet 27)

Figure 4.34-28: Process imcnSSF (sheet 28)

Figure 4.34-29: Process imcnSSF (sheet 29)

Figure 4.34-30: Process imcnSSF (sheet 30)
4.6.1.6	Process imcn_SSME_SSF and procedures
One process is instantiated at the IM-SSF for each Call Gap message received from a gsmSCF. 
This subclause contains the SDL process for IM‑SSF handling of the CallGap operation received from a gsmSCF. 
The following Call Gap procedures specified in 3GPP TS 23.078 Rel‑99 [4] shall also be applicable for IM‑SSF. The IM‑SSF shall take the role of the gsmSSF in the following:
Procedure Store_Call_Gap_Criteria;
Procedure Check_Gap_Criteria.

Figure 4.35-1: Process imcn_SSME_SSF (sheet 1)


Figure 4.35-2: Process imcn_SSME_SSF (sheet 2)
4.7	Descriptions of information Flows
This clause contains the detailed description of the information flows used by CAMEL for IP Multimedia Subsystems call control.
Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different traffic case: IP Multimedia Origination (IM_Orig), IP Multimedia Termination (IM_Term). The distinction between IM_Orig and IM_Term calls is not applicable to all Information Flows.
An 'M' IE shall always be included for the corresponding traffic case. A 'C' IE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an  'S' IE are shown in the 'Description' column of the definition table. When a set of  'E' IEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O' IE may be included or omitted as required by the service logic. A '‑' IE shall always be omitted for the corresponding traffic case. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. 
Details of errors and exceptions to these rules are specified in 3GPP TS 29.278 [11].
4.7.1	IM‑SSF to gsmSCF information flows
4.7.1.1	Activity Test ack
4.7.1.1.1	Description
This IF is the response to the Activity Test.
4.7.1.1.2	Information Elements
This IF contains no information elements.
4.7.1.2	Apply Charging Report
4.7.1.2.1	Description
This IF is used by the IM‑SSF to report to the gsmSCF the information requested in the Apply Charging IF.
4.7.1.2.2	Information Elements
Information element name
Status
Description
Call Result
M
This IE contains the charging information to be provided by the IM‑SSF.

Call Result contains the following information:
Information element name
Status
Description
Time Duration Charging Result
M
This IE is a list defined in the next table.

Time Duration Charging Result contains the following information:
Information element name
Status
Description
Time Information
M
This IE is a choice between Time if No Tariff Switch and Time if Tariff Switch. This IE is described in the next table. 
Party To Charge
M
This IE is received in the related ApplyCharging operation to correlate the result to the request. This IE shall be a copy of the corresponding IE received in the Apply Charging operation.
Call Active
M
This IE indicates whether the call is active or not.
Call Released at Tcp Expiry
C
This element is an indication that the IM‑SSF has released the call and terminated the dialogue, due to Tcp expiry.
It shall be present when ACR is sent due to Tcp expiry and the IM‑SSF has released the call (because "ReleaseIfExceeded" was present in ACH operation).
In all other circumstances, this element shall be absent.

Time Information contains one of the following information:
Information element name
Status
Description
Time If No Tariff Switch
C
This IE will be present if no tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party or the MRFC connection, otherwise it will be absent. 
If Answer was detected for the connection to the Called Party or the MRFC connection, then the elapsed time since detection of Answer shall be reported.
If answer was not detected, it shall be set to "0". 
Time If Tariff Switch
C
This IE will be present if a tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party or the MRFC connection, otherwise it will be absent.

4.7.1.3 	Call Gap
4.7.1.3.1	Description
This IF is used to activate/modify/remove a call gap mechanism in the IM‑SSF. The call gap mechanism is used to reduce the rate at which specific service requests are sent to a gsmSCF.
A Call Gap operation can only be sent on an opened dialogue between a gsmSCF and the IM‑SSF.
It is possible to have several call gapping conditions applicable to the same IM‑SSF (i.e. each conditions were activated for a defined Service (identified by the serviceKey) by a defined gsmSCF (identified by the gsmSCFAddress).
4.7.1.3.2	Information Elements 
Information element name
Status
Description
Gap Criteria
M
This IE specifies the criteria for a call to be subject to call gapping.
Gap Indicators
M
This parameter indicates the gapping characteristics.
Control Type
O
This parameter indicates the reason for activating call gapping.
The value "sCPOverloaded" indicates that an automatic congestion detection and control mechanism in the SCP has detected a congestion situation.
The value "manuallyInitiated" indicates that the service and or network/service management centre has detected a congestion situation, or any other situation that requires manually initiated controls.
The controlType "manuallyInitiated" will have priority over "sCPOverloaded" call gap.
Gap Treatment
O
This parameter indicates how calls that were rejected due to the call gapping condition and for which the Default Call Handling was set to "Release Call" shall be treated.
M	Mandatory (The IE shall always be sent).
O	Optional (Service logic dependent).

Gap Criteria contains one of the following (Choice):
Information element name
Status
Description
Basic Gap Criteria
O
This IE is a choice of various basic criteria.
Compound Gap Criteria
O
This IE is a choice of various criteria including an ScfID.
O	Optional (Service logic dependent).

Compound Gap Criteria contains the following Information:
Information element name
Status
Description
Basic Gap Criteria
M
This IE is a choice of various criteria.
ScfID
O
This IE contains the address of the gsmSCF which initiated the CallGapping.
M	Mandatory (The IE shall always be sent).
O	Optional (Service logic dependent).

Basic Gap Criteria contains one of the following (Choice):
Information element name
Status
Description
Called Address
O
This parameter contains a string of digits. At each call attempt, when the leading digits of the dialled number match this specific value, the call gapping treatment shall be applied to this call.
Service
O
This parameter contains a service key value. At each call attempt, when the service key matches this specific value, the call gapping treatment shall be applied to this call.
Called Address and Service
O
This parameter contains a specific string of digits and a service key value. At each call attempt, when the leading digits of the dialled number and the service key of a call match these specific values, the call gapping treatment shall be applied to this call.
Calling Address and Service
O
This parameter contains a specific string of digits and a service key value. At each call attempt, when the leading digits of the calling party number and the service key match these specific values, the call gapping treatment shall be applied to this call.
O	Optional (Service logic dependent).

Gap Indicators contains the following information:
Information element name
Status
Description
Duration
M
Duration specifies the total time interval during which call gapping for the specified gap criteria will be active. 
A duration of 0 indicates that gapping is to be removed. 
 A duration of -2 indicates a network specific duration.
Other values indicate duration in seconds.
Interval
M
This parameter specifies the minimum time between calls being allowed through.
An interval of 0 indicates that calls meeting the gap criteria are not to be rejected.
An interval of -1 indicates that all calls meeting the gap criteria are to be rejected.
Other values indicate interval in milliseconds.
M	Mandatory (The IE shall always be sent).

Gap Treatment contains one of the following (choice):
Information element name
Status
Description
Information To Send
O
This parameter indicates an announcement or a tone to be sent to the calling party. At the end of information sending, the call shall be released.
Release Cause
O
If the call is to be released, this IE indicates a specific cause value to be sent in the release message. See ETSI EN 300 356-1 [20] for the coding.
O	Optional (Service logic dependent).

Information To Send contains one of the following (choice):
Information element name
Status
Description
In-band Info
O
This parameter specifies the in-band information to be sent.
Tone
O
This parameter specifies a tone to be sent to the end‑user.
O	Optional (Service logic dependent).

In-band Info contains the following information:
Information element name
Status
Description
Message Id
M
This parameter indicates the message(s) to be sent, it can be one of the following.
Message Duration
O
This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. ZERO indicates endless repetition.
M	Mandatory (The IE shall always be sent).
O	Optional (Service logic dependent).

Message Id contains one of the following (choice):
Information element name
Status
Description
Elementary Message Id
O
This parameter indicates a single announcement.
O	Optional (Service logic dependent).

4.7.1.4	Call Information Report
4.7.1.4.1	Description
This IF is used to send specific call information for a single call to the gsmSCF as requested from the gsmSCF in a previous Call Information Request.
4.7.1.4.2	Information Elements
Information element name
Status
Description
Requested Information List 
M
This IE specifies a list of Requested information Values which are requested.
Leg ID
M
This IE indicates the party in the call for which information shall be collected.

4.7.1.5	Event Report BCSM
4.71.5.1	Description
This IF is used to notify the gsmSCF of a call-related event (i.e. BCSM events as answer and disconnect) previously requested by the gsmSCF in a Request Report BCSM Event IF.
4.7.1.5.2	Information Elements
Information element name
Status
Description
Event type BCSM
M
This IE specifies the type of event that is reported.
Event Specific Information BCSM
C
This IE indicates the call related information specific to the event.
Leg ID
M
This IE indicates the party in the call for which the event is reported.
Misc Call Info
M
This IE indicates the DP type.

If the Event Type BCSM IE contains either O_Answer or T_Answer, then the Event Specific Information BCSM IE contains the following information elements:
Information element name
Status
Description
Destination address
M
This IE specifies the destination address for the call leg.
The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of destination address may be zero.

If the Event Type BCSM IE contains one of Route_Select_Failure, O_Called_Party_Busy, O_Disconnect, T_Busy, or T_Disconnect, then the Event Specific Information BCSM IE contains the following information element:
Information element name
Status
Description
Cause
C
This IE indicates the cause.

If the Event Type BCSM IE contains O_No_Answer then the Event Specific Information BCSM IE is not included.
4.7.1.6	Initial DP
4.7.1.6.1	Description
This IF is generated by the IM‑SSF when a trigger is detected at a DP in the BCSM, to request instructions from the gsmSCF.
4.7.1.6.2	Information Elements
Information element name
IM_Orig
IM_Term
Description
Media Type Info List
M
      M
This IE indicates the media types associated with the SIP call session. This IE shall contain the media description(s) received from the S‑CSCF.
Called Party Number
C
C
This IE contains the ISDN number used to identify the called party in the forward direction.  

The ISDN called party number is received from the gsmSCF due to the previous CAMEL processing or is derived from the SIP URL received from the S‑CSCF for the destination address.

For all IM terminating call scenarios, at least one of the following IEs shall be present:
CalledPartyNumber
CalledPartyURL
Called Party URL
C
C
This IE contains the SIP URL used to identify the called party in the forward direction. 

For all IM terminating call scenarios, at least one of the following IEs shall be present:
CalledPartyNumber
CalledPartyURL
Calling Party Number
C
C
This IE carries the ISDN calling party number to identify the calling party or the origin of the call.

For all IM originating call scenarios, at least one of the following IEs shall be present:
CallingPartyNumber
CallingPartyURL
Calling Party URL
C
C
This IE contains the SIP URL used to identify the calling party or the origin of the call. 

For all IM originating call scenarios, at least one of the following IEs shall be present:
CallingPartyNumber
CallingPartyURL
Calling Party Category
C
C
Indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).
CallGap Encountered
C
C
This parameter indicates the type of gapping the related call has been subjected to.

This parameter shall be present only if a call gapping context is applicable to the initialDP operation.
SIP Call ID
M
M
This IE represents a globally unique identifier for the SIP call. This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. 

This IE is received from the SIP request message from S‑CSCF.
Cause
C
C
This IE indicates the cause specific to the armed BCSM DP event. This IE is applicable to DP Route_Select_Failure and DP T_Busy. The cause may be used by the SCF to decide about the further handling of the call.

For IM Termination for an unregistered subscriber, the Cause IE shall be set to indicate Subscriber Absent.
Event Type BCSM
M
M
This IE indicates the armed BCSM DP event, resulting in the Initial DP IF.

This IE shall be set to indicate DP T_Busy if a not reachable event is detected (e.g. IM termination to a subscriber not currently registered).
IMSI
M
M
This IE identifies the mobile subscriber.

This IE shall contain the IMSI value received from the S‑CSCF during notification of a SIP registration.
IP SSP Capabilities
C
C
This IE indicates which MRFC resources are supported within the IM‑SSF and are available. If this IE is absent, this indicates that no MRFC is attached and available.
IM‑SSF Address
M
M
This IE represents the E.164 address of the IM‑SSF from which the InitialDP operation is sent from. 
Original Called Party ID
C
C
This contains the ISDN number used to identify the original destination number if the call has been forwarded on route to the IM‑SSF or is forwarded by the gsmSCF due to the previous CAMEL processing.
Original Called Party URL
C
C 
This IE contains the SIP URL identifying the original destination number if the call has been forwarded on route to the IM—SSF or is forwarded by the gsmSCF due to the previous CAMEL processing.
Redirecting Party ID
C
C
This IE indicates the ISDN number identifying the directory number the call was redirected from. This IE shall also be sent if it was received from the gsmSCF due to the previous CAMEL processing.
Redirecting Party URL
C
C
This IE indicates the SIP URL identifying the directory number the call was redirected from. This IE shall also be sent if it was received from the gsmSCF due to the previous CAMEL processing.
Redirection Information
C
C
This IE contains forwarding related information, such as redirection reason. This IE shall also be sent if it was received from the gsmSCF due to the previous CAMEL processing.
Service Key
M
M
This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF.
Subscriber State
-
C
This IE indicates the status of the IMS Subscriber. The states are:
-	CAMELBusy: The IMS subscriber is engaged on a transaction for an originating or terminating IM call session.
-	NetworkDeterminedNotReachable: The network can determine from its internal data that the IMS subscriber is not reachable.
AssumedIdle: The state of the IMS subscriber is neither "CAMELBusy" nor "NetworkDeterminedNotReachable".
Time And Timezone
M
M
This IE contains the time that the IM‑SSF was triggered, and the time zone the IM‑SSF resides in.

4.7.1.7	Specialized Resource Report
4.7.1.7.1	Description
This IF is used to response to a PlayAnnouncement IF when the announcement complete indication is set.
4.7.1.7.2	Information Elements
This IF contains no information elements.
4.7.2	gsmSCF to IM‑SSF information flows
4.7.2.1	Activity Test
4.7.2.1.1	Description
This IF is used to check for the continued existence of a relationship between the gsmSCF and IM‑SSF. If the relationship is still in existence, then the IM‑SSF will respond. If no reply is received, then the gsmSCF will assume that the IM‑SSF has failed in some way and will take the appropriate action.
4.7.2.1.2	Information Elements
This IF contains no information elements.
4.7.2.2	Apply Charging
4.7.2.2.1	Description
This IF is used for interacting from the gsmSCF with the IM‑SSF charging mechanisms to control the call duration. 
4.7.2.2.2	Information Elements
Information element name
Status
Description
ACh Billing Charging Characteristics
M
This IE specifies the charging related information to be provided by the IM‑SSF and the conditions on which this information has to be provided back to the gsmSCF.
Party To Charge
M
This IE shall be reflected in the corresponding IE of the Apply Charging Report operation. This IE has no effect on the charging procedures in the MSC.

ACh Billing Charging Characteristics contains the following information:
Information element name
Status
Description
Time Duration Charging
M
This IE is described in the next table.

Time Duration Charging contains the following information:
Information element name
Status
Description
Max Call Period Duration
M
This IE indicates the maximum call period duration timer.
Tariff Switch Interval
O
This IE indicates the tariff switch time until the next tariff switch applies.
Release If Duration Exceeded
O
This IE indicates that the call shall be released when the Max call Period Duration expires, with a warning tone if the Play Tone IE is present. The cause used in the release message shall be "normal unspecified".
Default is to continue the call.
Play Tone
O
This IE is set if a tone has to be played to the party for whom the BCSM is operating. If present, this IE indicates that 30 seconds before the Max Call Period Duration timer expires, 
a triple tone of 900 Hz (200 milliseconds tone, 200 milliseconds pause) shall be played.

4.7.2.3	Call Information Request
4.7.2.3.1	Description
This IF is used to request the IM‑SSF to record specific information about a single call and report it to the gsmSCF (with a CallInformationReport).
4.7.2.3.2	Information Elements
Information element name
Status
Description
Requested Information Type List
M
This IE specifies a list of specific items of information which are requested.
Leg ID
M
This IE indicates the party in the call for which information shall be collected.
Requested Information Type List contains the following information:
Information element name
Status
Description
Call Attempt Elapsed Time
O
This IE indicates that the Call Attempt Elapsed Time is requested in the Call Information Report.
Call Attempt Elapsed Time is the duration between the end of the CAMEL processing initiating call setup (Connect, Continue or Continue With Argument IF) and the received answer indication from the called party side.
For the Calling Party, the value of Call Attempt Elapsed Time in the Call Information Report shall be set to 0.
Call Stop Time
O
This IE indicates that the Call Stop Time is requested in the Call Information Report.
Call Stop Time is the time stamp when the connection is released.
Call Connected Elapsed Time
O
This IE indicates that the Call Connected Elapsed Time is requested in the Call Information Report.
Call Connected Elapsed Time is the duration between the received answer indication from the called party side and the release of the connection.
For a Calling Party, it indicates the duration between the sending of IDP and the release of that party
Release Cause
O
This IE indicates that the Release Cause is requested in the Call Information Report.
Release Cause is the release cause for the call.

4.7.2.4	Cancel
4.7.2.4.1	Description
This IF is used by the gsmSCF to request the IM‑SSF to cancel all EDPs and reports.
4.7.2.4.2	Information Elements
Information element name
Status
Description
All Requests
M
This IE indicates that all active requests for EventReportBCSM, ApplyChargingReport and CallInformationReport shall be cancelled.

4.7.2.5	Connect
4.7.2.5.1	Description
This IF is used to request the IM‑SSF to perform the call processing actions to route a call to a specific destination. To do so, the IM‑SSF may use destination information from the calling party and existing call set-up information depending on the information provided by the gsmSCF.
4.7.2.5.2	Information Elements
Information element name
Status
Description
Calling Party Category
O
This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).
Destination Routing Address
E1
This IE contains the called party number towards which the call is to be routed using an ISDN value.
Destination Routing Address URL  
E1
This IE contains the called party number towards which the call is to be routed using a SIP URL.
Original Called Party ID
O,E2
This contains the original destination number if the call has been forwarded on route to the IM‑SSF or is forwarded by the gsmSCF.

This IE shall use an ISDN value to identify the original destination number. 
Original Called Party URL
O,E2
This contains the original destination number if the call has been forwarded on route to the IM‑SSF or is forwarded by the gsmSCF. 

This IE shall use a SIP URL to identify the original destination number.
Redirecting Party ID
O,E3
This IE indicates the directory number the call was redirected from. This IE shall use an ISDN value to identify the redirecting party.
Redirecting Party URL
O,E3
This IE indicates the directory number the call was redirected from. This IE shall use a SIP URL to identify the redirecting party.

4.7.2.6	Connect To Resource
4.7.2.6.1	Description
This IF is used to connect a call from the IM‑SSF to MRFC via S‑CSCF.
4.7.2.6.2	Information Elements
This IF requires no information elements for IMS.
4.7.2.7	Continue
4.7.2.7.1	Description
This IF requests the IM‑SSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. The IM‑SSF completes DP processing, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) without substituting new data from the gsmSCF.
4.7.2.7.2	Information Elements
This IF contains no information elements.
4.7.2.8	Continue With Argument
4.7.2.8.1	Description
This information flow requests the IM‑SSF to proceed the call processing with modified information at the DP at which it previously suspended call processing to await gsmSCF instructions. The IM‑SSF completes DP processing, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) with the modified call setup information as received from the gsmSCF.
4.7.2.8.2	Information Elements
Information element name
Status
Description
Calling Party Category
O
This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).

4.7.2.9	Disconnect Forward Connection
4.7.2.9.1	Description
This IF is used to disconnect a connection with a MRFC previously established with a Connect To Resource IF.
4.7.2.9.2	Information Elements
This IF contains no information elements.
4.7.2.10	Furnish Charging Information
4.7.2.10.1	Description
This IF is used to request the IM‑SSF to include call related information in the CAMEL specific logical call record. The logical call record is created when FCI is received and a logical call record for that leg does not exist. For modelling purposes the logical call record is buffered in the IM‑SSF. The IM‑SSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data is moved to the corresponding CDR and the logical call record is deleted.
The CSE can send multiple concatenated FCIs per leg for completion. The total maximum of free format data is 160 octets per leg. The 160 octets may be sent in one or more FCI operations. If there is non-completed free format data and new FCI operation(s) is/are received to overwrite the non-completed data, then the non-completed data is discarded and the gsmSCF can send another 160 octets per leg. The SDLs of 3GPP TS 23.078 Rel‑99 [4] define when Logical CDRs are completed. After the completion the gsmSCF can send another 160 octets of free format data in one or more FCI operations for the called leg.
4.7.2.10.2	Information Elements
Information element name
Status
Description
FCI Billing Charging Characteristics
M
This IE is described in the next table.

FCI Billing Charging Characteristics contains the following information:
Information element name
Status
Description
FCIBCCCAMEL Sequence 1
M
This IE is described in the next table.

FCIBCCCAMEL Sequence 1 contains the following information:
Information element name
Status
Description
Free Format Data
M
This IE is a free format data to be inserted in the CAMEL logical call record.
Party To Charge
M
This IE indicates the party for whom a CAMEL logical call record will be created.
Append Free Format Data
O
This IE indicates that the IM‑SSF shall append the free format data to the Logical call record.
-	If this IE is present and indicates "Append", the IM‑SSF shall append the free format data received in this IF to the free format data already present in the Logical call record for that leg of the call.
-	If this IE is absent or in value "Overwrite", then the IM‑SSF shall overwrite all free format data already present in the Logical call record for that leg of the call, by the free format data received in this IF.
If no Logical call record exists yet for that leg of the call, then the IM‑SSF shall ignore this IE.

4.7.2.11	Release Call
4.7.2.11.1	Description
This IF is used to tear down by the gsmSCF an existing call at any phase of the call for all parties involved in the call.
4.7.2.11.2	Information Elements
The following information elements are required:
Information element name
Status
Description
Release Cause
M
A number giving an indication to the IM‑SSF about the reason of releasing this specific call. This may be used by MSC/GMSC for generating specific tones to the different parties in the call or to fill in the "cause" in the release message.

4.7.2.12	Request Report BCSM Event
4.7.2.12.1	Description
This IF is used to request the IM‑SSF to monitor for a call-related event, then send a notification back to the gsmSCF when the event is detected (see Event Report BCSM).
4.7.2.12.2	Information Elements
Information element name
Status
Description
BCSM Event
M
This IE specifies the event or events of which a report is requested.

BCSM Event contains the following information:
Information element name
Status
Description
Event type
M
This IE specifies the type of event of which a report is requested.
Leg ID
C
This IE indicates the party in the call for which the event shall be reported.
Monitor Mode
M
When this IE is "interrupted", the event shall be reported as a request, if it is "notifyAndContinue", the event shall be reported as a notification, if the IE is "transparent", the event shall not be reported.
DP Specific Criteria
O
This IE is described in the next table.

DP Specific Criteria is defined as:
Information element name
Status
Description
Application Timer
O
This IE carries additional timer duration information (timer values for No Answer event) required for arming No_Answer EDPs in the IM‑SSF. The TNRy timer (value defined between 10 s and 40 s) shall be shorter than the network no answer timer.
NOTE	If a Request Report BCSM Event information flow overwrites previous Request Report BCSM Event information flow which contained Application Timer IE for No_Answer DP, the behaviour of the IM‑SSF is unpredictable.

4.7.2.13	Reset Timer
4.7.2.13.1	Description
This IF is used to refresh a timer. 
4.7.2.13.2	Information Elements
Information element name
Status
Description
Timer Value
M
This IE specifies the value to which the indicated timer shall be set.
Timer ID
O
This IE indicates which timer shall be reset. It shall be set to "Tssf".

4.7.3	gsmSCF – IM‑SSF information flows for MRFC related operations
In an IMS Core Network, the Multimedia Resource Function Controller (MRFC) is used for providing specialised resource functions like playing announcements and tones. Requests from the gsmSCF that requires a specialised resource function are sent to the MRFC via the IM‑SSF and S‑CSCF using SIP signalling as specified in the functional requirements of the MRFC found in 3GPP TS 23.218 [5]. 
This subclause contains the information flows descriptions between the gsmSCF and the IM‑SSF for MRFC-related operations.
4.7.3.1	Cancel
4.7.3.1.1	Description
This IF is used by the gsmSCF to request the IM‑SSF to cancel a correlated previous operation in the MRFC.
4.7.3.1.2	Information Elements
The following information elements are used:
Information element name
Status
Description
Invoke ID
M
This IE specifies the operation to be cancelled.

4.7.3.2	Play Announcement
4.7.3.2.1	Description
This IF is sent from the gsmSCF to the IM‑SSF and is used to specify information for playing announcements or tones in the MRFC. 
4.7.3.2.2	Information Elements
The following information elements are required:
Information element name
Status
Description
Information To Send
M
This IE indicates an announcement or a tone to be sent to the end user by the MRFC.
Disconnect From IP Forbidden
M
This IE indicates whether or not the MRFC may be disconnected from the user when all information has been sent.
Request Announcement Complete
M
This IE indicates whether or not a SpecializedResourceReport shall be sent to the gsmSCF when all information has been sent.

Information To Send contains the following information:
Information element name
Status
Description
Inband Info
C
This IE indicates the inband information to be sent.
Tone
C
This IE indicates the tone to be sent. The mapping from the code points of this IE to tones is a matter for agreement between the gsmSCF operator and the MRFC operator.

Inband Info contains the following information:
Information element name
Status
Description
Message ID
M
This IE is described in the next table.
Number Of Repetitions
M
This IE indicates the maximum number of times the message shall be sent to the end-user.
Duration
O
This IE indicates the maximum duration time in seconds that the message shall be played/repeated. Zero indicates endless repetition.
Interval
O
This IE indicates the time interval in seconds between two repetitions.

Message ID contains the following information:
Information element name
Status
Description
Elementary Message ID
C
This IE indicates a single announcement
Text
C
This IE indicates a text to be sent. The text shall be transformed to inband information (speech) by the MRFC.
Elementary Message IDs
C
This IE indicates a sequence of announcements
Variable Message
C
This IE indicates an announcement with one or more variable parts.

Tone contains the following information:
Information element name
Status
Description
Tone ID
M
This IE indicates the tone to be sent.
Duration
O
This IE indicates the maximum duration time in seconds that the message shall be played/repeated. Zero indicates endless repetition.

4.7.3.3	Prompt And Collect User Information (received information)
4.7.3.3.1	Description
This IF is sent from the gsmSCF to the IM‑SSF and is used to interact with a call party in order to collect information.
4.7.3.3.2	Information Elements
The following information elements are required:
Information element name
Status
Description
Collected Info
M
This IE is described in the next table.
Information To Send
O
This IE indicates an announcement or a tone to be sent to the end user by the MRFC.
Disconnect From IP Forbidden
M
This IE indicates whether the MRFC may be disconnected from the user when all information has been sent.

Collected Info contains the following information:
Information element name
Status
Description
Collected Digits
M
This IE is described in the next table.

Collected Digits contains the following information:
Information element name
Status
Description
Minimum Number Of Digits
M
This IE indicates the minimum number of valid digits to be collected.
Maximum Number Of Digits
M
This IE specifies the maximum number of valid digits to be collected
End Of Reply Digit
O
This IE indicates the digit(s) used to signal the end of input.
Cancel Digit
O
If this IE is present, the cancel digit can be entered by the user to request a possible retry
Start Digit
O
If this IE is present, the start digit(s) indicates the start of the valid digits to be collected.
First Digit Time Out
O
If this IE is present, the first digit shall be received before the expiration of the first digit timer expiration
Inter Digit Time Out
O
If this IE is present, any subsequent valid or invalid digit shall be received by the MRFC before the inter digit timer expires.
Error Treatment
O
This IE indicates what specific action shall be taken by the MRFC in the event of error conditions occurring.
Interruptable Ann Ind
O
If this IE is set to TRUE (default value) the announcement is interrupted after the first valid or invalid digit received by the MRFC. If this IE is present and explicitly set to FALSE, the announcement will not be interrupted after the first digit is received by the MRFC
Voice Information
O
This IE is optional, where the default value is specified being FALSE. If the VoiceInformation IE is set to FALSE, all valid or invalid digits are entered by DTMF If this IE is present and explicitly set to TRUE, calling user is required to provide all valid or invalid information by speech
Voice Back
O
This IE is optional, where the default value is specified being FALSE. If the VoiceBack IE is set to FALSE, no voice back information is given by the MRFC If this IE is present and explicitly set to TRUE, the valid input digits received by the MRFC will be announced back to the calling user immediately after the end of input is received

InformationToSend is defined in subclause 4.7.3.2.2.
4.7.3.4	Prompt And Collect User Information ack (received information)
4.7.3.4.1	Description
This IF is used by the IM‑SSF to indicate the result a Prompt And Collect User Information IF to the gsmSCF.
4.7.3.4.2	Information Elements
The following information elements are required:
Information element name
Status
Description
Digits Response
C
This IE indicates the digit sequence received from the end user

4.7.3.5	Specialized Resource Report
4.7.3.5.1	Description
This IF is used by the IM‑SSF to response to a PlayAnnouncement IF when the announcement complete indication is set.
4.7.3.5.2	Information Elements
This IF contains no information elements.
4.7.4	IM‑SSF to HSS information flows
4.7.4.1	Any Time Subscription Interrogation request 
4.7.4.1.1	Description
This IF is used by the IM‑SSF to request subscription information from the HSS. For example, the IM‑SSF shall send this as a result of receiving a third party SIP registration from the S‑CSCF (over the ISC interface). The IM‑SSF shall also send the MAP ATSI request when a SIP INVITE message on a MT session for an unregistered subscriber is received.
4.7.4.1.2	Information Elements
Information element name
Status
Description
gsmSCF Address
M
This IE shall indicate the address of the interrogating IM‑SSF. The address shall be in international E.164 format.
Requested Info
M
This IE indicates the type of subscriber information being requested. 
This shall consist of the CAMEL Subscription Information; the CAMEL Subscription Information is described in a table below.
Subscriber Identity
M
This IE identifies the subscriber for which the information is requested. The identity shall be an IMSI.

CAMEL subscription information contains the following information elements:
Information element name
Status
Description
Additional Requested CAMEL Subscription Info
M
This IE shall contain one of the following: O‑IM‑CSI/VT‑IM‑CSI/D‑IM‑CSI

4.7.4.2	Notify Subscriber Data Change ack
4.7.4.2.1	Description
This IF is used to respond to the HSS's notification of the change of subscriber data.
4.7.4.2.2	Information Elements
This IF contains no information elements.
4.7.5	HSS to IM‑SSF information flows
4.7.5.1	Any Time Subscription Interrogation ack 
4.7.5.1.1	Description
This IF is used by the HSS to provide the requested subscriber's IM‑CSI data to the IM‑SSF. 
4.7.5.1.2	Information Elements
Information element name
Status
Description
CAMEL Subscription Information
C
This IE shall be present if the subscriber is provisioned with a CAMEL Subscription Information for IM CN. This IE is described in a table below.

CAMEL Subscription Information contains the following information elements:
Information element name
Status
Description
O‑IM‑CSI
C
See subclause 4.4.1.1
D‑IM‑CSI
C
See subclause 4.4.1.2
VT‑IM‑CSI
C
See subclause 4.4.1.3

4.7.5.2	Notify Subscriber Data Change
4.7.5.2.1	Description
This IF is used by the HSS to notify to the IM‑SSF of the change of subscriber IM CSI data. This IF is sent at each time subscriber IM CSI data is changed.
4.7.5.2.2	Information Elements
Information element name
Status
Description
IMSI
M
The IMSI is used to identify the subscriber.
MSISDN
C
This shall consist of the subscriber's MSISDN if available.  If no MSISDN is available, the parameter shall be set with a dummy MSISDN value.
CAMEL Subscription Information
M
The CAMEL Subscription Information IE is used to indicate the modified or deleted CAMEL Subscription Information data. This IE is described in a table below. 

CAMEL Subscription Information Modified contains the following information elements:
Information element name
Status
Description
O‑IM‑CSI
S
See subclause 4.4.1.1. It shall be present if it was modified.
D‑IM‑CSI
S
See subclause 4.4.1.2. It shall be present if it was modified.
VT‑IM‑CSI
S
See subclause 4.4.1.3. It shall be present if it was modified.
Specific CSI Deleted List
S
This IE indicates that one or more specific elements of IMS CAMEL Subscription Information have been deleted from the HSS. It shall indicate any of the following;
-	O‑IM‑CSI (with TDP criteria for O‑IM‑CSI);
-	D‑IM‑CSI;
-	VT‑IM‑CSI with TDP criteria for VT‑IM‑CSI;
This IE shall be present if IM CSI is/are deleted.

5	Control and interrogation of subscription data
Support of the procedures described in this clause in CAMEL Phase 4 is a network operator option.
5.1	Architecture
The architecture for the control and the interrogation of subscription data described in the clause 10 in 3GPP TS 23.078 Rel‑99 [4] for the HLR and the gsmSCF also applies for the HSS and the gsmSCF.
5.2	Procedures for CAMEL
5.2.1	Any Time Subscription Interrogation
The following process in the HLR described in 3GPP TS 23.078 Rel‑99 [4] applies for the handling of Any Time Interrogation for Subscription Information Retrieval in the HSS:
-	CAMEL_ATSI_HLR.
5.2.2	Any Time Modification
The following process in the HLR described in 3GPP TS 23.078 Rel‑99 [4] applies for the handling of Any Time Modification in the HSS:
-	CAMEL_ATM_HLR.
5.2.3	Notify Subscriber Data Change
The description of the procedure in 3GPP TS 23.078 Rel‑99 [4] applies for the handling of Notify Subscriber Data Change in the HSS.
5.3	Description of information flows
This subclause contains the detailed description of the information flows used by CAMEL for control and interrogation of subscription data.
Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or Optional (O).
An 'M' IE shall always be included. A 'C' IE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S' IE are shown in the 'Description' column of the definition table. An 'O' IE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol.
The following principles apply for the handling of the IEs by the receiving entity:
-	The gsmSCF may silently discard any IE which it does not functionally support.
-	The HSS shall return an error if it does not functionally support an IE which it receives.
Details of errors and exceptions to these rules are specified in 3GPP TS 29.002 [9]. 
5.3.1	gsmSCF to HSS information flows
5.3.1.1	Any Time Modification Request
5.3.1.1.1	Description
This IF is used to modify information in the HSS at any time. The IF from the gsmSCF to the HLR is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.1.2	Any Time Subscription Interrogation Request
5.3.1.2.1	Description
This IF is used to request subscription information from the HSS at any time. The IF from the gsmSCF to the HLR is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.1.2.2	Information Elements
Any Time Subscription Interrogation Request is specified in 3GPP TS 23.078 Rel‑99 [4]. Additionally the following IMS specific information elements are required:
Information element name
Status
Description
Requested Info
M
This IE may indicate supported CAMEL phases in HSS.

Additional CAMEL Subscription Info
S,E
This IE may be one of the following elements:
O‑IM‑CSI / VT‑IM‑CSI / D‑IM‑CSI.

5.3.1.3	Notify Subscriber Data Change response
5.3.1.3.1	Description
This IF is used by the gsmSCF to respond to the HSS of the change of subscriber data notify. The IF from the gsmSCF to the HLR is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.2	HSS to gsmSCF information flows
5.3.2.1	Any Time Modification ack
5.3.2.1.1	Description
This IF is used by the HSS to provide the modified information to the gsmSCF. The IF from the HLR to the gsmSCF is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.2.1.2	Information Elements
Any Time Modification ack is specified in 3GPP TS 23.078 Rel‑99 [4]. Additionally the following IMS specific information elements are required:
Information element name
Status
Description
O‑IM‑CSI
S
See subclause 4.4.1.1. It shall be present if it was modified.
VT‑IM‑CSI
S
See subclause 4.4.1.3. It shall be present if it was modified.
D‑IM‑CSI
S
See subclause 4.4.1.2. It shall be present if it was modified.

5.3.2.2	Any Time Subscription Interrogation ack
5.3.2.2.1	Description
This IF is used by the HSS to provide the requested subscription information to the gsmSCF. The IF from the HLR to the gsmSCF is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.2.2.2	Information Elements
Any Time Subscription Interrogation ack is specified in 3GPP TS 23.078 Rel‑99 [4]. Additionally the following IMS specific information elements are required:
Information element name
Status
Description
Supported CAMEL Phases In HSS
C
This IE indicates the CAMEL phase supported in the HSS.
O‑IM‑CSI
C
See subclause 4.4.1.1.
VT‑IM‑CSI
C
See subclause 4.4.1.3.
D‑IM‑CSI
C
See subclause 4.4.1.2.

5.3.2.3	Notify Subscriber Data Change
5.3.2.3.1	Description
This IF is used by the HSS to notify to the gsmSCF of the change of subscriber data. This IF is sent at each time subscriber data is changed. The IF from the HLR to the gsmSCF is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
5.3.2.3.2	Information Elements
Notify Subscriber Data Change is specified in 3GPP TS 23.078 Rel‑99 [4]. Additionally the following IMS specific information elements are required:
Information element name
Status
Description
Specific CSI Deleted List
S
This IE shall indicate any of the following;
-	O‑IM‑CSI (with TDP criteria for O‑IM‑CSI);		‑
-	D‑IM‑CSI (with TDP criteria for D‑IM‑CSI);
-	VT‑IM‑CSI with TDP criteria for VT‑IM‑CSI;

6	Subscriber Location and State retrieval
Support of the procedures described in this clause in CAMEL Phase 4 is a network operator option.
6.1	Architecture
The architecture for the subscriber location and state retrieval described in the clause 11 in 3GPP TS 23.078 Rel‑99 [4] for the HLR and the gsmSCF applies for the HSS and the gsmSCF.
6.2	Procedures for CAMEL
6.2.1	Any Time Interrogation
The description of the procedure in 3GPP TS 23.078 Rel‑99 [4] applies for the Any Time Interrogation in the HSS.
6.3	Description of information flows
This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of information about the location and state of a subscriber.
Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-).
An 'M' IE shall always be included. A 'C' IE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S' IE are shown in the 'Description' column of the definition table. When a set of 'E' IEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A '‑' IE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol.
The following principles apply for the handling of the IEs by the receiving entity:
-	The gsmSCF may silently discard any IE which it does not functionally support.
-	The GMLC shall return an error if it does not functionally support an IE which it receives.
Details of errors and exceptions to these rules are specified in 3GPP TS 29.002 [9]. 
6.3.1	gsmSCF to HSS information flows
6.3.1.1	Any Time Interrogation Request
6.3.1.1.1	Description
This IF is used to request information (any one or more of subscriber state, subscriber location, IMEI & software version, MS classmark information for the CS domain and GPRS MS classmark information) from the HSS at any time. The IF from the gsmSCF to the HLR is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
6.3.2	HSS to gsmSCF information flows
6.3.2.1	Any Time Interrogation ack
6.3.2.1.1	Description
This IF is used by the HSS to provide the requested subscriber location and/or subscriber state information to the gsmSCF. The IF from the HLR to the gsmSCF is specified in 3GPP TS 23.078 Rel‑99 [4]. The IF is also applied to the interface between the gsmSCF to the HSS.
Annex A (informative):
Change history
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew09/2002CN#17NP-020348Creation of version 5.0.02.1.05.0.012/2002CN#18NP-0205300012Correction and improvement in the overall SDL structure5.0.05.1.012/2002CN#18NP-020530002Correction and improvement in the registration procedures5.0.05.1.012/2002CN#18NP-0205320032Correction and improvement in MO procedures5.0.05.1012/2002CN#18NP-0205320043Correction and improvement in MT procedures5.0.05.1012/2002CN#18NP-020530005Correction and improvement in CSI update5.0.05.1.012/2002CN#18NP-020530006Clarification in the case multiple RRBs are sent for a DP5.0.05.1.012/2002CN#18NP-0205300071Inconsistent description on ACR: time information5.0.05.1.012/2002CN#18NP-020530008Remove support of SCI operation from imcnSSF SDL process5.0.05.1.012/2002CN#18NP-020530009Removal of ETC processing from IM-SSF SDL Procedures5.0.05.1.012/2002CN#18NP-0205300101Correction of InitialDP MediaType parameter5.0.05.1.012/2002CN#18NP-0205320121IF Description for gsmSRF-related operations for IMS5.0.05.1012/2002CN#18NP-020529014Figure and table numbers editorial changes5.0.05.1012/2002CN#18NP-020531015For better document structure - editorial5.0.05.1.012/2002CN#18NP-020531016Editorial improvement - clause 25.0.05.1.012/2002CN#18NP-020531017Editorial improvement - clause 35.0.05.1.012/2002CN#18NP-020531018Editorial improvement - clause 45.0.05.1.012/2002CN#18NP-020531019Editorial improvement - clause 55.0.05.1.012/2002CN#18NP-020531020Editorial improvement - clause 65.0.05.1012/2002CN#18NP-020531021Editorial improvement - clause 75.0.05.1012/2002CN#18NP-020532022SDL Procedure for Connect To Resource5.0.05.1012/2002CN#18NP-0205320231Stage 2 specifications for Call Gap for IMS5.0.05.1012/2002CN#18NP-0205320242Clarification of DP destination number trigger criteria for IMS5.0.05.1012/2002CN#18NP-020532025Number comparison  for D-CSI5.0.05.1012/2002CN#18NP-020532026Correction to Dialled Services criteria5.0.05.1003/2003CN#19NP-0300900271Implementing of Connect to Resource handling in CAMEL for IMS5.1.05.2.003/2003CN#19NP-0300900281Introduction of ResetTimer input in state WFI-DS (IMS)5.1.05.2.003/2003CN#19NP-030090029Correction of imcnSSF procedure names 5.1.05.2.003/2003CN#19NP-030090030Incorrect procedure names used for CAMEL_MT_CTR and CAMEL_MO_CTR5.1.05.2.003/2003CN#19NP-030090031Incorrect procedures called in CAMEL_IMCN_MT_ANSWER5.1.05.2.003/2003CN#19NP-030091032Sending of provisional response for the INVITE5.1.05.2.003/2003CN#19NP-030091033Incorrect SIP response when no CAMEL is invoked5.1.05.2.003/2003CN#19NP-0300910351Corrections in CAMEL_IMCN_MO_ANSWER5.1.05.2.003/2003CN#19NP-030091036Corrections in the procedures for handling failure SIP response5.1.05.2.003/2003CN#19NP-030091039Inconsistency in Call Information Report in Re-Connect Case5.1.05.2.006/2003CN#20NP-0301910401Incorrect list of TDPs listed for O-IM-CSI5.2.05.3.006/2003CN#20NP-030191041Corrections to process IM-SSF5.2.05.3.006/2003CN#20NP-030191042Redundant check for Final_Response_Received in Disconnect procedures5.2.05.3.009/2003CN#21NP-0303740432Incorrect handling of failure SIP response for MT5.3.05.4.009/2003CN#21NP-0303740442Setting of Timers not specified for IM-SSF process5.3.05.4.009/2003CN#21NP-0303740451Incorrect handling of failure SIP response for MO5.3.05.4.012/2003CN#22NP-0305250461Correction to the definition of interfaces for the IM-SSF5.4.05.5.009/2004CN#25NP-040397047Correction of Check_Criteria Procedure names referenced in Process imcnSSF5.5.05.6.012/2004CN#26Rel-6 created after CN#265.6.06.0.006/2005CT#28CP-0500970048Removal of references to HLR for CAMEL control of IMS6.0.06.1.012/2005CT#30CP-0506650049Incorrect References6.1.06.2.012/2005CT#30Rel-7 version was created because of ETSI TISPAN references.6.2.07.0.003/2006CT#31CP-0600820050Specification of gsmSCF Address format in AnyTime request messages7.0.07.1.012/2008CT#42Upgraded unchanged from Rel-77.1.08.0.02009-12----Update to Rel-9 version (MCC)8.0.09.0.0




















 PAGE 2
 STYLEREF ZGSM Release 9
 STYLEREF ZA 3GPP TS 23.278 V9.0.0 (2009-12)


3GPP