ATIS T1 TR 82-2003 SIP Network Operators Implementers Guide for Pre-Paid Calling Card with DTMF Detection at the PSTN-IP Gateway.pdf

1、 TECHNICAL REPORT T1.TR.82-2003 Technical Report on SIP Network Operators Implementers Guide for Pre-Paid Calling Card, with DTMF Detection at the PSTN-IP Gateway Prepared by T1S1.7 Working Group on Services, Architecture, and Control Problem Solvers to the Telecommunications Industry A Word from AT

2、IS and Committee T1 Established in February 1984, Committee T1 develops technical standards, reports and requirements regarding interoperability of telecommunications networks at interfaces with end-user systems, carriers, information and enhanced-service providers, and customer premises equipment (

3、CPE). Committee T1 is sponsored by ATIS and is accredited by ANSI. T1.TR.82-2003 Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Committee T1 is sponsored by the Alliance for Telecommunications Industry Solutions (ATIS) and accredited

4、 by the American National Standards Institute (ANSI). Copyright 2004 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publi

5、sher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. T1.TR.82-2003 Technical Report on SIP Network Operators Implementers Guide for Pre-Paid Calling Card, with DTMF Detection at the PSTN-IP Gateway Secretariat Alliance for Telecommunication

6、s Industry Solutions Approved September 2003 Abstract This document provides a solution for the implementation of a Pre-Paid Calling Card application in the IP domain for circuit switched originated calls. The SUBSCRIBE and NOTIFY requests are used to request DTMF monitoring and notification of dete

7、ction in order to enable caller-initiated re-origination request while a call is in progress. T1.TR.82-2003 Foreword This document is entitled SIP Network Operators Implementers Guide for Pre-Paid Calling Card, with DTMF Detection at the PSTN-IP Gateway. Suggestions for improvement of this report wi

8、ll be welcome. These should be sent to the Alliance for Telecommunications Industry Solutions, T1 Secretariat, 1200 G Street, NW, Suite 500, Washington DC 20005. This Technical Report was processed and approved by the Accredited Standards Committee Telecommunications, T1. Committee approval of this

9、Technical Report does not necessarily imply that all committee members voted for its approval. Working Group T1S1.7 on Services, Architecture and Control of the Technical Subcommittee T1S1 on Services, Architectures, and Signaling was responsible for the development of this standard, and had the fol

10、lowing members: Martin Dolly, T1S1.7 Chair Joe Zebarth, T1S1.7 Vice Chair Martin Dolly, Fidencio Chaidez, Wesley Hicks, Robert Pugh, T1S1 Editors Ken Bender Ken Biholar Scott Brim Sergio Catanzariti Charles Cathey Fidencio Chaidez Janey Cheu Durai Chinnaiah Yogesh Dave Martin Dolly Wesley Downum Chu

11、ck Dvorak Brian Foster Taichi Fu Stuart Goldman Robert J Hall Michael Hammer Wesley Hicks Ndiata KalonJi Rajiv Kapoor Keith Mainwaring Jim McEachern Steve M Mills Robert Pugh Akber Qureshi Greg Ratta Susana Sabater Niranjan Sandesara Neal Seitz Viqar Shaikh Steve Showell Ray P Singh Bruce Thompson J

12、ean Trakinat Rajendra P Udeshi Tom Walsh Joe Zebarth ii T1.TR.82-2003 Table of Contents 1 SCOPE 1 1.1 SERVICE REQUIREMENTS1 1.2 HIGH LEVEL REQUIREMENTS .1 1.3 SECURITY CONSIDERATIONS .1 2 REFERENCES 2 3 DEFINITIONS 2 3.1 NETWORK ARCHITECTURE 2 4 ABBREVIATIONS all users of this Technical Report are t

13、herefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. 1 IETF RFC 3261, SIP: Session Initiation Protocol.22 IETF RFC 2327, SDP: Session Description Protocol.23 IETF RFC 1890, RTP Profile for Audio and Video Con

14、ferences with Minimal Control.24 IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.25 IETF RFC 3264, An Offer/Answer Model with SDP.26 IETF RFC 3262, Reliability of Provisional Responses in SIP.27 IETF RFC 2833, RTP Payload for DTMF Digits, Telephony Tones, and Teleph

15、ony Signals.28 IETF RFC 3265, SIP- Specific Event Notification.23 Definitions 3.1 Network Architecture The network architecture considered for this functionality assumes that the service network elements - represented by Application Server (AS) and Media Server (MS) - are connected via an IP network

