idnits 2.17.1 draft-giordano-cli-forward-in-call-trx-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 180. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 November 2007) is 6017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Daniele Giordano 3 4 November 2007 4 Expires: 7 May 2008 6 CLI forwarding method during call transfer 7 draft-giordano-cli-forward-in-call-trx-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The IETF Trust (2007). 36 Abstract 38 Many telephony services are IP based and they can use various 39 signaling protocols like H.323, SIP, MGCP, MEGACO and vendor 40 proprietary protocols. This document describe a method to identify 41 and to change the Calling Line Identification (or CLI) field during 42 call forwarding. This method is voice over ip protocol independent. 43 This method can be apply to all voice over ip protocols. 45 Table of Contents 47 1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Implementation and Operations . . . . . . . . . . . . . . . . 3 50 4. Consideration about well known services . . . . . . . . . . . . 4 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Intellectual Property and Copyright Statements . . . . . . . . . . 6 57 1. Conventions Used In This Document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 2. Introduction 65 In POTS/PSTN networks the CLI (Calling Line Identification) is a base 66 information about the billing telephone number from which calls are 67 originated. CLI can be managed to obtain various services: CLI 68 presentation or CLIP, CLI restriction or CLIR, CLI stripping, CLI 69 screening and other well known services. 70 These cases are implemented in IP based telephony network or voice 71 over IP network. 72 But, What happens during call forwarding? 73 In traditional telephony, two calling line ids are sent along with 74 the outgoing call. 75 It doesn't happen in the current IP implementations. 76 There is a need for a mechanism to identify the originating party and 77 to send the appropriate CLI. 79 3. Implementation and Operations 81 When a call is forwarded (unconditionally, on busy and not answered) 82 we MUST identify three parties: the calling party A, the called 83 transferor party B and the transferred party C. 85 call flow 87 A ----------> B ---------> C 89 During call setup A sends its CLI to B. 90 B can send both CLI, its own and CLI of A. 91 CLI of A SHOULD be called original-CLI; CLI of B SHOULD be called 92 transferor-CLI. 94 What happens to CLI in this scenario? 95 We MUST identify two cases: 97 1) CLI pass through: the transferred party C MUST receive the 98 original-CLI 100 A ----------> B ---------> C 101 |____________CLI___________| 103 2) CLI override: the transferred party C MUST receive the 104 transferor-CLI 106 A ----------> B ---------> C 107 |_____CLI____| 109 Who set the forwarding MUST select a CLI forwarding method. In this 110 way the appropriate caller line id can be sent during call setup. 112 This implementation would be protocol independent. All signaling 113 protocols describe how to write CLI information in own signaling 114 message. 116 4. Consideration about well known services 118 This draft doesn't influence the correct working of well known 119 services like CLI Presentation or CLI Restriction. Their working is 120 described in all signaling voice protocols. 122 5. Security Considerations 124 This document is not directly concerned with security. 125 However, implementing this feature you can obtain more control over 126 call routing and more information in the call report. 128 6. IANA Considerations 130 None. 132 7. Normative References 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, March 1997. 137 Author's Address 139 Giordano Daniele 140 Email: d.giordano@fastpiu.it 142 Full Copyright Statement 144 Copyright (C) The IETF Trust (2007). 146 This document is subject to the rights, licenses and restrictions 147 contained in BCP 78, and except as set forth therein, the authors 148 retain all their rights. 150 This document and the information contained herein are provided on an 151 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 152 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 153 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 154 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 155 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 156 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 158 Intellectual Property 160 The IETF takes no position regarding the validity or scope of any 161 Intellectual Property Rights or other rights that might be claimed to 162 pertain to the implementation or use of the technology described in 163 this document or the extent to which any license under such rights 164 might or might not be available; nor does it represent that it has 165 made any independent effort to identify any such rights. Information 166 on the procedures with respect to rights in RFC documents can be 167 found in BCP 78 and BCP 79. 169 Copies of IPR disclosures made to the IETF Secretariat and any 170 assurances of licenses to be made available, or the result of an 171 attempt made to obtain a general license or permission for the use of 172 such proprietary rights by implementers or users of this 173 specification can be obtained from the IETF on-line IPR repository at 174 http://www.ietf.org/ipr. 176 The IETF invites any interested party to bring to its attention any 177 copyrights, patents or patent applications, or other proprietary 178 rights that may cover technology that may be required to implement 179 this standard. Please address the information to the IETF at 180 ietf-ipr@ietf.org. 182 Acknowledgment 184 Funding for the RFC Editor function is provided by the IETF 185 Administrative Support Activity (IASA).