1、 ETSI TR 183 057 V2.1.1 (2008-07)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Feasibility study on Out-of-band DTMFETSI ETSI TR 183 057 V2.1.1 (2008-07) 2 Reference DTR/TISPAN-03112-NGN-R2 Keywords DTMF, outband ETSI 650 Route des
2、Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from:
3、http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be th
4、e printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at
5、http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright
6、 and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade
7、 Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 183 057 V2.1.1 (2008-07) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Normative references .5 2.2 Informative references5 3 Abbreviations .6 4 Introductio
8、n and use cases6 4.1 Introduction 6 4.2 Use cases 7 5 Needs7 6 Overview of technical solutions.8 6.1 General .8 6.2 DTMF transport along the session signalling path.8 6.3 DTMF transport outside the session signalling path 8 6.3.1 General8 6.3.2 Use of SIP Event Management capabilities9 6.3.2.1 Descr
9、iption9 6.3.2.2 Dialog correlation .10 6.3.2.3 Forking10 6.3.3 Use of a dedicated control channel .10 7 Comparison of solutions.11 History 12 ETSI ETSI TR 183 057 V2.1.1 (2008-07) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to
10、 ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is ava
11、ilable from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referen
12、ced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Netwo
13、rking (TISPAN). ETSI ETSI TR 183 057 V2.1.1 (2008-07) 5 1 Scope The purpose of the present document is to analyse the requirements for out-of-band DTMF transport in IMS, to assess the possible technical solutions addressing these requirements, to select a solution and to identify and derive the requ
14、ired changes to the relevant IMS specifications. NOTE: The consequence of the TR will most certainly lead to developing CRs against ETSI TISPAN Release 2 IMS specifications and the corresponding 3GPP specifications. 2 References References are either specific (identified by date of publication and/o
15、r edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes o
16、f the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. For online referenced documents, information sufficient to
17、 identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the me
18、thod of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case letters. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Normative refer
19、ences Not applicable. 2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendm
20、ents) applies. i.1 ETSI ES 283 003: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 3GPP TS 24.229 (Release 7), modified“.
21、 i.2 IETF RFC 2833: “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals“. i.3 IETF RFC 2976: “The SIP INFO Method“. i.4 IETF RFC 4730: “A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)“. ETSI ETSI TR 183 057 V2.1.1 (2008-07) 6 i.5 3GPP TR 24.880: “3rd G
22、eneration Partnership Project; Technical Specification Group Core Network and Terminals Media server control using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3“. i.6 draft-mcglashan-mscp-03: “Media Server Control Protocol (MSCP)“. i.7 draft-ietf-sip-gruu: “Obtaining and Using Globally
23、 Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)“. i.8 draft-ietf-sipping-dialogusage: “Multiple Dialog Usages in the Session Initiation Protocol“. i.9 draft-kaplan-sip-info-events-00: “SIP INFO Event Framework“. i.10 draft-kaplan-sipping-dtmf-package-00: “DTMF Info-Eve
24、nt Package“. i.11 http:/www1.ietf.org/mail-archive/web/sip/current/msg20982.html. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: AS Application Server B2BUA Back to Back User Agent CSCF Call Session Control Function DTMF Dual Tone Multi Frequency GRUU Gl
25、obally Routable UA URI IMS IP Multimedia Core Network Subsystem IVR Interactive Voice ResponseKPML Key Press Markup Language MRF Media Resource Function MSCP Media Server Control Protocol MSML Media Server Markup Language NGN Next Generation Network PSTN Public Switched Telecommunications Network RT
26、P Real-Time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol UA User Agent UE User Equipment URI Uniform Resource Identifier XML eXtended Markup Language 4 Introduction and use cases 4.1 Introduction The TISPAN Release 1 set of standards supports transport of DTMF
27、using in-band signals in the form of RTP packets. The actual waveforms may be encoded using a voice codec (e.g. G.711) or represented using a dedicated format defined in RFC 2833 i.2. In-band transport provides a suitable solution to cover all use cases where DTMF has to be exchanged within the fram
28、ework of an established media link between two entities. This typically occurs when the user explicitly connects to a DTMF-driven menu (e.g. voicemail browsing, televoting, etc.) or when a call is directed to an intermediary entity (e.g. an MRF) so that a user interaction procedure can take place pr
29、ior to completing the establishment of the call (e.g. credit card calling). ETSI ETSI TR 183 057 V2.1.1 (2008-07) 7 However, this solution is far less suitable when DTMF is used as a means to invoke a particular feature in a network entity that has no inherent reason for being in the media path at t
30、he moment this feature is invoked. Although the network entity could be artificially inserted (maintained) in the media path (using e.g. conferencing capabilities) for the purpose of collecting DTMF, an “out of band“ transport mechanism would definitely provide a more efficient solution. In the cont
31、ext of the present document, “Out-of-band“ transport of DTMF should be understood as means to transport, outside the media path, signals representing key press stimuli. 4.2 Use cases The need for an “out of band“ transport mechanism has been identified in the framework of several services when advan
32、ced features are provided to the end users. Two examples are provided below. 1) Return to voicemail browsing after call back: The requirement appears when a user calls back the individual who left a message on a voicemail system and wishes to return to the top-level menu at the end of the call. The
33、user expresses willingness to return to the voicemail menu by pressing a DTMF key. This signal needs to be transported out-of-band from the user to the voicemail system, unless the voicemail system was kept in the media path during the call. 2) Address Book with Voice Activated Dialling: This type o
34、f service enables a user to use speech recognition to establish a call to a person or an organization registered in his address book. It generally provides users with the ability to request a follow-on call at the end of each call, usually by pressing a DTMF key. This signal needs to be transported
35、out-of-band from the user to the server hosting the address book, unless this system was kept in the media path during the call. The first use case can be further exemplified using the following sequence of events: 1) A user connects to its voicemail system, via an Application Server. 2) After liste
36、ning one of the new messages, the user requests the voicemail system (using inband DTMF) to establish a call to the person who left this message. 3) The voicemail system interacts with the Application Server to get this call established. 4) The AS releases the current call leg to the voicemail syste
37、m and establishes a call leg to the new party. 5) A call is established between the calling party and the person who left the message on the mailbox. 6) At the end of this call, the calling party wishes to listen to subsequent messages left on the mailbox and enters a DTMF sequence. When Step 6 is r
38、eached, the voicemail system is no longer in the media path and therefore cannot receive a request expressed in the form of an inband DTMF (RFC 2833 i.2 or G.711 Waves). 5 Needs As touched in the previous sections, a palliative solution to support such services would be to maintain the intermediate
39、entity (e.g. the voicemail system) in the media path. However, this would obviously be to the detriment of its processing capacity or cost. Therefore, there is a need for a transport mechanism enabling conveying, out-of-band, a sequence of DTMF signals from a service request or to an application cap
40、able of interpreting the DTMF sequence. This application may then decide to bring the intermediate entity back in the media path for running additional user interaction procedures. This requirement may be found in association with three different call configurations, all of which need to be taken in
41、to account in the design of a solution: - Both the sender and the receiver of the DTMF are attached to the IMS (e.g. the sender is a UE, while the receiver is an AS, an MRF and/or another UE). - The sender is attached to the IMS (e.g. the sender is a UE) while the receiver is located in another type
42、 of network (e.g. PSTN or H.323). ETSI ETSI TR 183 057 V2.1.1 (2008-07) 8 - The receiver is attached to the IMS (e.g. the receiver is an AS, an MRF or a UE) while the sender is located in another type of network (e.g. PSTN or H.323). Moreover, a solution to support the above use cases should not dis
43、rupt other services that use DTMF for different purposes. In particular DTMF sequences that are sent to an intermediary service should not be received by peer media entities (e.g. if a user engaged in an in-band interaction with an IVR receives an incoming call and presses a key to reject it, the co
44、rresponding DTMF signal should not be sent to the IVR). 6 Overview of technical solutions 6.1 General Two broad categories of solutions can be identified, depending on whether DTMF signals are transported along the session signalling path or not. 6.2 DTMF transport along the session signalling path
45、This type of solution consists in sending DTMF in SIP messages so that they can be intercepted by any entity along the session signalling path (e.g. an Application Server). A well-known realization of this type of solution relies on the use of the INFO method (RFC 2976 i.3), where the DTMF signals a
46、re carried in the message body. However, it should be noted that the use of the INFO method for that purpose has been ruled out by the SIP community on several occasions (see archives of the SIPPING mailing list). This type of solution may be used as a single method to support the requirements of al
47、l types of services (i.e. any DTMF signal sent from a User Equipment is carried out-of-band) or be used in parallel with an in-band method. The latter approach assumes that the sequences to be reported out-of-band can be easily distinguished by the UE (i.e. using pre-configured patterns) from other
48、sequences that remain transmitted in-band. The INFO method, as it is currently specified, is not appropriate for such a need. An improvement would be to indicate in the initial INVITE request what type of body message of INFO is exactly required/supported (negotiation and subscription stage) and the
49、n to send the DTMF information in the body of an INFO request during the dialog (notification stage). There are currently some discussions at the IETF (i.9, i.10 and i.11) on updating the INFO method in order to carry Event Packages and to include a negotiation of supported Event Packages in the INVITE-initiated dialog. The INVITE request and its responses are used to indicate and negotiate supported Event Packages, thanks to two new headers: “Send-Event“ and “Recv-Event“. The INFO request indicates the specific Event Package it is assoc