16、 represented by the Common Back Bone (CBB). As the majority of the originations and terminations exist in the PSTN (EO, Class 4, or PBX), the card services are interconnected to the PSTN via one or more Network Gateway Switch (NGS) elements that translate both signaling and bearer interfaces between

17、 the PSTN and IP network. The NGS contains two functional elements: 1) a Call Control Element (CCE), which processes signaling; and 2) a Network Gateway Border Element (NGBE), which processes the bearer path. To route calls internal to the CCB, the Network Redirect Element (NRE) receives all initial

18、 invites in order to properly direct signaling to the next entity in the call signaling path. In initial implementations, the vast majority of the traffic will traverse the NGS in route to and from the PPC services; however as the number of IP endpoints grow, there are no limitations in the architec

19、ture that would limit originations and terminations to these endpoints. 2This document is available from the Internet Engineering Task Force (IETF). 2 T1.TR.82-2003 Figure 1 - Network Architecture and Protocol Relationships 4 Abbreviations tag= From: ;tag= CSeq: SUBSCRIBE Event: telephone-event;dura

20、tion;events=;id= Expires: Content-Type: audio/telephone-event Content-Length: 0 4 T1.TR.82-2003 Where: is an optional parameter that defines the duration of a continuous DTMF tone (in milliseconds) that will cause the CCE to send a NOTIFY request before detecting the end of the tone. A NOTIFY reques

21、t is always sent when the CCE detects the end of the key press, but additional NOTIFY requests will be sent during the key press if the tone persists for the value of beyond the time that the previous NOTIFY was sent. For long key presses, combined with short values of , a single DTMF digit can resu

22、lt in many NOTIFY requests. With calling card re-origination requests, in particular, the AS cannot provide a prompt for a new destination number or begin collecting digits if the caller is still pressing a DTMF key, so the AS must wait for completion of the tone. Therefore, it is likely that sendin

23、g NOTIFY requests at the termination of each detected DTMF digit is preferable to sending many NOTIFY requests for each digit. As a result, it is recommended that the AS not include the parameter, and that the CCE ignore the value of the parameter if it is received and just return a single NOTIFY at

24、 the conclusion of each DTMF tone. is the set of events that are to be detected by the CCE. For DTMF tones, the set includes: Digits 0 through 9 (decimal 0-9); The * key (decimal 10); The # key (decimal 11); Special digits A through D (decimal 12-15); and Flash (decimal 16). As described in clause 6

25、.2, the CCE will report each detected DTMF digit as a discrete event and it is the responsibility of the AS to reconstruct the sequence of digits into a string. As a result, the CCE should report all DTMF digits (with the possible exception of Flash), not just one or two specific DTMF values. The “e

26、vent“ parameter is optional, and if not included in the SUBSCRIBE request will be assumed to be the default set of decimal values 0-15 (i.e., all DTMF digits except for Flash). is an optional value that uniquely differentiates the subscription from all other active subscriptions for the same call. I

27、f an AS will not use more than one subscription per call, there is no need to use this parameter. If an AS plans to request more than one subscription, then this parameter must be used. defines the requested length of time (in seconds) that the subscription shall remain active. If this length of tim

28、e violates rules defined by the CCE, the CCE may decide to use a shorter duration, but the CCE shall not extend the subscription beyond the requested duration. The specific duration that will be used by the CCE is reported in the “Expires“ parameter of a SIP “Subscription-State“ header in a NOTIFY r

29、equest. If the optional “Expires“ header is not included, the CCE shall use a CCE-defined default value (3600 seconds, for example). 5.2 SIP NOTIFY Request The CCE sends NOTIFY requests to the AS to report changes in the state of the subscription (e.g., successful subscription installation, changes

30、to subscription duration, and termination of subscriptions). The CCE also sends NOTIFY requests to the AS to report detection of the specific events that were defined in the SUBSCRIBE request. Upon receipt of a NOTIFY request, the AS responds with a SIP 200 OK. If the CCE does not receive a SIP 200

31、OK from the AS, the CCE will not resend the NOTIFY. Instead, the CCE will immediately terminate the subscription and send a NOTIFY to the AS that includes a SIP “Subscription-State“ header with a value of “terminated.“ When reporting detection of an event, the NOTIFY request will include DTMF inform

32、ation in the body of the message, using a four-byte RTP DTMF payload structure (defined in RFC 2833). 5 T1.TR.82-2003 Specifically, the NOTIFY will include the specific DTMF key (0-9, #, *, A-D); an indication that the tone has completed or not; the volume of the detected tone; and the duration of t

33、he tone. 5.2.1 SIP NOTIFY Protocol for Subscription State Change The following structure depicts a typical NOTIFY request that confirms activation of a subscription or reports a change to the subscription (e.g., confirms a refresh, confirms a cancellation requested by the AS, or reports a cancellati

34、on triggered on the CCE): NOTIFY sip: SIP/2.0 Call-Id: To: ;tag= From: ;tag= CSeq: NOTIFY Event: telephone-event;rate=1000;events=;id= Subscription-State: active;expires=;reason= Content-Type: audio/telephone-event Content-Length: 0 Where: is the set of events that will be detected by the CCE. Norma

35、lly, the event set will be identical to the event set received in the SUBSCRIBE request, but it is possible that the CCE can only honor a subset of the events that were requested, in which case the event set will include fewer DTMF digits than were received in the SUBSCRIBE. If an “events“ parameter

36、 was not received in the SIP “Event“ header of the SUBSCRIBE request, then the CCE will use the default set of DTMF digits 0-15, and the “events“ parameter does not need to be included in the confirming NOTIFY request. is an optional value that uniquely differentiates the subscription from all other

37、 active subscriptions for the same call. If an “id“ parameter was received in the SUBSCRIBE request, it will be included in all NOTIFY requests associated with that subscription. contains the remaining time that the subscription will be active (truncated to the nearest second). indicates the reason

38、for the subscription state change. This parameter is only included when the subscription is cancelled; it is not included for duration refresh or initial subscription installation. Valid values include: noresource: Used when the caller hangs up. timeout: Used when the subscription duration expires o

39、n the CCE, or when the AS sends a request to cancel the subscription (using a SUBSCRIBE request with SIP “Expires“ header of value 0). 5.2.2 SIP NOTIFY Protocol for Reporting a DTMF Event The following structure depicts a typical NOTIFY request that reports the detection of a DTMF event: NOTIFY sip:

40、 SIP/2.0 Call-Id: To: ;tag= From: ;tag= CSeq: NOTIFY Event: telephone-event;rate=1000;events=;id= Subscription-State: active;expires= Content-Type: audio/telephone-event Content-Length: 4 : 6 T1.TR.82-2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-

41、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: is the set of events that will be detected by the CCE (see the description of in the confirming NOTIFY description, above). is an optional value that

42、 uniquely differentiates the subscription from all other active subscriptions for the same call. If an “id“ parameter was received in the SUBSCRIBE request, it will be included in all NOTIFY requests associated with that subscription. contains the remaining time that the subscription will be active

43、(truncated to the nearest second). is the specific DTMF digit that was detected, encoded in binary as follow: DTMF digit decimal value binary encoding 0-9 0-9 00000000 - 00001001 * 10 00001010 # 11 00001011A-D 12-15 00001100 - 00001111 Flash 16 00010000 indicates whether this NOTIFY is the final NOT

44、IFY for a specific tone. If this value is “1,“ then the NOTIFY request was sent at the conclusion of the DTMF tone. If this value is “0,“ then this NOTIFY was sent before the DTMF tone ended, and at least one more NOTIFY request will be sent for this same DTMF digit. is reserved for future use, and

45、will always be “0“ for now. reports the detected power level of the DTMF tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0, but the range of valid values for DTMF tones is 0 to -36 dBm0 (larger values denote lower volume). Since it is expected that most, if not a

46、ll, AS applications will not use volume as a criteria for acceptance or rejection of DTMF digits, it seems reasonable that a CCE could select a mid-level value (15, for example) that is always reported in NOTIFY requests. reports the duration of the DTMF tone, in timestamp units. At a sampling rate

47、of 1000 Hz, this field equates to a duration expressed in milliseconds and is sufficient to report event durations of up to 65.535 seconds. If the NOTIFY request was sent at the end of the DTMF tone, the value of will be the total duration of the tone. If the NOTIFY request was sent in the middle of

48、 a tone, the will be the total duration so far. 6 Signaling Procedures Call processing applications may require mid-call notification of DTMF keys for many reasons, and these applications may need single digits or complex sequences to trigger some behavior. In the case of Pre-Paid Calling Cards, a u

49、biquitous service is the ability for the caller to request another call without the need 7 T1.TR.82-2003 to hang up and redial the service access number and calling card number. In this clause, this service (called a “re-origination request“) is discussed in more detail. 6.1 Description of Re-Origination For the sake of discussion, we describe a re-Origination event as when the subscriber presses the “#” key twice in rapid succession. Other indications can be used to invoke re