PKT SP RSTF C01 140314

PacketCable™
Residential SIP Telephony Feature Specification
PKT-SP-RSTF-C01-140314
CLOSED
Notice
This PacketCable specification is the result of a cooperative effort
undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. You may download,
copy, distribute, and reference the documents herein only for the
purpose of developing products or services in accordance with such
documents, and educational use. Except as granted by CableLabs® in
a separate written license agreement, no license is granted to modify
the documents herein (except via the Engineering Change process), or
to use, copy, modify or distribute the documents for any other purpose.
This document may contain references to other documents not owned
or controlled by CableLabs. Use and understanding of this document
may require access to such other documents. Designing,
manufacturing, distributing, using, selling, or servicing products, or
providing services, based on this document may require intellectual
property licenses from third parties for technology referenced in this
document. To the extent this document contains or refers to documents
of third parties, you agree to abide by the terms of any licenses
associated with such third party documents, including open source
licenses, if any.
 Cable Television Laboratories, Inc. 2007-2014
PKT-SP-RSTF-C01-140314 PacketCable™
DISCLAIMER
This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation
or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular
purpose of this document, or any document referenced herein. Any use or reliance on the information or opinion in
this document is at the risk of the user, and CableLabs and its members shall not be liable for any damage or injury
incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained
in the document.
CableLabs reserves the right to revise this document for any reason including, but not limited to, changes in laws,
regulations, or standards promulgated by various entities, technology advances, or changes in equipment design,
manufacturing techniques, or operating procedures described, or referred to, herein.
This document is not to be construed to suggest that any affiliated company modify or change any of its products or
procedures, nor does this document represent a commitment by CableLabs or any of its members to purchase any
product whether or not it meets the characteristics described in the document. Unless granted in a separate written
agreement from CableLabs, nothing contained herein shall be construed to confer any license or right to any
intellectual property. This document is not to be construed as an endorsement of any product or company or as the
adoption or promulgation of any guidelines, standards, or recommendations.

ii CableLabs 03/14/14
Residential SIP Telephony Feature Specification PKT-SP-RSTF-C01-140314
Document Status Sheet
Document Control Number: PKT-SP-RSTF-C01-140314
Document Title: Residential SIP Telephony Feature Specification
Revision History: I01 - Released 9/27/06

I02 - Released 9/25/07
C01 - Released 3/14/14
Date: March 14, 2014
Status: Work in Draft Issued Closed

Progress
Distribution Restrictions: Author Only CL/Member CL/ Member/ Public

Vendor
Key to Document Status Codes
Work in Progress An incomplete document, designed to guide discussion and generate feedback,
that may include several alternative requirements for consideration.
Draft A document in specification format considered largely complete, but lacking

review by Members and vendors. Drafts are susceptible to substantial change
during the review process.
Issued A stable document, which has undergone rigorous member and vendor review
and is suitable for product design and development, cross-vendor interoperability,
and for certification testing.
Closed A static document, reviewed, tested, validated, and closed to further engineering
change requests to the specification through CableLabs.
Trademarks
CableLabs® is a registered trademark of Cable Television Laboratories, Inc. Other CableLabs marks are listed at
http://www.cablelabs.com/certqual/trademarks. All other marks are the property of their respective owners.

03/14/14 CableLabs iii
Contents
1 SCOPE ..................................................................................................................................................................1
1.1 Introduction and Purpose ...............................................................................................................................1
1.2 Requirements .................................................................................................................................................1
2 REFERENCES ....................................................................................................................................................2
2.1 Normative References....................................................................................................................................2
2.2 Informative References ..................................................................................................................................4
2.3 Reference Acquisition....................................................................................................................................5
3 TERMS AND DEFINITIONS ............................................................................................................................7
4 ABBREVIATIONS AND ACRONYMS ............................................................................................................9
5 OVERVIEW....................................................................................................................................................... 11
5.1 PacketCable Design Considerations for Residential SIP Telephony ........................................................... 11
5.2 Residential SIP Telephony Specific Applications ....................................................................................... 11
5.3 Functional Components for Residential SIP Telephony .............................................................................. 12
5.4 Protocol Interfaces for Residential SIP Telephony ...................................................................................... 12
6 NORMATIVE REFERENCE APPLICATION .............................................................................................. 13
6.1 Adaptations of [PKT 24.229]....................................................................................................................... 13
6.2 Additional IETF Requirements Based on Specific IETF RFCs and Internet-Drafts ................................... 13
7 RESIDENTIAL SIP TELEPHONY FEATURE REQUIREMENTS ........................................................... 15
7.1 Basic Calling Capabilities ............................................................................................................................ 15
7.1.1 Digit Maps ........................................................................................................................................... 15
7.1.2 Vertical Service Codes ......................................................................................................................... 21
7.1.3 Addressing and Dial String Entry ........................................................................................................ 23
7.1.4 Basic Call Signaling ............................................................................................................................ 23
7.1.5 Held Media .......................................................................................................................................... 31
7.1.6 Announcements .................................................................................................................................... 37
7.1.7 In-Service and Out-of-Service States ................................................................................................... 52
7.1.8 UE Status Change ................................................................................................................................ 53
7.1.9 Early Media ......................................................................................................................................... 54
7.1.10 No Answer Timeout.............................................................................................................................. 58
7.1.11 Response Codes ................................................................................................................................... 59
7.1.12 Feature State Synchronization between Application Server and User Equipment .............................. 59
7.1.13 IPv6 Support ........................................................................................................................................ 61
7.1.14 DSCP for Non-Emergency Signaling................................................................................................... 62
7.1.15 Operator Specific Features .................................................................................................................. 62
7.1.16 Event for Registrations ........................................................................................................................ 62
7.2 Caller ID ...................................................................................................................................................... 63
7.2.1 Caller ID Presentation......................................................................................................................... 63
7.2.2 Caller ID Display ................................................................................................................................ 66
7.2.3 Caller ID Per-Line Blocking................................................................................................................ 68
7.2.4 Caller ID Per-Call Blocking (CIDS-Suppression)............................................................................... 69
7.2.5 Caller ID Per-Call Delivery (CIDS-Delivery) ..................................................................................... 71
7.2.6 Caller ID with Call Waiting (CIDCW) ................................................................................................ 73
7.2.7 Anonymous Call Rejection ................................................................................................................... 73
7.2.8 MGC Considerations ........................................................................................................................... 77
7.2.9 Caller-ID Per Call Toggle ................................................................................................................... 77
7.3 Call Forwarding ........................................................................................................................................... 79
7.3.1 Overview .............................................................................................................................................. 79

iv CableLabs 03/14/14
7.3.2 Call Forwarding Variable ................................................................................................................... 83

7.3.3 Call Forwarding Don't Answer ........................................................................................................... 93
7.3.4 Call Forwarding on Busy .................................................................................................................... 97
7.3.5 Selective Call Forwarding ................................................................................................................... 99
7.3.6 Remote Activation of Call Forwarding .............................................................................................. 103
7.3.7 Call Forwarding to Voice Mail.......................................................................................................... 104
7.4 Call Blocking Features............................................................................................................................... 105
7.4.1 Outbound Call Blocking .................................................................................................................... 105
7.4.2 Collect Call Blocking ......................................................................................................................... 110
7.4.3 Solicitor Blocking .............................................................................................................................. 111
7.5 Multi-Party Features .................................................................................................................................. 116
7.5.1 Hook Flash Processing ...................................................................................................................... 116
7.5.2 Call Waiting ....................................................................................................................................... 117
7.5.3 Hold ................................................................................................................................................... 120
7.5.4 Call Transfer ...................................................................................................................................... 125
7.5.5 Three-Way Calling ............................................................................................................................. 131
7.6 Miscellaneous Features .............................................................................................................................. 136
7.6.1 Do Not Disturb .................................................................................................................................. 136
7.6.2 Subscriber Programmable PIN.......................................................................................................... 144
7.6.3 Distinctive Alerting ............................................................................................................................ 147
7.6.4 Message Waiting Indicators .............................................................................................................. 151
7.6.5 Speed Dialing..................................................................................................................................... 155
7.6.6 Customer-Originated Call Trace ....................................................................................................... 160
7.6.7 Screening List Editing ........................................................................................................................ 162
7.6.8 Network-Based Call Screening .......................................................................................................... 162
7.6.9 Hotline ............................................................................................................................................... 168
7.7 Call History Features ................................................................................................................................. 171
7.7.1 Auto Recall......................................................................................................................................... 171
7.7.2 Auto Callback .................................................................................................................................... 181
7.8 Operator Services....................................................................................................................................... 184
7.8.1 Busy Line Verification ....................................................................................................................... 185
7.8.2 Operator Interrupt ............................................................................................................................. 188
7.8.3 Call Completion ................................................................................................................................. 188
8 EMERGENCY SERVICES ............................................................................................................................ 189
8.1 Overview of NENA E9-1-1 VoIP Migration Phases ................................................................................. 189
8.2 Scope ......................................................................................................................................................... 189
8.3 Assumptions .............................................................................................................................................. 189
8.4 Emergency Call Handling .......................................................................................................................... 190
8.5 UE Requirements for Emergency Services Support .................................................................................. 192
8.5.1 Minimum UE State to Place Emergency Calls .................................................................................. 192
8.5.2 Emergency Calling Configuration ..................................................................................................... 192
8.5.3 Obtain Location ................................................................................................................................. 192
8.5.4 Recognition of an UE-Originated Emergency Call ........................................................................... 193
8.5.5 Basic Call Modifications while on an Emergency Call ..................................................................... 193
8.5.6 PSAP Operator RingBack .................................................................................................................. 197
8.5.7 PSAP CallBack (PSAP Originated Emergency Call) ........................................................................ 198
8.5.8 Feature Interactions .......................................................................................................................... 199
8.5.9 Signaling Identification of an Emergency Call .................................................................................. 201
8.5.10 QoS for an Emergency Call ............................................................................................................... 202
8.5.11 Other UE Requirements ..................................................................................................................... 202
8.5.12 Emergency Services Feature Data..................................................................................................... 202
8.6 P-CSCF Requirements ............................................................................................................................... 202
8.6.1 Recognition of UE-Originated Emergency Call ................................................................................ 202
8.6.2 Forwarding the call to an E-CSCF .................................................................................................... 203
8.6.3 Handling of Network-Initiated De-Registration during Emergency Calls......................................... 203

03/14/14 CableLabs v
8.7 E-CSCF Requirements ............................................................................................................................... 203

8.7.1 Emergency Call Routing in the NENA i3 Architecture ...................................................................... 203
8.7.3 Emergency Call Routing in NENA Pre-i2.......................................................................................... 204
8.8 MGC, SG and MG Requirements .............................................................................................................. 205
8.8.1 Emergency Call Routing in NENA i3................................................................................................. 205
8.8.2 Emergency Call Routing in NENA i2................................................................................................. 205
8.8.3 Emergency Call Routing in NENA Pre-i2.......................................................................................... 205
ANNEX A DIGIT MAP SYNTAX (NORMATIVE) ....................................................................................... 206
APPENDIX I ACKNOWLEDGEMENTS ........................................................................................................ 208
APPENDIX II REVISION HISTORY ............................................................................................................ 209
Figures
FIGURE 1 - BASIC CALL - ON-NET TO ON-NET ............................................................................................................. 28
FIGURE 2 - BASIC CALL - ON-NET TO ON-NET NO ANSWER ........................................................................................ 29
FIGURE 3 - BASIC CALL - ON-NET TO ON-NET BUSY, CALL WAITING NOT APPLIED .................................................. 29
FIGURE 4 - BASIC CALL - ON-NET TO PSTN OFF-NET ................................................................................................. 30
FIGURE 5 - BASIC CALL - PSTN OFF-NET TO ON-NET ................................................................................................. 31
FIGURE 6 - SAMPLE HELD MEDIA MESSAGE FLOW ...................................................................................................... 34
FIGURE 7 - SAMPLE HELD MEDIA MESSAGE FLOW - IPV4 MODE UE FALLBACK TO RFC2543 DEFINED HOLD .......... 35
FIGURE 8 - SAMPLE HELD MEDIA MESSAGE FLOW - RETRIEVAL OF HELD MEDIA ...................................................... 35
FIGURE 9 - HELD MEDIA - TRANSITION TO DUAL-HOLD .............................................................................................. 36
FIGURE 10 - HELD MEDIA - RETRIEVAL BY ONE PARTY WHEN IN DUAL-HOLD........................................................... 36
FIGURE 11 - ANNOUNCEMENT MEDIA MAPPING .......................................................................................................... 40
FIGURE 12 - MEDIA SERVING - UE INVITE FOR NETWORK ANNOUNCEMENT............................................................. 47
FIGURE 13 - MEDIA SERVING - SERVER REDIRECTING UE ........................................................................................... 48
FIGURE 14 - MEDIA SERVING - SERVER PROVIDING ANNOUNCEMENT WITH EARLY MEDIA ........................................ 49
FIGURE 15 - MEDIA SERVING - NETWORK ANNOUNCEMENT BY RE-INVITE FROM SIP NETWORK ............................. 50
FIGURE 16 - MEDIA SERVING - UE INVITE FOR NETWORK ANNOUNCEMENT WITH LANGUAGE PREFERENCE............ 51
FIGURE 17 - FUNCTIONAL COMPONENTS FOR DETERMINING IN-SERVICE/OUT-OF-SERVICE STATE ............................ 52
FIGURE 18 - EARLY MEDIA FROM TERMINATING PARTY............................................................................................... 56
FIGURE 19 - EARLY MEDIA FROM INTERMEDIATE PARTY ............................................................................................. 57
FIGURE 20 - EARLY MEDIA - PSTN ORIGINATION ....................................................................................................... 57
FIGURE 21 - ANONYMOUS CALLER REJECTION (ACR) - ACTIVATION/DEACTIVATION ................................................. 76
FIGURE 22 - ACR - ORIGINATOR HAS A RESTRICTED IDENTITY .................................................................................... 77
FIGURE 23 - MULTIPLE FORWARDING SCENARIO ......................................................................................................... 81
FIGURE 24 - CALL FORWARDING VARIABLE (CFV) - ACTIVATION WITH USER-PROVIDED ADDRESS .......................... 88
FIGURE 25 - CFV - ACTIVATION WITH USER-PROVIDED ADDRESS - NO ANSWER AT FWD-TO ADDRESS ..................... 89
FIGURE 26 - CFV - ACTIVATION WITH USER-PROVIDED ADDRESS - SECOND ATTEMPT WITHIN TWO MINUTES TO THE
SAME ADDRESS .................................................................................................................................................... 90
FIGURE 27 - CFV - ACTIVATION TO A FIXED NUMBER ................................................................................................. 91
FIGURE 28 - CFV - DEACTIVATION .............................................................................................................................. 92
FIGURE 29 - CFV - FORWARDED CALL......................................................................................................................... 93
FIGURE 30 - CALL FORWARD DO NOT ANSWER (CFDA) - ESTABLISHMENT DUE TO NO ANSWER TIMEOUT .............. 96
FIGURE 31 - CFDA - ESTABLISHMENT DUE TO SIP RESPONSE TIMEOUT ..................................................................... 97
FIGURE 32 - CALL FORWARD BUSY LINE (CFBL) - ESTABLISHMENT .......................................................................... 99
FIGURE 33 - SELECTIVE CALL FORWARDING (SCF) - FORWARDED CALL .................................................................. 103
FIGURE 34 - OUTBOUND CALL BLOCKING (OCB) - FEATURE FUNCTION WHILE DEACTIVATED................................ 107
FIGURE 35 - OCB - INVALID OVERRIDE PIN ENTRY .................................................................................................. 108
FIGURE 36 - OCB - VALID OVERRIDE PIN ENTRY ..................................................................................................... 109

vi CableLabs 03/14/14
FIGURE 37 - OCB - OVERRIDE PIN SERVICE NOT ENABLED ...................................................................................... 110

FIGURE 38 - SOLICITOR BLOCKING (SB) - CALLED PARTY ACCEPTS THE CALLER ..................................................... 114
FIGURE 39 - SB - CALLED PARTY REJECTS THE CALLER OR FAILS TO RESPOND TO THE IVR .................................... 115
FIGURE 40 - SB - CALLING PARTY FAILS TO ENTER A GREETING............................................................................... 116
FIGURE 41 - CALL WAITING (CWT) - ANSWERING A SECOND CALL .......................................................................... 120
FIGURE 42 - NETWORK HOLD - HOLD AND RETRIEVE ................................................................................................ 123
FIGURE 43 - NETWORK HOLD - SECOND CALL ATTEMPT FAILED............................................................................... 124
FIGURE 44 - NETWORK HOLD - CONTROLLER GOES ON-HOOK.................................................................................. 124
FIGURE 45 - CALL TRANSFER (CXR) FEATURE FLOW, B TRANSFERS A TO C, NOT ALL USER INPUTS ARE SHOWN FOR
A ........................................................................................................................................................................ 126
FIGURE 46 - CXR - B TRANSFERS A TO C (BLIND) USING REFER AFTER INITIAL INVITE BUT BEFORE C ANSWERS
........................................................................................................................................................................... 130
FIGURE 47 - CXR - B TRANSFERS A TO C (CONSULTATIVE) USING REFER AFTER ESTABLISHING THE CALL TO C
WITH INVITE ..................................................................................................................................................... 131
FIGURE 48 - THREE-WAY CALL (3WC)...................................................................................................................... 134
FIGURE 49 - 3WC - CONTROLLER HANGS UP DURING 2ND CALL ATTEMPT ................................................................... 135
FIGURE 50 - 3WC - CONTROLLER FLASHES THE HOOK TO DISCONNECT THIRD PARTY IN A 3WC............................. 136
FIGURE 51 - 3WC - CONTROLLER DISCONNECTS THE 3WC ....................................................................................... 136
FIGURE 52 - DO NOT DISTURB (DND) - DEACTIVATED ............................................................................................. 140
FIGURE 53 - DND - OVERRIDE/EXEMPT PRIVILEGE ................................................................................................... 141
FIGURE 54 - DND - INVALID OVERRIDE PIN .............................................................................................................. 142
FIGURE 55 - DND - VALID OVERRIDE PIN ................................................................................................................. 143
FIGURE 56 - SUBSCRIBER PROGRAMMABLE PIN (SPP) .............................................................................................. 146
FIGURE 57 - DISTINCTIVE ALERTING (DA) - DISTINCTIVE RINGING ........................................................................... 150
FIGURE 58 - DA - DISTINCTIVE CALL WAITING........................................................................................................... 151
FIGURE 59 - MESSAGE WAITING INDICATOR (MWI) - SUCCESSFUL SUBSCRIPTION AUTHORIZATION ........................ 153
FIGURE 60 - MWI - FAILED SUBSCRIPTION AUTHORIZATION ...................................................................................... 154
FIGURE 61 - MWI - MESSAGE ACCOUNT STATUS CHANGE ......................................................................................... 155
FIGURE 62 - SPEED DIALING (SD) .............................................................................................................................. 158
FIGURE 63 - SD - FAILED AUTHORIZATION ................................................................................................................. 159
FIGURE 64 - SD - NO MAPPING .................................................................................................................................. 159
FIGURE 65 - COT - COLLECTION OF TRACING INFORMATION WHEN CALLER'S IDENTITY IS RESTRICTED .................... 162
FIGURE 66 - A LEAVES MESSAGE WHILE B SCREENS CALL.......................................................................................... 167
FIGURE 67 - AUTOMATIC RECALL (AR) - TARGET NOT ANONYMOUS ........................................................................ 178
FIGURE 68 - AR - ANONYMOUS TARGET IS BUSY........................................................................................................ 179
FIGURE 69 - AR - ANONYMOUS TARGET BECOMES IDLE ............................................................................................. 180
FIGURE 70 - BUSY LINE VERIFY (BLV) ...................................................................................................................... 187
FIGURE 71 - EMERGENCY CALL.................................................................................................................................. 194
FIGURE 72 - EMERGENCY CALL - USER DISCONNECT HANDLING................................................................................ 196
FIGURE 73 - EMERGENCY CALL - RECONNECTING AFTER HOLD ................................................................................. 197
FIGURE 74 - EMERGENCY CALL - PSAP OPERATOR RINGBACK WHILE ON HOLD ........................................................ 198
FIGURE 75 - EMERGENCY CALL - PSAP OPERATOR CALLBACK .................................................................................. 199
Tables
TABLE 1 - DIGIT MAP ACTIONS .................................................................................................................................... 21
TABLE 2 - FEATURES THAT ARE CONFIGURABLE THROUGH THE DIGIT MAP ................................................................ 22
TABLE 3 - ACTIONS AT CALLING UE UPON RECEIPT OF AN 18X MESSAGE .................................................................. 24
TABLE 4 - BASIC CALL FEATURE DATA ....................................................................................................................... 27
TABLE 5 - HELD MEDIA FEATURE DATA ...................................................................................................................... 33
TABLE 6 - TONE ANNOUNCEMENT IDENTIFIERS ........................................................................................................... 38
TABLE 7 - AUDIO ANNOUNCEMENT IDENTIFIERS ......................................................................................................... 39
TABLE 8 - ANNOUNCEMENT MAP - DEFAULT SIP RESPONSE CODE MAPPING ............................................................. 40
TABLE 9 - ANNOUNCEMENT FEATURE DATA ............................................................................................................... 43
TABLE 10 - LOCAL MEDIA ............................................................................................................................................ 43

03/14/14 CableLabs vii
TABLE 11 - UE ANNOUNCEMENT LANGUAGE PREFERENCE FEATURE DATA ............................................................... 45

TABLE 12 - IN-SERVICE/OUT-OF-SERVICE FEATURE DATA ........................................................................................... 53
TABLE 13 - UE STATUS CHANGE FEATURE DATA ........................................................................................................ 54
TABLE 14 - NO ANSWER TIMEOUT FEATURE DATA ..................................................................................................... 58
TABLE 15 - RESPONSE CODES ...................................................................................................................................... 59
TABLE 16 - DSCP FOR NON-EMERGENCY SIGNALING ................................................................................................. 62
TABLE 17 - OPERATOR SPECIFIC FEATURES DATA ....................................................................................................... 62
TABLE 18 - P-ASSERTED-IDENTITY HEADER SELECTION ............................................................................................. 64
TABLE 19 - EFFECTS OF PER-CALL BLOCKING FEATURES ON PRESENTATION STATUS ................................................ 65
TABLE 20 - CALLER ID FEATURE DATA ....................................................................................................................... 66
TABLE 21 - CALLER ID DISPLAY FEATURE DATA ........................................................................................................ 68
TABLE 22 - CALLER ID PER-CALL BLOCKING FEATURE DATA .................................................................................... 70
TABLE 23 - CALLER ID PER-CALL DELIVERY FEATURE DATA..................................................................................... 72
TABLE 24 - ACR FEATURE DATA ................................................................................................................................. 74
TABLE 25 - PARAMETERS AND HEADER FIELDS THAT ARE MODIFIED IN A CF AS ...................................................... 82
TABLE 26 - CALL FORWARDING VARIABLE FEATURE DATA ........................................................................................ 85
TABLE 27 - CALL FORWARDING VARIABLE UA-PROFILE EVENT PACKAGE DATA ELEMENTS .................................... 86
TABLE 28 - CALL FORWARDING DON'T ANSWER FEATURE DATA................................................................................ 94
TABLE 29 - CALL FORWARDING BUSY LINE FEATURE DATA ....................................................................................... 98
TABLE 30 - SCF FEATURE DATA ................................................................................................................................ 101
TABLE 31 - SELECTIVE CALL FORWARDING UA-PROFILE EVENT PACKAGE DATA ELEMENTS .................................. 102
TABLE 32 - REMOTE ACTIVATION OF CALL FORWARDING FEATURE DATA ............................................................... 104
TABLE 33 - OUTBOUND CALL BLOCKING FEATURE DATA ......................................................................................... 106
TABLE 34 - SOLICITOR BLOCKING FEATURE DATA .................................................................................................... 113
TABLE 35 - CALL WAITING FEATURE DATA............................................................................................................... 118
TABLE 36 - CALL HOLD FEATURE DATA .................................................................................................................... 122
TABLE 37 - CALL TRANSFER FEATURE DATA............................................................................................................. 129
TABLE 38 - 3WC FEATURE DATA .............................................................................................................................. 133
TABLE 39 - DND FEATURE DATA .............................................................................................................................. 139
TABLE 40 - DO NOT DISTURB UA-PROFILE EVENT PACKAGE DATA ELEMENTS ....................................................... 139
TABLE 41 - SUBSCRIBER PROGRAMMABLE PIN FEATURE DATA ................................................................................ 145
TABLE 42 - DISTINCTIVE ALERTING FEATURE DATA ................................................................................................. 148
TABLE 43 - DISTINCTIVE TONES FOR CALL WAITING ................................................................................................. 149
TABLE 44 - MWI FEATURE DATA .............................................................................................................................. 153
TABLE 45 - SPEED DIALING FEATURE DATA .............................................................................................................. 157
TABLE 46 - CUSTOMER ORIGINATED TRACE FEATURE DATA .................................................................................... 161
TABLE 47 - NETWORK-BASED CALL SCREENING FEATURE DATA ............................................................................. 165
TABLE 48 - HOTLINE FEATURE DATA ........................................................................................................................ 168
TABLE 49 - EFFECTS OF PER-CALL PRESENTATION FEATURES ON PRESENTATION STATUS FOR AUTO RECALL ........ 172
TABLE 50 - AUTO RECALL FEATURE DATA ................................................................................................................ 176
TABLE 51 - EFFECTS OF PER-CALL PRESENTATION FEATURES ON PRESENTATION STATUS FOR AUTO CALLBACK.... 182
TABLE 52 - AUTO CALLBACK FEATURE DATA ........................................................................................................... 183
TABLE 53 - BUSY LINE VERIFY FEATURE DATA......................................................................................................... 186
TABLE 54 - EMERGENCY SERVICES FEATURE DATA .................................................................................................. 202

viii CableLabs 03/14/14
1 SCOPE
1.1 Introduction and Purpose
This document specifies an implementation of common residential telephony features in a PacketCable network
with SIP based User Equipment (UEs). These features include the most commonly used residential features and
capabilities, including Caller ID features, call forwarding features, hold, transfer, three-way calling, emergency
calling, and operator services.
The PacketCable network architecture uses the Session Initiation Protocol (SIP) as the basis for call setup and
teardown. SIP was designed to permit distribution of feature logic to the network endpoints, requiring less
processing in network elements, and theoretically permitting a reduction in cost of network infrastructure. Also, SIP
was designed to support a wide range of interactive applications, including telephony, video conferencing,
interactive messaging, presence, wireless services, and many others. Lastly, SIP is the foundation of the IP
Multimedia Subsystem (IMS) architecture, upon which the PacketCable architecture is based. Many telecom
equipment and software suppliers are focusing their investments in converged network solutions on the IMS
architecture, and the PacketCable architecture leverages the IMS architecture, which should yield more rapid
implementation timeframes.
This initial Residential SIP Telephony Feature Specification defines the Layer 3 and higher network requirements
and signaling to enable User Equipment (UE) to establish services to emulate historical analog telephony services
and features.
1.2 Requirements
Throughout this document, the words that are used to define the significance of particular requirements are
capitalized. These words are:
"MUST" This word means that the item is an absolute requirement of this specification.
"MUST NOT" This phrase means that the item is an absolute prohibition of this specification.
"SHOULD" This word means that there may exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case carefully weighed before
choosing a different course.
"SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the
listed behavior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with this label.
"MAY" This word means that this item is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it enhances the product, for example;
another vendor may omit the same item.

03/14/14 CableLabs 1
2 REFERENCES
2.1 Normative References
In order to claim compliance with this specification, it is necessary to conform to the normative requirements within
the following standards and other works as indicated. This is in addition to the other requirements of this
specification. Notwithstanding, intellectual property rights may be required to use or implement such normative
references.
[BR 780] Telcordia BR 780-200-020 Tones and Announcements Issue Number 09, October 2000.
[CODEC- PacketCable Codec and Media Specification, PKT-SP-CODEC-MEDIA-C01-140314, March 14,
MEDIA] 2014, Cable Television Laboratories, Inc.
[EN 300 659-1] ETSI EN 300 659-1, Access and Terminals (AT); Analogue access to the Public Switched
Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related)
services; Part 1: On-hook data transmission, January 2001.
[EN 300 659-3] ETSI EN 300 659-3, Access and Terminals (AT); Analogue access to the Public Switched
Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related)
services; Part 3: Data link message and parameter codings, January 2001.
[GR 30] Telcordia GR-30-CORE, LSSGR: Voiceband Data Transmission Interface, December 1998, FR-
64.
[GR 31] Telcordia GR-31-CORE LSSGR: Calling Number Delivery, June, 2000, FSD-01-02-1051.
[GR 215] Telcordia GR-215, LSSGR: CLASS Feature: Automatic Callback (FSD 01-02-1250), April 2002,
FR-64.
[GR 216] Telcordia GR-216, LSSGR: CLASS Feature: Customer Originated Trace (FSD 01-02-1052) Issue
Number 02, April 2002, FR-64.
[GR 217] Telcordia GR-217, LSSGR: CLASS Feature: Selective Call Forwarding (FSD 01-02-1410), April
2002, FR-64.
[GR 220] Telcordia GR-220, LSSGR: CLASS Feature: Screening List Editing (FSD 30-28-0000), April
2002, FR-64.
[GR 227] Telcordia GR-227, LSSGR: CLASS Feature: Automatic Recall (FSD 01-02-1260), April 2002,
FR-64.
[GR 303] Telcordia GR-303, Integrated Digital Loop Carrier System Generic Requirements, Objectives,
and Interface, December 2000, FD-29, FR-440.
[GR 506] Telcordia GR-506, LSSGR: Signaling for Analog Interfaces, November, 1996, FR-64.
[GR 529] Telcordia GR-529 LSSGR: Public Safety (FSDs 15-01-0000, 15-03-0000, 15-07-0000), Issue 1,
June 2000.
[GR 531] Telcordia GR-531, LSSGR: Interoffice (FSDs 25-05-0903, 25-06-0501, 25-06-0502, 25-06-
0506), June 2000, FR-64.
[GR 567] Telcordia GR-567, LSSGR: CLASS Feature: Anonymous Call Rejection (FSD 01-02-1060), June
2000, FR-64.
[GR 570] Telcordia GR-570, LSSGR: Speed Calling (FSD 01-02-1101), June 2000, FR-64.
[GR 571] Telcordia GR-571, LSSGR: Call Waiting (FSD 01-02-1201), June 2000, FR-64.
[GR 577] Telcordia GR-577, LSSGR: Three-Way Calling (FSD 01-02-1301), June 2000, FR-64.
[GR 579] Telcordia GR-579, LSSGR: Add-On Transfer and Conference Calling Feature (FSD 01-02-1305),
June 2000, FR-64.
[GR 580] Telcordia GR-580, LSSGR: Call Forwarding Variable (FSD 01-02-1401), June 2000, FR-64.
[GR 586] Telcordia GR-586, LSSGR: Call Forwarding Subfeatures (FSD 01-02-1450), April 2002, FR-64.

2 CableLabs 03/14/14
[GR 1176] Telcordia GR-1176, March, 1999, OSSGR: Custom Call-Handling Features (FSD 80 Series), A
Module of OSSGR, April 1990, FR-271.
[GR 1188] Telcordia GR-1188, LSSGR: CLASS Feature: Calling Name Delivery Generic Requirements
(FSD 01-02-1070), December 2000, FR-64.
[GR 1277] Telcordia GR-1277, LSSGR: Operator Services: Switching System Generic Requirements Using
Integrated Services Digital Network User Part (ISUP), August 2001.
[GR 1401] Telcordia GR-1401, LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-
02-2000), June 2000, FR-64.
[GR 2948] Telcordia GR-2948-CORE Prompted Automatic Callback (FSD 01-02-1255) December 1996,
FR-64.
[GR 2956] Telcordia GR-2956, LSSGR: CCS SS7 Generic Requirements in Support of E9-1-1 Service,
December 2000.
[ID SIP-CFG] IETF Internet-Draft, A Framework for Session Initiation Protocol User Agent Profile Delivery,
draft-ietf-sipping-config-framework-18, October 2010, work in progress.
[ID SIP- IETF Internet-Draft, Location Conveyance for the Session Initiation Protocol, draft-ietf-sipcore-
CONVEY] location-conveyance-04, October 2010, work in progress.
[PKT 24.229] PacketCable Release Sip and SDP Stage 3 Specification 3GPP TS 24.229, PKT-SP-24.229-C01-
140314, March 14, 2014, Cable Television Laboratories, Inc.
[RFC 2543] IETF RFC 2543, SIP: Session Initiation Protocol, March 1999.
[RFC 3066] IETF RFC 3066, Tags for the Identification of Languages, January 2001.
[RFC 3261] IETF RFC 3261, SIP: Session Initiation Protocol, June 2002.
[RFC 3262] IETF RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP),
June 2002.
[RFC 3264] IETF RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP), June,
2002.
[RFC 3265] IETF RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, June 2002.
[RFC 3323] IETF RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP), November 2002.
[RFC 3325] IETF RFC 3325; Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks, November 2002.
[RFC 3389] IETF RFC Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN), September
2002.
[RFC 3515] IETF RFC 3515, The Session Initiation Protocol (SIP) Refer Method, April 2003.
[RFC 3825] IETF RFC 3825, Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information, July 2004.
[RFC 3842] IETF RFC 3842, A Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol (SIP), August 2004.
[RFC 3891] IETF RFC 3891, The Session Initiation Protocol (SIP) Replaces Header, September 2004.
[RFC 3892] IETF RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism, September 2004.
[RFC 3911] IETF RFC 3911, The Session Initiation Protocol (SIP) Join Header, October 2004.
[RFC 3959] IETF RFC 3959, The Early Session Disposition Type for the Session Initiation Protocol (SIP),
December, 2004.
[RFC 3966] IETF RFC 3966, The tel URI for Telephone Numbers, December, 2004.
[RFC 4119] IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, December 2005.
[RFC 4235] IETF RFC 4235, An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol
(SIP), November 2005.
[RFC 4240] IETF RFC 4240, Basic Network Media Services with SIP, December 2005.

[RFC 4244] IETF RFC 4244, An Extension to the Session Initiation Protocol (SIP) for Request History
Information, November 2005.
[RFC 4330] IETF RFC 4330, Simple Network Time Protocol version 4 for IPv6, IPv4, and OSI, January,
2006.
[RFC 4458] IETF RFC 4458, Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and
Interactive Voice Response (IVR), April 2006.
[RFC 4538] IETF RFC 4538, Request Authorization through Dialog Identification in the Session Initiation
Protocol (SIP), June 2006.
[RFC 4566] IETF RFC 4566, SDP: Session Description Protocol, July 2006.
[RFC 4676] IETF RFC 4676, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic
Addresses Configuration Information, October 2006.
[RFC 5031] IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services, January 2008.
[RFC 5079] IETF RFC 5079, Rejecting Anonymous Requests in the Session Initiation Protocol (SIP),
December 2007.
[RFC 5503] IETF RFC 5503, Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for
Supporting the PacketCable Distributed Call Signaling Architecture, March 2009.
[RFC 5626] IETF RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP),
October 2009.
[RFC 5627] IETF RFC 5627, Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the
Session Initiation Protocol (SIP), October 2009.
[SR-TSV- Telcordia Special Report, SR-TSV-002476, CPE Compatibility Considerations for the Voiceband
002476] Data Transmission Interface, December 1992.
2.2 Informative References

This specification uses the following informative references.
[ARCH-FRM TR] PacketCable Architecture Framework Technical Report, PKT-TR-ARCH-FRM-C01-140314,
March 14, 2014, Cable Television Laboratories, Inc.
[CMSS1.5] PacketCable CMS to CMS Signaling 1.5 Specification, PKT-SP-CMSS1.5-I07-120412, April
12, 2012, Cable Television Laboratories Inc.
[EG 201 188] ETSI EG 201 188, Public Switched Telephone Network (PSTN Network Termination Point
(NTP) analogue interface, January 2000.
[EN 300 001] ETSI EN 300 001, Attachments to the Public Switched Telephone Network (PSTN), October
1995.
[GR 219] Telcordia GR 219 CORE LSSGR: CLASS Feature: Distinctive Ringing/Call Waiting Issue
Number 02, April 2002, FR-64.
[GR 246] Telcordia Technologies Specification of Signalling System Number 7, December 2005.
[GR 391] Telcordia GR-391, LSSGR: CLASS Feature: Calling Identity Delivery Blocking Features
(FSD 01-02-1053), June 2000, FR-64.
[GR 572] Telcordia GR-572, LSSGR: Cancel Call Waiting (FSD 01-02-1204), June 2000, FR-64.
[GR 674] Telcordia GR-674-CORE LSSGR: Special Information Tones (FSD 20-06-0500), (TR-TSY-
000674), June 2000.
[GR 675] Telcordia GR-675-CORE LSSGR: Expanded Announcement System (FSD 20-06-0600) (TR-
TSY-00675), June 2000.

[NENA i2] NENA, Interim VoIP Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Issue 1
December 6, 2005.
http://www.nena.org/sites/default/files/08-001_20051205.pdf
[NENA i3] NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3), NENA
08-002, Version 1.0, December 18, 2007.
http://www.nena.org/sites/default/files/08-002%20V1%2020071218.pdf
[NFT TR] PacketCable NAT and Firewall Traversal Technical Report, PKT-TR-NFT-C01-140314,
March 14, 2014, Cable Television Laboratories, Inc.
[PKT 33.203] PacketCable Access Security for IP-Based Services Specification 3GPP TS 33.203, PKT-SP-
33.203-C01-140314, March 14, 2014, Cable Television Laboratories, Inc.
[QoS] PacketCable Quality of Service Specification, PKT-SP-QOS-C01-140314, March 14, 2014,
Cable Television Laboratories, Inc.
[RFC 2833] IETF RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony, May 2000.
[RFC 3315] IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), July 2003.
[RFC 3761] IETF RFC 3761, The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM), April 2004.
[RFC 3960] IETF RFC 3960, Early Media and Ringing Tone Generation in the Session Initiation Protocol
(SIP), December 2004.
[RFC 3986] IETF RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, January 2005.
[RFC 4234] IETF RFC 4234, Augmented BNF for Syntax Specifications, October, 2005.
[RFC 5222] IETF RFC 5222, Lost: A Location-to-Service Translation Protocol, August 2008.
[RFC 5245] IETF RFC 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols, April 2010.
[RFC 5766] IETF RFC 5766. Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN), April 2010
[RST TR] PacketCable Residential SIP Telephony Feature Definition Technical Report, PKT-TR-RST-
C01-140314, March 14, 2014, Cable Television Laboratories, Inc.
[SIP TR] PacketCable SIP Signaling Technical Report, PKT-TR-SIP-C01-140314, March 14, 2014,
Cable Television Laboratories, Inc.
[TGCP1.5] PacketCable 1.5 PSTN Gateway Call Signaling Protocol Specification, PKT-SP-TGCP1.5-I04-
120412, April 12, 2012, Cable Television Laboratories, Inc.
[TS 23.218] 3GPP TS 23.218, IP Multimedia (IM) session handling; IM call model; Stage 2, Release 7,
V7.9.0 (2008-06).
[TS 23.228] 3GPP TS 23.228, IP Multimedia Subsystem (IMS) Stage 2, Release 7, V7.12.0 (2008-06).
2.3 Reference Acquisition

• 3rd Generation Partnership Project: www.3gpp.org
• Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027; Phone +1-303-661-9100;
Fax +1-303-661-9199; Internet: http://www.cablelabs.com/
• European Telecommunications Standards Institute, http://www.etsi.org/home.htm/
• Internet Engineering Task Force (IETF), Internet: http://www.ietf.org/
Note: Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or
obsoleted by other documents at any time. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt/ Internet-Drafts may also be accessed at http://tools.ietf.org/html/

• National Emergency Number Association (NENA), http://www.nena.org/9-1-

1TechStandards/tech_info_docs.htm, http://www.nena.org/9-1-1TechStandards/voip.htm/
• Telcordia Technologies, http://www.telcordia.com/

3 TERMS AND DEFINITIONS

This specification uses the following terms:
Active call / Active A call state where the called party has answered the call and two-way media is being
session exchanged.
Automatic Location The database that maps telephone number to location in the current 9-1-1 system.
Identification
Automatic Number The mechanism used to determine the telephone number of the caller.
Identification
Callback When a PSAP initiates a new call back to a caller. This is not the same as ringback. See
below.
CNAM Calling Name.
Configuration Server The logical network element responsible for UE provisioning, configuration and
(Config.Server) management.
Dynamic Host The protocol used to configure an endpoint on an IP network commonly used to assign
Configuration it an IP address, and recently extended to configure the location of the endpoint.
Protocol
Emergency Services A device which bridges the VoIP network to the Selective Router. In PacketCable this
Gateway is a function of the MGC, SG and MG.
Emergency Services A code that looks like a telephone number that is temporarily assigned to a VoIP 9-1-1
Query Key call by the VPC and is used as the key to the ALI database to retrieve location
information for that call.
Emergency Services A code that is used to route a VoIP 9-1-1 call to the correct ESGW and also to choose
Routing Number an appropriate trunk group on that ESGW that connects to a specific Selective Router.
i1 NENA i1 documents mechanisms in use today to support 9-1-1 services by some VoIP
service providers. NENA i1 allows for VoIP 9-1-1 calls to be delivered to the correct
PSAP via a PSAP-designated 10-digit number.
i2 The second 911 VoIP migration phase, called "i2" as defined by NENA providing a
viable solution for VoIP carriers. There are two specialized "service operators"
introduced in this migration phase: the VPC Service Operator and the Emergency
Services Gateway Operator.
i3 The third and final migration phase planned by NENA, a more long term approach to
address the needs of having IP-enabled emergency centers.
Integrated Services User Part (part of the SS7 signaling stack).

Digital Network
Internet Engineering The standards body for the Internet.
Task Force
Media Gateway Devices bridging between the PacketCable IP Voice Communication network and the
PSTN. A Media Gateway provides the bearer circuit interfaces to the PSTN and
transcodes the media stream.
National Emergency The primary standards body for the 9-1-1 community.
Number Association

Off Hook The active state of a traditional telephone, while a call is in progress or being
attempted, and the telephone handset is out of its cradle.
On Hook The idle state of a traditional telephone, while no call is in progress and the telephone
handset is sitting in its cradle.
Proxy Server An intermediary entity that acts as both a server and a client for the purpose of making
requests on behalf of other clients.
Ringback A function applied by a PSAP that causes an offhook phone to get ROH tone and an on
hook phone to ring. This is not a new call. Ringback is not the same as Callback. See
above.
SIP Client The functional element subscribers use to attach to the PacketCable network.
(ENUM) Telephone In [RFC 3761], the E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Number Mapping Discover System (DDDS) Application (ENUM).
Trunk An analog or digital connection from a circuit switch that carries user media content
and may carry voice signaling (MF, R2, etc.).
VoIP Positioning A specialized service operator who determines which PSAP should get a VoIP 9-1-1
Center call given the reported location of the caller and supplies that location to the PSAP
when the PSAP consults the ALI.

4 ABBREVIATIONS AND ACRONYMS

This specification uses the following abbreviations:
3WC Three Way Calling
AC Auto Callback or Alternating Current
ACR Anonymous Call Rejection
ALI Automatic Location Identification
ANI Automatic Number Identification
AR Auto Recall
AS Application Server
AUID Application Unique Identifier
BLV Busy Line Verification
CF Call Forwarding
CFBL Call Forwarding Busy Line
CFDA Call Forwarding Don't Answer
CFV Call Forwarding Variable
CID Caller Identity Delivery
CIDB Caller Identity Delivery Blocking
CIDS Caller Identity Delivery and Suppression
CND Calling Number Delivery
CNDB Calling Number Delivery Blocking
COT Customer Originated Trace
CPE Customer Premise Equipment
CT Call Transfer
CWT Call Waiting
DHCP Dynamic Host Configuration Protocol
DND Do Not Disturb
DTMF Dual Tone Multi Frequency
DVA Digital Voice Adapter
E-CSCF Emergency-Call Session Control Function
ENUM Telephone Number Mapping
ESGW Emergency Services Gateway
ESQK Emergency Services Query Key
ESRN Emergency Services Routing Number
GRUU Globally Routable User-Agent URI
HSS Home Subscriber Server
ICE Interactive Connectivity Establishment
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
IP Internet Protocol
ISDN Integrated Services Digital Network

ISUP Integrated Services Digital Network (ISDN) User Part

ITU International Telecommunication Union
IVR Interactive Voice Responder
MG Media Gateway
MGC Media Gateway Controller
NAT Network Address Translation.
NBCS Network-Based Call Screening
NCS Network Call Signaling
NENA National Emergency Number Association
OCB Outbound Call Blocking
P-CSCF Proxy - Call Session Control Function
PIDF-LO A Presence Information Data Format Location Object
PRACK Provisional Acknowledgement
PSAP Public Safety Answering Point – the entity that answers 9-1-1 calls
PSTN Public Switched Telephone Network
QoS Quality of Service
RACF Remote Activation of Call Forwarding
ROH Receiver-Off-Hook, also known as "howler tone"
RST Residential SIP Telephony
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
SCF Selective Call Forwarding
S-CSCF Serving – Call Session Control Function
SDP Session Description Protocol, defined by [RFC 4566].
SG Signaling Gateway
SIP Session Initiation Protocol, VoIP signaling protocol, defined by [RFC 3261]
SLE Screening List Editing
SPP Subscriber Programmable PIN
SS7 Signaling System #7
STUN Simple Traversal of UDP through NATs
TCAP Transaction Capabilities Application Part (part of the SS7 signaling stack)
TURN Traversal Using Relay NAT
UE User Equipment
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
UTC Coordinated Universal Time
VM Voice Mail
VoIP Voice over Internet Protocol
VPC VoIP Positioning Center
VSC Vertical Service Code

5 OVERVIEW
This Residential SIP Telephony Feature Specification is an application specification that relies upon the
PacketCable architecture as described in [ARCH-FRM TR] and related PacketCable specifications. The Residential
SIP Telephony specifications are embodied in a separate standalone release. This document specifies how residential
telephony features must be implemented in PacketCable networks.
5.1 PacketCable Design Considerations for Residential SIP Telephony

The following design principles have been used in the creation of this specification.
• Minimal state awareness in network elements:
This specification avoids holding state in network elements when it is reasonable to do so. The knowledge of
any state related information is minimized in all network elements in order to favor scale and low cost
implementations. Some examples of state information are: status related to the SIP and media sessions, device
provisioning and QoS establishment.
• Distributed architecture for feature functionality:
This specification distributes more functionality to end-user equipment when functional, security, and other
requirements have allowed it. This creates more resilient and lower cost network solutions.
• Minimal changes to IMS specifications:
IMS was designed to provide a network capable of supporting multiple applications; hence this specification
avoids mandating changes to the IMS core network when it is reasonable to do so. This specification primarily
defines additional requirements for User Equipment, Application Servers, and PSTN Interconnect elements
such as Media Gateway Controllers.
• Transparency of end-user behavior for telephony service without inheriting the existing PSTN network
architecture:
As described above, the core architecture differs substantially from the existing PSTN network. Hence the
behavior and feature interaction of some telephony features may differ from that described within Telcordia
LSSGR specifications. In most cases the user behavior described within the referenced LSSGR specifications
has been reproduced.
5.2 Residential SIP Telephony Specific Applications

This specification describes the set of requirements for the implementation of residential telephony features using a
standard RST Client (called RST User Equipment (RST UE) or simply UE in this specification), which is in turn
connected to a PacketCable network.
In the current scope of this specification, we assume that the UE implementing the residential SIP Telephony
requirements interfaces with an analog phone.
This specification does not describe an implementation of the following features:
• Business telephone features
• Roaming or nomadic telephone features
• "Soft client" personal computer software "telephone" features

5.3 Functional Components for Residential SIP Telephony

For a description of the PacketCable architecture and Functional Components, please refer to [ARCH-FRM TR].
This specification defines specific requirements on the UE and Application Servers to implement Residential SIP
Telephony features. Some of the features are completely implemented on the UE; some are completely implemented
on an Application server, while some others are implemented on both UE and Application Server. The MGC
requirements for support of Residential SIP Telephony features are specified in [CMSS1.5].
An Application Server is a logical entity. In this specification, every feature that requires an Application Server is
associated with a distinct one. For example, the Call Transfer section defines requirements on the Call Transfer
Application Server (CT AS); the Outbound Call Blocking section defines requirements on the Outbound Call
Blocking Application Server (OCB AS) and so forth. In terms of implementation, more than one Application
Servers could be combined into one physical entity.
5.4 Protocol Interfaces for Residential SIP Telephony

The protocol interfaces for Residential SIP Telephony are defined in [ARCH-FRM TR]. The RST feature
specification (current document) is part of the RST suite of specifications which also consists of the following:
• PacketCable Residential SIP Telephony Accounting Specification:
The purpose of this specification is to define the collection of usage data needed to support Accounting of
Residential SIP Telephony Features.
• PacketCable Residential SIP Telephony E-DVA Specification:
This specification defines the embedded Digital Voice Adaptor (E-DVA) requirements for the analog interface
and for powering of the E-DVA. An embedded DVA is a DOCSIS cable modem (CM) integrated with a
PacketCable DVA.

6 NORMATIVE REFERENCE APPLICATION

The Residential SIP Telephony specification leverages a number of IETF documents and 3GPP, Telcordia, and
CableLabs specifications. This section names and describes key specifications that contain requirements for
implementations that claim compliance with this Residential SIP Telephony Feature Specification.
The PacketCable components compliant with the Residential SIP Telephony specification MUST implement all of
the normative requirements defined within the specifications [TS 23.228], [TS 23.218], [PKT 24.229], [QoS], and
[PKT 33.203], unless otherwise noted in the following sub-sections.
6.1 Adaptations of [PKT 24.229]

In order to support the PacketCable Residential SIP telephony application, several adaptations to [PKT 24.229] are
required. In most cases, the adaptations involve strengthening of requirements; such as changing optional
requirements to mandatory. The following requirements are modified. This is not a complete list, and there may be
other adaptations specified throughout the document.
• A UE MUST include the P-Preferred-Identity header in SIP messages if it is assigned more than one Public
Identity at registration time. [PKT 24.229] states that the P-Preferred-Identity header is optional regardless of
the number of assigned public identities.
• Requirements on the use and population of Privacy and From headers are strengthened. For details, see
Section 7.2, Caller ID.
• A UE MUST supply a Globally Routable User-Agent URI (GRUU) in its contact address when establishing a
dialog. The requirements for the handling of a GRUU defined in [RFC 5627] MUST be supported by the UE.
• The requirements for the handling of a History-Info header defined in [RFC 4244] MUST be supported by the
UE, Call Forwarding AS, and SIP network elements. In addition to the procedures in [PKT 24.229], the UE
MUST include a Supported Header in an INVITE request with the 'his info' option tag as defined in
[RFC 4244]. When proxying an INVITE, the SIP network elements MUST follow the rules defined in
[RFC 4244] with regard to inclusion and population of the History-Info header.
• The UE requirement for the case of receiving a NOTIFY with "rejected" event attribute can be configured. For
details, see Section 7.1.16.
• Any AS supporting an RST feature MUST support the Application Server procedures specified in
[PKT 24.229]. In addition, unless specified otherwise in this specification, any AS supporting an RST feature
and acting as a B2BUA MUST ensure that the To header field in the INVITE request of the outgoing call leg
matches the To header field received in the INVITE of the incoming call leg.
6.2 Additional IETF Requirements Based on Specific IETF RFCs and Internet-
Drafts
Additionally, the requirements, as defined within the following specifications, MUST be adhered to in order to
provide the service set defined herein.
• As defined in [RFC 3264], a UE that is operating using IPv4 MUST be capable of receiving SDP with a
connection address of IN IP4 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the
peer. This requirement provides backwards compatibility with [RFC 2543].
• The requirements within [RFC 5079] MUST be supported by the ACR AS.
• The requirements for the handling of a Replaces header as defined by [RFC 3891] MUST be supported by the
UE.
• The requirements for the handling of the REFER method as defined by [RFC 3515] MUST be supported by the
UE.

• The requirements for the notification of message-waiting events as defined by [RFC 3842] MUST be supported
by the Message Waiting Indicators (MWI) AS and the UE.
• The requirements defined by [RFC 4240] MUST be supported by an AS providing network announcements.
• The requirements in [RFC 3066] MUST be supported by a UE that wishes to indicate language preferences.
• The Alert-Info header as defined by [RFC 3261] MUST be supported by the Distinctive Ringing AS and the
UE.
• Subscriptions to the dialog-event package as defined by [RFC 4235] MUST be supported by the UE.
• The requirements for the handling of the Join header as defined by [RFC 3911] MUST be supported by the UE.
• The requirements for the handling of a target-dialog header as defined by [RFC 4538] MUST be supported by
the UE.
• The requirements for the handling of a P-DCS-Trace-Party-ID header as defined by [RFC 5503] MUST be
supported by the UE and the COT AS, with the exceptions noted in this document.
• The UE MUST support the inclusion of a Presence Information Data Format Location Object (PIDF-LO) as
defined by [RFC 4119] in INVITE requests conveying location information for emergency calls as required by
[ID SIP-CONVEY].
• The DHCP option as defined by [RFC 3825] MUST be supported by the UE.
• The DHCP option as defined by [RFC 4676] MUST be supported by the UE.
• The emergency session URI defined by [RFC 5031] MUST be supported by the UE and the P-CSCF.
• The requirements defined by [RFC 3959] MUST be supported by the UE and any AS in the network that
provides early media. For details, refer to Section 7.1.9.
The following requirements are optional to implement on the UE. The UE MAY implement the following
requirements:
• Preconditions requirements specified in [PKT 24.229].
• Referred-By header requirements specified in [RFC 3892].
• SIPS URI requirements specified in [RFC 3261].

7 RESIDENTIAL SIP TELEPHONY FEATURE REQUIREMENTS

7.1 Basic Calling Capabilities
All call flows in this specification are informative in nature. Some call flows illustrate the use of a 100 Trying
response to a received INVITE implying the use of an unreliable transport protocol as opposed to reliable transport
protocol as optionally provided by [PKT 33.203]. These are illustrative only and there is no normative requirement
on the use of unreliable transport protocol imposed by this specification.
7.1.1 Digit Maps

Digit maps are provisioned on the UE to inform the UE about how dialed digits should be interpreted. A digit map is
an ordered set of regular expressions combined with some special tokens that represent actions to be carried out by
the UE when a regular expression is matched. While the remaining of this section is for North American digit maps,
the PacketCable digit map syntax defined below can represent any country digit map.
PacketCable digit maps are capable of representing the following types of digit strings (where N is for descriptive
purpose only and represents any single digit between 2 and 9 inclusive and X represents any single digit between 0
and 9 inclusive):
• NXX-XXXX (7-digit dialing)
• NXX-NXX-XXXX (10-digit dialing)
• 1-NXX-XXXX [terminator] (7-digit dialing)
• 1-NXX-NXX-XXXX (10-digit dialing)
• [0-1]N11 (special service codes)
• 0 [terminator] (local operator)
• 00 (carrier operator)
• 011 followed by up to 15 digits followed by [terminator] (international direct distance dialing)
• 01 followed by up to 15 digits followed by [terminator] (operator assisted international dialing)
• 10XXX [terminator] (3 digit carrier code dialing)
• 10XXX-NXX-NXX-XXXX (3-digit carrier code toll dialing)
• 101XXXX-NXX-NXX-XXXX (4-digit carrier code toll dialing)
• *XX (2-digit vertical service code)
• 11XX (2-digit vertical service code)
• *XXX (3-digit vertical service code)
• 11XXX (3-digit vertical service code)
• N [terminator] (1-digit speed dial code)
• NX [terminator] (2-digit speed dial code; first digit limited to 2-4)
Any time an optional terminator (represented above by "[terminator]") may be dialed, the UE MUST measure
critical digit timing to determine if any additional digits are to be dialed. If the terminator digit is dialed (normally
#), the UE MUST cancel critical digit timing measurement. Also, the UE SHOULD accept the digit string as
dialed. If no terminator digit is dialed, the UE MUST accept the digit string as dialed when the critical digit timer
expires.
If an operator requires the support of both 7- and 10-digit dialing, the 7-digit dialing should be specified with an
optional terminator digit. This approach for defining the digit map is recommended because the first 3 digits dialed

may not provide enough information to determine whether 4 or 7 additional digits are required to successfully match
an entry in the digit map.
Dialing errors are captured through a combination of the digit map function and the extended offhook processing
defined in Section 7.1.4.4.
7.1.1.1 Digit Map Syntax Introduction

The digit map is organized into a list of rules. The UE MUST apply the digit map rules sequentially and upon
matching a pattern, including timers, the UE MUST perform the specified action or actions.
All of the mechanisms in this syntax specification are described in both prose and an augmented Backus-Naur Form
(BNF) defined in [RFC 4234]. [RFC 4234] defines a set of core rules that are used by this specification, and not
repeated here. Implementers need to be familiar with the notation and content of [RFC 4234] in order to understand
this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
Annex A of this document contains the augmented BNF for the Digit Map Syntax.
7.1.1.2 Digit Map Semantics

DigitMapPackage: This is a complete and self-contained unit of definitions, suitable for provisioning on a UE. A UE
MUST support a DigitMapPackage for each public user identity.
TimerDef : Defines the duration denoted by one of the named timers that influence the processing of dial strings.
The duration is specified as a decimal number, in units of seconds. Fractional seconds may be specified. The UE
MAY round the value up to the minimum required resolution to accommodate the resolution of its internal clocks.
The minimum required resolution of the digit collection timers MUST be one tenth of one second. The values
specified apply to all DigitMapPackages defined. Syntax checking, such as checking for redundant timer definitions,
should be performed outside of the UE, prior to provisioning the digit map into the UE.
There are two named timers – S and Z. Each timer has a different purpose:
• S - Short Interdigit Timer: Used when critical timing should be performed, such as when the dialed digits
constitute a complete address, but additional digits may constitute a different complete address.
• Z - Long Duration Timer: The duration a particular digit is to be held in order to be detected. When a Z is
placed in a pattern, the Long Duration Timer is applied to the following key in the pattern.
SymbolDef: Defines a named symbol that may be referenced within a pattern or action. The actual value of the
symbol can be defined internally or externally to the DigitMapPackage.
• When defined internally to the DigitMapPackage, the value of the symbol is a string formed by concatenating
all of the constant pieces in the definition, but omitting the surrounding quotation marks and any intervening
white space and comments.
• When defined externally to the DigitMapPackage, the value of the symbol is required to be preceded with the
ampersand ('&') character, it cannot be quoted, cannot contain an ampersand character and it is required to be a
single name (no intervening white spaces and comments). The symbol value is resolved through fetching the
Basic Call Feature Data information (Section 7.1.4.5). The symbol value needs to be resolved during execution
of the relevant rule action making reference to it and taking into account the current execution context in which
the rule has been invoked (as an example, the same symbol may resolve to different external value depending
on which user is making usage of the common DigitMapPackage). The sample digit map (Section 7.1.1.3)
shows an example of such use.
SymbolDefs apply to the entire DigitMapPackage, and each SymbolDefs name must be unique. When referencing
symbols, the name comparison must be case insensitive. The method of specifying the value of a symbol is similar
to the method used to specify the value of parameter in a rule action.
MapDef: Defines a named map. MapDefs apply to the entire DigitMapPackage, and it is an error to define the same
name more than once, as a symbol or a map. A map contains one or more rules for interpreting dialed digits. All the
rules in a map are compared to the same dialstring in parallel while dialing is in progress, and continues until at least

one of the rules has matched, or until it is determined that none of the rules can match the dialstring. If more than
one rule matches the same dialstring, then the first matching rule is followed.
Rule: A rule includes a pattern that can be matched against a dial string, and a list of actions to be carried out, in
sequence, when a dialed string is matched.
Pattern: A pattern is a concise way of representing a number of dial strings of interest. In its simplest form, a pattern
denotes a sequence of keys that are pressed on a telephone keypad. The valid keys are the numbers '0' through '9',
the '*' key, the '#' key, and the keys 'A' through 'D' that are present on some keypads. Additional elements may be
used so that a single pattern may match more than one dial string.
The character 'X' (or 'x') denotes any numerical digit – '0' through '9'.
The notation '[stu…z]', where 's', 't', etc. are letters on keyboard keys (in case the UE has the ability to type letters on
a keyboard), matches any of the keys 's', 't', etc. The order of the characters within the brackets is unimportant.
The notation '[n-m]', where 'n' and 'm' are digits, matches any single digit in the range n-m. In other words, '[3-7]'
means the same as '[34567]'. This form may also be combined with the preceding form, so that '[A2-49]' is valid and
is equivalent to '[2349A]'.
The notation '[^stu…z]' matches any keyboard key that would not be matched by '[stu…z]'. This may be used with
all the forms above, so that '[^A2-49]' is valid and is equivalent to '[015678BCD*#]'.
Any key or bracketed notation for a key may be preceded by the character 'Z' (or 'z'). This means to apply the long
duration timer Z to that keypress. In that case, a match occurs only if a matching key is held down for a duration
equal to the long duration timer Z.
When the notation for a key is followed by '{n-m}' it means that the preceding key should be repeated a minimum of
'n' times and a maximum of 'm' times. This is equivalent to creating multiple patterns. For instance "1x{2-3}7" is a
matching equivalent to the two patterns "1xx7" and "1xxx7." The form '{-m}' is allowed and means '{0-m}'.
The character 'S' (or 's'') may be included to denote the short interdigit timer. This element is matched when the
corresponding amount of time elapses without key entry since the entry of the previous matched key.
Anything valid in a pattern, including all of the above forms, may be enclosed in parenthesis '(' and ')' and then
inserted as an element in a pattern, denoting a sub-pattern. Sub-patterns may be nested within other sub-patterns.
Within a pattern, sub-patterns may be denoted by counting the total number of '(' characters from the beginning of
the pattern to the beginning of the sub-pattern. For example, in the pattern "1(8xx)(555(xxxx))" the sub-pattern
'xxxx' may be referenced by the value 3. This is useful in constructing the parameters to actions.
A sub-pattern may also contain an '=' followed by the name of a symbol or map. If a symbol is named, then the
meaning is the same as if the string value of the symbol had been included. In this case the value of the symbol must
conform to the syntax of a pattern. If a map is named, then that map is applied, and then matching continues with
whatever follows the sub-pattern.
Note: The execution of an action associated with a sub-pattern is conditional on a successful match of the parent
pattern. That means that the action specified by the sub-pattern cannot be applied until successful match of
the entire pattern.
Finally, the characters '-', '.' and space that are often used as punctuation in telephone numbers may be used freely
anywhere a character denoting a key may be used to improve the readability of patterns. The '-', '.' and space
characters must be ignored as they play no role in matching.
Action: An Action invokes specific behavior when a rule has been matched by a dial string. Two special actions
(RETURN and USEMAP) affect digit map processing and are defined here. Other actions may be defined to interact
with the environment outside of the digit map, and are defined elsewhere.
Each action has a name, and may have one or more parameters. If the action has parameters, they are enclosed in
parentheses and separated by commas. There are two kinds of parameters: map parameters and string parameters.
Each action has some expectation regarding the number of parameters it expects, which ones are maps, which are
strings, and what string content is acceptable.

A map parameter is used to pass a map reference to an action. Its most obvious use is with the USEMAP action. A
map parameter is denoted by an '=' followed by the name of a map.
A string parameter is composed of one or more strings. Each string is concatenated to form the value of the
parameter. (The form used to denote a parameter is similar to that used to denote the value of a SymbolDef.) Each
string making up the parameter is demarked using single or double quote characters. A string may contain any
printable ascii character except single or double quotes.
A string in a string parameter may also refer to characters matched in the pattern of the containing rule. The string
beginning with '#' followed by a number N, refers to the portion of the dialstring matching the Nth sub-pattern
within the pattern. For example, given the pattern "1(8xx)(555(xxxx))," and the dialstring "18885559876", "#3"
refers to the value "9876." The string "#0" refers to the entire matched dialstring.
A string may also be denoted by a '#' followed by a number N, followed by a 'v'. If sub-pattern N is a reference to a
digit map, then this syntax refers to the value returned by that map (see description of RETURN).
Action RETURN: The RETURN action specifies the value that results from the application of a map. It may have
zero or one parameter. The value returned for zero parameters is "" (empty string). The value returned for one
parameter is the digits matched from the dialstring.
The RETURN action only affects the value of the map. It does not affect other actions associated with the same rule.
(Hence the RETURN action MAY be followed by other actions, though this may be confusing.) There SHOULD be
at most one RETURN action per rule. For completeness, if there is more than one, the last one determines the value
of the map. If there are no RETURN actions in a rule, then a RETURN action with no parameters is assumed.
Action USEMAP: The USEMAP action is a way to apply a named map to dialstring input received after the
containing rule has been matched. It provides a way for dialed digits to determine how subsequent dialed digits
should be interpreted. It may have no parameters or one map parameter. If a parameter is present, it denotes the map
to be used. If no parameters are present, then USEMAP processes the first map defined within the
DigitMapPackage.
The referenced map may also have rules that specify actions. Actions are processed in order within a rule. When a
USEMAP action is processed, any actions it may specify are processed after actions preceding the USEMAP, and
before actions that follow the USEMAP.
There is a subtlety here that interacts with that for sub-pattern matching. As noted above, if a sub-pattern references
a map, and if the reference to the sub-pattern is followed by other targets to be matched, then the rules for the sub-
pattern cannot be invoked until the parent pattern is known to match. If the sub-pattern contains a USEMAP, then at
the time the USEMAP is applied, the dial string input will have been advanced beyond where it was when the rule
containing the USEMAP was matched.
Action MAKE-CALL: The MAKE-CALL action provides a standard way to create a SIP or TEL URI and send an
INVITE to the target identity. The MAKE-CALL action's parameter is the Request-URI to be used to create the
INVITE request.
7.1.1.3 Sample Digit Map

This example allows: 7-digit and 10-digit local calling; 10-digit and 1+ 10-digit long
distance calling. It is not applicable to locations that allow 7-digit dialing to more
than one area code.
// Timer values
TIMER S=4 // Short interdigit timer. Used when critical timing should be
// performed, such as when the dialed digits constitute a complete
// address, but additional digits may constitute a different
// complete address
TIMER Z=2.0 // Long duration timer. The duration a particular digit is to be
// held in order to be detected.
// Symbols
domain = "@example.net"

areaCode = &varAreaCode // varAreaCode is defined via configuration (see Basic Call

Feature Data Table)
dialString = ";user=dialstring" // Just to shorten things
homeEmergencyNumber = "911"
localEmergencyNumber = "911" // alternate emergency number
// Maps
MAP MainTable = // This is where processing starts
"0(=End)" : MAKE-CALL ("sip:0" =domain =dialstring)
: MAKE-CALL ("sip:00" =domain =dialstring)
"(=Emergency)" : EMERGENCY-CALL ("urn:service:sos")
"[2-8]11" : MAKE-CALL ("sip:" #0 =domain =dialstring)
// or : MAKE-CALL ("tel:" #0 ";phone-context=+1")
"(=PhoneNumbers)" : MAKE-CALL ("tel:" #1v )
"(=DialAround)" : MAKE-CALL ( "tel:" #1v )
"0(=NationalNumbers)" : MAKE-CALL ( "sip:0" #1v =domain =dialstring )
"0([2-9]x{0-15}) (=End)" // let operator decipher unknown string
: MAKE-CALL ( "sip:0" #1 =domain =dialstring )
"([2-9]) (=End)" : MAKE-CALL ( "sip:" #1 =domain =dialstring)
// one-digit speed dialing
"([2-4]x) (=End)" : MAKE-CALL ( "sip:" #1 =domain =dialstring)
// two-digit speed dialing
"(=ImmediateVSCs)" : RETURN
"(=DelayedVSCs)" : RETURN
"Z#" : RECALL; USEMAP(=MainTable)
// Press # for 2 seconds and get recall dial tone
"x{1-29}*" : REORDER
"x{1-29}#" : REORDER
"x{30}" : REORDER
MAP Emergency = // Matches emergency dialstrings

"(=localEmergencyNumber)" : RETURN
"(=homeEmergencyNumber)" : RETURN
"[01](=homeEmergencyNumber)" : RETURN
MAP PhoneNumbers = // Matches phone# and returns the canonicalized

// form without a scheme
"(=CollectNumbers)" : RETURN( #1v ) // override later matches
"(=SurchargedNumbers)" : RETURN( #1v ) // override later matches
"1{0-1}(=NationalNumbers)" : RETURN("+1" #1v )
"011([2-9]x{1-14}) (=End)" : RETURN( "+" #1 )
"01([2-9]x{1-14}) (=End)" : RETURN( "01" #1 )
MAP CollectNumbers = // 800 and friends

"1{0-1} (800[2-9]x{6})" : RETURN( "+1" #1 )
"1{0-1} (866[2-9]x{6})" : RETURN( "+1" #1 )
"1{0-1} (888[2-9]x{6})" : RETURN( "+1" #1 )
MAP SurchargedNumbers = // 900, etc.

"1{0-1} (900[2-9]x{6})" : RETURN( "+1" #1 )
MAP DialAround = // Matches dial around phone# and returns canonicalized

// form without scheme
"101(x{4})(=PhoneNumbers)"
: RETURN( #2v ";cic=+1" #1 )
// (CIC dialed by user)
"101(x{4})0" : RETURN( "0" ";cic=+1" #1 )
MAP ImmediateVSCs = // Matches and executes immediate VSCs. Returns nothing

"(=Star)57" // (COT-ACTIVATE)
: COT-ACTIVATE (#0) // Can't use MAKE-CALL for this.
"(=Star)63" // (SCF)

: MAKE-CALL ( "sip:" #0 =domain =dialstring)

"(=Star)66" // (AC-ACTIVATE)
: AC-ACTIVATE (#0) // Auto Callback
"(=Star)86" // (AC-DEACTIVATE)
: AC-DEACTIVATE ("sip:" #0 =domain =dialstring)
// Auto Callback
"(=Star)69" // (AR-ACTIVATE)
: AR-ACTIVATE (#0) // Auto Recall
"(=Star)89" // (AR-DEACTIVATE)
: AR-DEACTIVATE ("sip:" #0 =domain =dialstring)
// Auto Recall
"(=Star)77" // ACR-ACTIVATE
: ACR-ACTIVATE ( "sip:" #0 =domain =dialstring)
"(=Star)87" // ACR-DEACTIVATE
: ACR-DEACTIVATE ( "sip:" #0 =domain =dialstring)
"(=Star)83" // (SCF)
: FEATURE-CHECK("23"); MAKE-CALL (sip:" #0 =domain
=dialstring)
"(=Star) 7[89]" // (DND-ACTIVATE/DND-DEACTIVATE)
: FEATURE-CHECK("16"); MAKE-CALL ( "sip:" #0 =domain
=dialstring)
"(=Star)95" // (SPP)
=dialstring)
"(=Star)96" // (SB-MAINT)
=dialstring) // solicitor blocking maintenance
"(=Star)72" // (CFV PROGRAM)
// Check if CFV(11) available
// if not available - play network announcement
// if available
// Play Recall Dial Tone
// Collect digits using subset digitmap
// Prepend "*72." onto dialed address using SIP URI
// The following is an example implementation:
: FEATURE-CHECK("11", "file:///PacketCableRST/ro");
RECALL; USEMAP(=ForwardingNumber)
"(=Star)73" // (CFV DEACTIVATE)
// Check if CFV(11) available
// if not available - play network announcement
// if available
// Play Recall Dial Tone
// MAKE-CALL with *73 as dialed address using SIP URI
// The following is an example implementation:
: FEATURE-CHECK("11","file:///PacketCableRST/ro");
MAKE-CALL("sip:*73" =domain =dialstring )
MAP DelayedVSCs = // Make some state change, then continue processing dialing
"(=Star)52" // (HOLD)
: HOLD-ACTIVATE; USEMAP(=MainTable)
"(=Star)68" // CID-SUPPRESS
: CID-SUPPRESS; USEMAP (=MainTable)
"(=Star)67" // CNDB-TOGGLE
: CNDB-TOGGLE; USEMAP (=MainTable)
"(=Star)82" // CID-DELIVER
:= CID-DELIVER; USEMAP (=MainTable)
"(=Star)70" // (CCS) (Really Toggle-Call-Waiting)
: CW-TOGGLE; USEMAP(=MainTable)
// The CALL-WAITING action must give the right tone.
"(=Star)74" // (SD8)
: FEATURE-CHECK("27"); RECALL; USEMAP (=SD8)
"(=Star)75" // (SD30)
: FEATURE-CHECK("27"); RECALL; USEMAP (=SD30)

MAP SD8 = // Program one-digit speed dial number

"[2-9]" : MAKE-CALL("sip:*74." #0 =domain =dialstring)
"[^2-9]" : REORDER
"S" : REORDER
MAP SD30 = // Program two-digit speed dial number

"[2-4]x" : MAKE-CALL("sip:*75." #0 =domain =dialstring)
"[^2-4]" : REORDER
"S" : REORDER
"[2-4] (=End)" : REORDER
MAP ForwardingNumber = // Just for programming CFV

"(=SurchargedNumbers)" : REORDER // not allowed
"(=PhoneNumbers)" : MAKE-CALL ( "sip:*72." #1v =domain
=dialstring)
MAP Star = // Matches star & 11

"(*)" : RETURN
"(11)" : RETURN
MAP End = // Matches End of Dial Indicators # or S

"#" : RETURN
"S" : RETURN
MAP NationalNumbers =
"([2-9]x{6})(=End)" : RETURN( =areaCode #1 )
"([2-9]x{2}[2-9]x{6})" : RETURN( #1 )
7.1.2 Vertical Service Codes

Vertical service codes are dialed digit strings used to represent feature invocations. They are sometimes referred to
as star codes or feature activation codes. A feature invocation is feature activation, feature deactivation, feature
programming, or feature instance. Vertical service codes (VSCs) do not have to begin with a star, nor are they
restricted to 3-digit strings such as "*69." The actual digits that make up a VSC are defined by the digit map. The
digit map also defines whether the VSC is processed by the UE or forwarded to the network via the substitution
methodology defined above.
Since VSCs can be defined by an operator based on their needs and some VSCs are processed by the UE, the
digitmap indicates how to map VSCs to PacketCable residential SIP services.
For vertical service codes processed in the network, the UE MUST pass the VSC and any other digits required by
the digit map to the network using a SIP INVITE. The digits MUST be reported using a SIP URI with
user=dialstring. The digits themselves are included in the SIP URI as defined by the digitmap substitution.
Table 1 provides the defined local action identifiers for the services defined in this document. Table 2 identifies the
suggested VSCs for use in North America. The expected digit-map input parameters (as per Section 7.1.1) for the
UE actions are also indicated in Table 1.
Table 1 - Digit Map Actions
UE Action ID and Input Parameter(s) Description

ACR-ACTIVATE (<request URI>, [<failure URI>]) Anonymous Call Rejection – activation. Play reorder tone or failure URI
if specified when feature is not configured.
ACR-DEACTIVATE (<request URI>, [<failure URI>]) Anonymous Call Rejection - deactivation. Play reorder tone or failure
URI if specified when feature is not configured.
AC-ACTIVATE (<VSC>, [<failure URI>]) Auto Callback - activation. Play reorder tone or failure URI if specified
when feature is not configured.
AC-DEACTIVATE (<VSC>, [<failure URI>]) Auto Callback - deactivation. Play reorder tone or failure URI if specified
MAKE-CALL (<request URI for the call>) Basic call

UE Action ID and Input Parameter(s) Description

AR-ACTIVATE (<VSC>, [<failure URI>]) Auto Recall - activation. Play reorder tone or failure URI if specified
AR-DEACTIVATE (<VSC>, [<failure URI>]) Auto Recall - deactivation. Play reorder tone or failure URI if specified
CID-SUPPRESS ([<failure URI>]) Caller ID Suppress. Play reorder tone or failure URI if specified when
feature is not configured.
CID-DELIVER ([<failure URI>]) Caller ID Delivery. Play reorder tone or failure URI if specified when
CNDB TOGGLE ([<failure URI>]) Caller ID Toggle. Play reorder tone or failure URI if specified when
Caller ID Suppress is not configured.
COT-ACTIVATE (<VSC>, [<failure URI>]) Customer-Originated Call Trace. Play reorder tone or failure URI if
specified when feature is not configured.
CW-TOGGLE ([<failure URI>]) Call waiting toggle. Play reorder tone or failure URI if specified when
FEATURE-CHECK (<feature-id>, [<failure URI>]) If the feature identified by feature-id is not enabled play the failure URI if
specified, otherwise play reorder tone. Stop processing further actions if
the check fails.
ACTIVATED-CHECK (<feature-id>, [<failure URI>]) If the feature identified by feature-id is not activated play the failure URI
if specified, otherwise play reorder tone. Stop processing further actions
if the check fails.
DEACTIVATED-CHECK (<feature-id>, [<failure URI>]) If the feature identified by feature-id is not deactivated play the failure
URI if specified, otherwise play reorder tone. Stop processing further
actions if the check fails.
HOLD-ACTIVATE ([<failure URI>]) Hold Activate. Play reorder tone or failure URI if specified when feature
is not configured.
EMERGENCY-CALL (<request URI for emergency call>) Emergency Call
REORDER Reorder tone
RECALL Recall tone
Table 2 - Features that are Configurable Through the Digit Map
Service Action Suggested VSC

Anonymous Call Rejection Activation *77
Deactivation *87
Automatic Callback Activation *66
Deactivation *86
Automatic Recall Activation *69
Deactivation *89
Caller ID Per-Call Blocking Suppress Any unique code
Caller ID Per-Call Delivery Deliver *82
Caller ID Per-Call Toggle Toggle *67
Customer Originated Trace Activation *57
Call Waiting Toggle *70
Call Forward Variable Programming *72
Deactivation *73
Distinctive Alerting List Maintenance *61, *81
Do Not Disturb Programming *78, *79
Hold Activation *52
Selective Call Forward Programming *63, *83
Solicitor Blocking List Maintenance Two unique codes
Speed Dial Programming *74 (SD8), *75 (SD30)

Service Action Suggested VSC

Subscriber Programmable PIN Programming Any unique code
Emergency Call Activation 911, 0911, 1911 (or other provisioned
emergency number)
The UE action functions are defined in the corresponding feature sections in this document. Some UE action
functions amount to sending the VSCs in INVITE requests to the corresponding application servers. Unless
overridden in the feature sections, the UE MUST include the request URI for such an INVITE using the general
form below:
sip:<input VSC parameter>@<domain>; user=dialstring
where < input VSC parameter > represents the matched VSC in the digit map and is obtained from the input
parameter of the UE action function; <domain> denotes the domain name provisioned to the UE. For instance, the
SIP URI may be:
sip:*57@example.com; user=dialstring
If a VSC-triggered feature is not available per UE provisioning, the UE obeys the following general rules in the
corresponding action function, unless specifically overridden in the feature sections:
• The UE MUST play a reorder tone (or an announcement if supported) to the user.
• The UE MUST NOT send the VSC-carrying INVITE to the AS.
7.1.3 Addressing and Dial String Entry

A UE MUST be able to collect digits, aggregate digits into dial strings and match them with the digit patterns
specified in a provisionable digit map. Dial strings are strings of characters that correspond to DTMF digits. The
characters are 0-9, A-D, *, and #.
The form of an address created by a UE is determined by the provisioned digit map.
The last rule of the digit map specifies the default behavior, and MUST match any pattern of dialed digits. This last
rule of the digit map MUST provide an error indication to the user that an invalid pattern of dialed digits has been
entered. The last rule of the digit map SHOULD specify reorder tone be played to the user.
Once a dial string matches a digit pattern, the UE MUST stop digit collection.
The digit map MUST be preconfigured on the UE via the Configuration Server.
A UE MUST take action according to the provisioned digit map processing after successfully matching the
dialstring. If the output of the digit map is intended to invoke a feature, the feature is performed by the UE, or
another network element, or a combination of both.
7.1.4 Basic Call Signaling

The basic calling capabilities consist of an originating call half and a terminating call half. A UE MUST support
[PKT 24.229] for the basic call capabilities. A UE MUST support [RFC 4566]. The requirements specified in this
section apply in the absence of other features.
7.1.4.1 Originating a Call

When originating a call, a UE MUST be able to:
• Detect off hook.
• Apply dial tone when off hook is detected or when specified by the provisioned digit map.
• Collect dialed digits as specified in the provisioned digit map.
• Process the actions specified in the provisioned digit map.

• Initiate a SIP session, as specified in [PKT 24.229].

• Encode and decode RTP and RTCP packets as defined in [CODEC-MEDIA].
• In the IP packets carrying the media sent from the UE towards the network, set the DSCP field to the
provisioned Non-Emergency media DSCP Value defined in Table 4.
When a UE sends an INVITE to initiate a session, the UE MUST offer the codecs in the SDP using the Preferred
network codec list defined in Table 4.
When a UE sends an INVITE to initiate a session, the UE MUST record the identity of the called party in local
memory. If the identity of the called party is anonymous or unknown, the UE MUST record the information that the
called party was anonymous or unknown in local memory. The identity of the called party may be unknown in the
case of the Auto Callback feature.
The UE MUST populate the To header of an originating INVITE with the URI contained in the Request-URI. This
will ensure that when a user initiates a call by dialing a Vertical Service Code for a feature where the UE selects the
called user identity (e.g., Auto Recall), then the To header of the INVITE will contain the called user identity and
not the dialed VSC code.
If an AS supporting a RST feature receives an INVITE request with a Request-URI identifying a Vertical Service
Code for an originating feature such as Speed Dial or Auto Recall whereby the AS chooses the called Public User
Identity, then the AS MUST populate the To header of the INVITE with the selected called Public User Identity.
This will ensure that when a user initiates a call by dialing a VSC for a feature where an AS supporting a RST
feature selects the called user identity, then the To header of the INVITE will contain the called user identity and not
the dialed VSC code.
Upon receiving an 18X message with an alert-info header, the UE MUST apply the ringback tone identified in the
alert-info header to the phone if it has the capability to do so. If the UE is not capable of applying the ringback tone
identified in the alert-info header, it MUST locally apply ringback tone. If the UE receives a 180 or 183 provisional
response message without an alert-info header and without an SDP, the UE MUST locally apply ringback tone to the
phone, and any received RTP packets should be ignored. Upon receiving a 180 or 183 message without an alert-info
header and with an SDP, and if RTP audio is received, the UE MUST play back the received RTP audio rather than
applying local ringback tone to the phone. Upon receiving a 180 or 183 message without an alert-info header and
with an SDP, and there is no RTP audio received, then the UE MUST locally apply ringback tone. These actions are
detailed in Table 3.
Table 3 - Actions at Calling UE upon Receipt of an 18X Message
Alert-Info Header Present? SDP Received? RTP Packets Received? Action

No No No Play local ringback
No No Yes Play local ringback
No Yes No Play local ringback
No Yes Yes Play audio received in RTP packets
Yes No No Play audio from alert-info header
Yes No Yes Play audio from alert-info header
Yes Yes No Play audio from alert-info header
Yes Yes Yes Play audio from alert-info header
If the Calling UE is configured to require that network resources are reserved before continuing with the session
([PKT 24.229]), then the Calling UE MUST NOT deliver media to the user until resource reservation is complete.
If the alert-info header is included in an 18X provisional response from the called party and resource reservation is
required but not yet completed, then the Calling UE MUST delay the application of the alert-info header until an
updated offer SDP is received showing that the remote resources are now reserved.
Upon receiving a 486 BUSY HERE message, the UE MUST apply an indication to the user of the call status as
defined by the entry for this response code in the announcement map as specified in Section 7.1.6.7, respond with an
ACK and terminate the session.

Upon receiving any other response code, the UE MUST respond according to Section 7.1.11.
7.1.4.2 Receiving a Call

When receiving a call, a UE MUST be able to:
• Locally apply ringing or distinctive ringing to the called party
• Encode and decode RTP packets
• In the IP packets carrying the media sent from the UE towards the network, set the DSCP field to the
provisioned Non-Emergency media DSCP Value defined in Table 4.
A UE MUST reject received RTP packets that are not associated with an existing early or confirmed dialog. Refer
to [RFC 3261] for the definition of early and confirmed dialogs.
A UE MUST have the capability to accept an incoming SIP session, as specified in [PKT 24.229]. For SDP codec
negotiation, the UE MUST use the Preferred network codec list defined in Table 4.
When a UE receives an incoming INVITE, and sends a progress message according to [PKT 24.229], it MUST alert
the user unless resource reservation is in progress at either the originating or terminating UE. If the UE is
configured to require that network resources are reserved before continuing with the session ([PKT 24.229]), and
this reservation is not complete, then the Called UE MUST NOT alert the user until it has received an updated SDP
from the calling party showing that the remote resources are now reserved.
When a UE receives an incoming INVITE, and if the UE has alerted the user, the UE MUST record the dialog ID of
the call and the identity of the calling party, if known, in local memory. If the identity of the calling party is
anonymous or unknown, and if the UE has alerted the user, the UE MUST record the information that the calling
party was anonymous or unknown in local memory.
The UE MUST respond with a 486 BUSY HERE message if the phone is already off-hook when the UE receives
the incoming INVITE unless Call Waiting is enabled for this user as defined in Section 7.5.2. The UE MUST NOT
record the identity of the calling party in its incoming call memory if the UE responds with a 486 BUSY HERE
message.
After the user has been alerted about an incoming call and the UE detects an off hook event, the UE MUST return a
200 OK to the INVITE.
7.1.4.3 On Hook Processing

When a calling UE with an active session (where the called party has answered the call and two-way media is being
exchanged) detects an on-hook condition before receiving a BYE from the remote party, the calling UE MUST send
a BYE request to the remote party.
The following requirements apply when a called UE with an active session detects an on-hook condition before
receiving a BYE from the remote party.
• The UE MUST start the BYE delay timer which delays the sending of BYE to allow the user to pick up the
phone again (as defined in Table 4, 'BYE Delay') and send comfort noise RTP packets to the remote UE using
the RTP payload format defined in [RFC 3389]. While the BYE delay timer is running, the previously
established session is still active; hence feature interactions are maintained.
• If the UE detects off hook before expiry of BYE Delay timer, the UE MUST stop the BYE delay timer and stop
sending comfort noise RTP packets to the remote UE according to [RFC 3389] and resume the media session
according to the previously negotiated SDP modes.
• If the BYE Delay timer expires, the UE MUST send a BYE request.
• If a BYE request is received while the BYE Delay timer is running, the UE MUST stop the BYE Delay timer
and respond to the BYE with a 200 OK.
• While the BYE Delay timer is running, the UE MUST reject any incoming call with a 486 response.

The above requirements for on-hook processing apply to a basic call only. The requirements for on-hook processing
during the execution of Call Waiting and Three-Way Calling are provided in Section 7.5.2 and Section 7.5.5,
respectively.
7.1.4.4 Extended Off Hook Processing

There are three ways a telephone handset can be left off-hook for an extended period of time:
• Origination Mode: the device was in an idle state (on-hook) and is placed off-hook and left there (presumably
accidentally) for a long period of time, or
• Termination Mode: the device was in use for a call and was not successfully returned to an idle state (placed on
hook) within 20 seconds after the call was terminated (that is, this UE received BYE). This can occur whether
the party was the originator or the receiver of the original call.
• Error Response Mode: the UE was in use for a call and either the UE received an error response (4xx, 5xx, 6xx)
and was not successfully returned to an idle state (placed on hook) before the completion of error
tones/announcements or the UE initiated release of the call while the user is still offhook (e.g., due to session
timers).
In the Origination Mode, the UE initially offers dial tone to prompt the end user to dial the desired number
according to Section 7.1.7. After the Origination Mode Dial Tone timer or the Long Interdigit timer defined in Table
4 expires, before which the user simply did not dial any digit, the UE MUST invoke its permanent sequence and
lockout treatment as defined below. The UE starts the Origination Mode Long Interdigit Timer defined in Table 4
after each digit dialed by the user. When the Origination Mode Long Interdigit Timer expires without the user
having dialed any further digits and without finding a match in the digit map, the UE MUST invoke permanent
sequence and lockout treatment as defined below. The Origination Mode Long Interdigit Timer SHOULD be set
longer than the Timer S defined in Section 7.1.1.2.
In the Termination Mode, the UE MUST apply the Termination Mode Off-Hook Error Signal (defined in Table 4)
for a time period defined as Termination Mode Error Signal Timer in Table 4 or until an on-hook state is detected.
If the Termination Mode Error Signal Timer expires before the on-hook state is detected, the UE MUST play the
announcements as defined in Table 4 and then invoke the permanent sequence and lockout treatment as defined
below. Upon detecting the on hook state, the UE MUST return to the idle state for the provisioned services.
In the Error Response Mode, the UE MUST invoke its permanent sequence and lockout treatment as defined below.
When the permanent sequence and lockout treatment is invoked, the UE MUST begin to generate a configurable
sequence of tones and announcements. These tones (Permanent Sequence Tone 1, Permanent Sequence Tone 2,
Permanent Sequence Tone 3, and Permanent Sequence Tone 4) and the timers that govern the duration of these
tones (Permanent Sequence Timer 1, Permanent Sequence Timer 2, Permanent Sequence Timer 3, and Permanent
Sequence Timer 3) are defined in Table 4. For example, the "Receiver-Off-Hook" (ROH) tone (sometimes called
Howler Tone) has traditionally been used in this situation. This is a four frequency tone which increases in
amplitude and repeats for a provisioned period of time. This tone can be re-defined by provisioning a different tone.
The sequence of tones and announcements MUST be generated by the UE until the last timer in the sequence
expires, after which the sequence stops and no analog line operation is accepted (Lockout) until the phone is placed
on hook for a provisionable time period (the Lockout Reset Timer defined in Table 4). After this Lockout Reset
Timer expires, the analog line MUST return to normal operation, responding to the next originator mode off hook
state according to Section 7.1.7, or in termination mode with appropriate (ring, caller ID, etc.) signaling.

7.1.4.5 Feature Data

Table 4 summarizes the feature data elements defined to support implementation of the basic call feature.
Table 4 - Basic Call Feature Data
Data Type Scope Stored Written Read Config.Server

by by by Requirement
Digit map Digit Map Per public user ID Config. Config. UE Mandatory
Server Server
Preferred network codec list List, Textual Per public user ID Config. Config. UE Mandatory
Server Server
Digit Map Variable Variable length array Per public user ID Config. Config. UE Mandatory
of Digit Map Variable Server Server
entries
Digit Map Variable Character string Per public user ID Config. Config. UE Mandatory
entry.Name identifying the Server Server
variable name.
Digit Map Variable Character string Per public user ID Config. Config. UE Mandatory
entry.Value identifying the Server Server
variable value.
BYE Delay Integer (seconds) Per network Config. Config. UE Mandatory
Server Server
Origination Mode Dial Tone Integer (seconds) Per network Config. Config. UE Mandatory
Timer Server Server
Origination Mode Long Integer (seconds) Per network Config Config UE Mandatory
Interdigit Timer Server Server
Termination Mode Off-Hook Tone Per network Config. Config. UE Mandatory
Error Signal Server Server
Termination Mode Error Integer (seconds) Per network Config. Config. UE Mandatory
Signal Timer Server Server
Permanent Sequence Tone 1 Tone Per network Config. Config. UE Mandatory
Server Server
Permanent Sequence Timer 1 Integer (seconds) Per network Config. Config. UE Mandatory
Server Server
Server Server
Server Server
Server Server
Server Server
Server Server
Server Server
Lockout Reset Timer Integer (seconds) Per network Config. Config. UE Mandatory
Server Server
Non-Emergency media DSCP Integer (range of Per Network Config. Config. UE Mandatory
Value 0..63) Server Server
Override NOTIFY Rejected Boolean Per Network Config. Config. UE Mandatory
Default: false Server Server
7.1.4.6 Feature Interactions

Please see each feature section for feature interactions with basic calls.

7.1.4.7 Call Flows

The call flows in this section illustrate basic call scenarios. The call flows are not normative, so if there is a
discrepancy between the text requirements and these call flows, then the text requirements take precedence.
Figure 1 illustrates a call from one UE to another UE where the call is answered.
PacketCable
Phone UE Network UE Phone
“A” “A” "B" “B”
Off-hook
Dial Tone
Digits
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing Off-hook
Ringback
200 OK
Tone
200 OK
ACK
ACK
Two-way communications
On-hook
BYE
BYE
Disconnected
200 OK BYE
200 OK BYE
On-hook
Figure 1 - Basic Call - On-Net to On-Net

Figure 2 illustrates a call from one UE to another UE where the call is not answered. A provisionable timer (defined
in Table 14) is used on the called UE to decide when to stop ringing and send back an error response to the caller.
PacketCable
“A” “A” "B" “B”
Off-hook
Dial Tone
Digits
INVITE
INVITE
Power
Ringing
180 Ringing
(No answer)
180 Ringing
Ringback Stop
Tone 480 ringing
Temporarily
480
Unavailable
Temporarily
Unavailable
ACK
On-hook ACK
Figure 2 - Basic Call - On-Net to On-Net No Answer
Figure 3 illustrates a call from one UE to another UE where the called UE is busy (on an active call), assuming that
call waiting is not applied at the called UE.
PacketCable
“A” “A” "B" “B”
Off-hook (B already engaged in call…)

Dial Tone
Digits
INVITE
INVITE
486 Busy
486 Busy
Busy Tone
ACK
On-hook ACK
Figure 3 - Basic Call - On-Net to On-Net Busy, Call Waiting Not Applied

Figure 4 illustrates a call from a UE to a phone on the PSTN network.
PacketCable Interconnect
Phone UE Network & PSTN Phone
“A” “A” “B”
Off-hook
Dial Tone
Digits
INVITE
INVITE
Power Ringing
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Ringback Tone
Off-hook
200 OK
200 OK
ACK
ACK
On-hook
BYE
BYE
Disconnected
200 OK BYE
200 OK BYE
On-hook
Figure 4 - Basic Call - On-Net to PSTN Off-Net

Figure 5 illustrates a call from a phone on the PSTN network to a UE (on the PacketCable network).
Phone UE Network & PSTN Phone
“A” “A” “B”
Off-hook
Dial Tone
Digits
INVITE
INVITE
Power
Ringing
180 Ringing
Off-hook 180 Ringing
200 OK Ringback Tone
200 OK
ACK
ACK
On-hook
BYE
BYE
Disconnected
200 OK BYE
200 OK BYE
On-hook
Figure 5 - Basic Call - PSTN Off-Net to On-Net
7.1.5 Held Media

There are a number of service capabilities defined in this specification that require an active bi-directional media
stream to be held. The media stream may be held by means of network signaling or it may be locally held by the
device "initiating" hold. The UE determines the media hold mechanism (local versus network signaling) by means
of configuration data as defined in Section 7.1.5.2.
When the UE is making use of network signaling to indicate hold then a held media stream is defined to be a
negotiated (via the SIP SDP offer-answer procedures as defined in [RFC 3264]) unicast media stream between two
parties where the offer-answer exchange between the parties results in a negotiated directionality attribute of
inactive. Where one of the parties is a UE not conformant to this specification, the media attributes may be
negotiated to a value other than inactive.
This specification assumes that there is only a single negotiated audio media stream between the two parties; support
for multiple negotiated active media streams (that is, additional audio, video, image, etc.) is out of the scope of this
specification.
When the UE is making use of local hold then a held media stream is one whereby the UE stops sending RTP
packets to the far end and squelches received RTP packets. RTCP continues to be exchanged.

7.1.5.1 Feature Execution

The UE MUST implement all the SDP requirements defined in [RFC 4566], including all the mandatory
requirements and all the recommended ("should") requirements unless otherwise noted in this section.
While the requirements detailed are written with reference to the interaction between UEs, they MUST apply
equally to any PacketCable components between which an INVITE initiated SIP dialog can be established.
In the procedures defined within this section reference is made to the 'controlling UE' and the 'held UE'. The
'controlling UE' is the party in the call that initiates the hold action; the 'held UE' is the party in the call being held
by the 'controlling UE.'
A dual-hold state is where both parties have each placed the other 'on hold'.
The initiation of media hold actions depend on the value of the 'Local Hold' configuration value defined in Section
7.1.5.2. A UE that is configured for 'Local Hold' (configuration value is set to 'true') MUST initiate media hold using
the procedures defined in Section 7.1.5.1.8. A UE that is configured for 'Network Signaled Hold' (configuration
value is set to 'false') MUST initiate media hold using the procedures defined in Section 7.1.5.1.1.
7.1.5.1.1 Actions at the UE initiating network hold
A controlling UE what wants to place a media stream "on hold" MUST offer updated SDP to the other media
endpoint with an attribute of a=inactive in the media description block.
A controlling UE that wants to place a media stream "on hold" MUST NOT set the connection information of the
SDP to a null IP address (for example, it MUST NOT set the 'c=' connection line to c=IN IP4 0.0.0.0).
A controlling UE that wants to place a media stream "on hold" SHOULD locally mute the media stream.
When the 'held UE' wishes to place the other party on hold, the UE MUST adhere to the requirements detailed
within this section.
7.1.5.1.2 Actions at the UE initiating network hold on receiving a hold 'answer'
In response to offering a "hold" SDP, a controlling UE will receive a corresponding answering SDP. If this
answering SDP contains an a=inactive attribute in either the media block equating to that being held or the session
level, then the hold action has been successfully completed.
If no directionality (these being sendrecv, sendonly, recvonly, inactive) attribute is received either in the answering
SDP's media block or the session level of the SDP; or a directionality attribute other than a=inactive is received, then
the recipient of the hold offer SDP is not conformant to either this specification or [RFC 3264]. If the recipient of
the hold offer SDP is not conformant to either this specification or [RFC 3264] as indicated by the answering SDP,
and if the controlling UE is operating using IPv4, then the controlling UE SHOULD offer an updated SDP to the
other party that contains a connection data line in the media block of the SDP set to c=IN IP4 0.0.0.0 (as required by
[RFC 2543]). Reception of an answering SDP means that the hold action has been successfully completed.
7.1.5.1.3 Actions at the UE receiving the hold offer
When a UE receives an offering SDP with an attribute of a=inactive in the media block (placing the media stream
"on hold"), then the UE MUST answer with an updated SDP and include an SDP media attribute of a=inactive in the
media description of the answer SDP equating to the offered held media.
When a UE receives an offering SDP with an attribute of a=inactive in the media block (placing the media stream
"on hold"), then the UE MUST NOT set the connection data of the SDP to c=0.0.0.0.
A held UE SHOULD provide comfort noise locally to the subscriber. Comfort noise is artificial background noise
used to fill the silence. The exact definition of comfort noise is out of scope for this specification.
7.1.5.1.4 Actions at a UE receiving a hold offer from a UE not conformant to this specification
A number of variations within SIP implementations exist for how the holding of a media stream should be signaled.
A UE that receives an offering SDP that does not conform to this specification needs to respond in a manner
compatible with the method invoked by offering party.

If the UE receives an offer SDP with an attribute of a=sendonly in the media block, then the UE MUST answer with
an updated SDP that includes an attribute of a=recvonly in the media block of the answer SDP equating to the
offered held media.
If a UE receives an offer SDP offer with a media attribute of a=sendonly, the UE SHOULD monitor the received
RTP packets and if no far-end media payload is provided, the UE SHOULD provide locally generated comfort
noise to the subscriber in order to simulate a held call.
If in addition to an attribute of a=sendonly the offer SDP contains connection data set to c=IN IP4 0.0.0.0 and the
UE is operating using IPv4, then the UE MUST include connection data of c=IN IP4 0.0.0.0 in the answering SDP.
If the UE receives an SDP offer with no directionality attributes but connection data set to c=IN IP4 0.0.0.0 and the
UE is operating using IPv4, then the UE MUST answer with an updated SDP to the offering party and include
connection data of c=IN IP4 0.0.0.0 in the answering SDP.
If the UE receives an offer SDP with no directionality attributes but connection data set to c=IN IP4 0.0.0.0 and the
UE is operating using IPv4, then the UE SHOULD provide comfort noise locally to the held subscriber.
7.1.5.1.5 Actions to ensure media keep-alive
When a media stream has been placed on hold via the mechanism defined in this section, no RTP packets are sent
between the two UEs as the directionality attribute negotiated is 'inactive'. However, as the media path between the
UEs may traverse components such as NATs and/or firewalls, connectivity of the media path needs to be
maintained. Media connectivity, however, is maintained through UE conformance to the requirements in
[PKT 24.229].
7.1.5.1.6 Actions on retrieval of media
When the controlling UE wishes to retrieve or resume bi-directional media with the held UE, it MUST send an
updated offer SDP with an attribute of a=sendrecv in the media block being resumed. A held UE not in a dual-hold
state that receives an offer SDP with an attribute of a=sendrecv MUST respond with an updated answer SDP with an
attribute of a=sendrecv in the media block being resumed. When a UE that is in a dual-hold state receives a new
offer SDP to retrieve the media, then the UE MUST respond with an updated answer SDP with an attribute of
a=inactive in the media block of the answer SDP equating to the offered retrieved media.
7.1.5.1.7 RTCP Requirements While On Hold
As noted in [RFC 3264], media directionality has no impact on any negotiated RTCP stream. Thus, RTCP MUST
continue to be transmitted to and/or from a UE that is on-hold if RTCP has been negotiated for this session.
7.1.5.1.8 Actions at the UE initiating Local Hold
A controlling UE that wants to place a media stream on local hold does not invoke any SIP signaling with the other
media endpoint. The controlling UE MUST stop the sending of RTP packets to the other media endpoint.
A controlling UE that wants to place a media stream on local hold SHOULD locally mute the media stream.
A controlling UE that has initiated local hold MUST NOT play out any received RTP packets to the user. The
discarded RTP packets are still counted for purposes of reporting statistics.
A controlling UE that locally holds a media stream MUST conform to any media keep-alive requirements in Section
7.1.5.1.5. A controlling UE that locally holds a media stream MUST conform to RTCP requirements in Section
7.1.5.1.7.

Table 5 summarizes the feature data items that are defined to support the Held Media feature.
Table 5 - Held Media Feature Data

Local Hold Boolean Per public user identity Config. Config. UE Mandatory
Server Server


See the individual service description sections of this specification for details on the use of held media and any
interactions that are present.
7.1.5.4 Call Flows

The call flows in this section illustrate call hold scenarios. The call flows are not normative, so if there is a
discrepancy between the text requirements and these call flows, then the text requirements take precedence. All of
the call flows make use of re-INVITEs to provide the updated SDP for the hold and retrieval actions. This is purely
illustrative; an UPDATE method may also be used.
Figure 6 illustrates the holding of an existing bi-directional unicast media stream.
PacketCable
“A” “A” "B" “B”
Active Call
Flash
INVITE
SDP: a=inactive
INVITE
SDP: a=inactive
Comfort
Noise
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Held Media
Comfort Noise is only

applied when applicable. It
should not be applied when
sendonly/recvonly attribute
negotiation is used.
Figure 6 - Sample Held Media Message Flow

Figure 7 illustrates the use of a fallback by a UE using IPv4 to [RFC 2543] defined hold when the initial hold
attempt fails because the 'held UE' does not understand the a=inactive directionality attribute.
PacketCable
“A” “A” "B" “B”
Active Call
Flash
INVITE
SDP:a=inactive
INVITE
SDP:a=inactive
200 OK
(no attribute)
200 OK
(no attribute)
ACK
ACK
UE “A” re-offers
INVITE
using RFC2543
SDP:c=IN IP4 0.0.0.0
defined “hold” INVITE
SDP:c=IN IP4 0.0.0.0
Comfort
Noise
200 OK
200 OK
ACK
ACK
Held Media
Figure 7 - Sample Held Media Message Flow - IPv4 Mode UE Fallback to RFC2543 Defined Hold
Figure 8 illustrates the retrieval of an existing held unicast media stream.
PacketCable
“A” “A” "B" “B”
Held Media
Flash
INVITE
SDP:a=sendrecv
INVITE
SDP:a=sendrecv
200 OK
SDP:a=sendrecv
200 OK
SDP:a=sendrecv
ACK
ACK
Active Call
Figure 8 - Sample Held Media Message Flow - Retrieval of Held Media

Figure 9 illustrates a message flow for the transition to a dual-hold state.
PacketCable
“A” “A” "B" “B”
Active Call
Flash
INVITE
SDP: a=inactive
INVITE
SDP: a=inactive
Comfort
Noise
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Held Media
Flash
INVITE
SDP: a=inactive
INVITE
SDP: a=inactive
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Dual Hold
Figure 9 - Held Media - Transition to Dual-Hold
Figure 10 illustrates a message flow when one party in a dual-hold state retrieves the media.
PacketCable
“A” “A” "B" “B”
Dual Hold
Flash
INVITE
SDP:a=sendrecv
INVITE
SDP:a=sendrecv
B is still locally
held, so “holds” A
200 OK
SDP:a=inactive
200 OK
SDP:a=inactive
ACK
ACK
Held Media
Figure 10 - Held Media - Retrieval by One Party When in Dual-Hold

7.1.6 Announcements
Users are alerted to some network conditions or states by network-initiated announcements. Announcements could
be informational tones or messages played to end users in response to events that occur in the network. These
announcements could be stored and played locally by the UE to the end user, or they could be received by the UE
from a network stream between the UE and a media server.
For the UE, an announcement is defined as the application of an analog signal to the two wire telephony port (RJ-11
analog telephone interface) to provide the end user or device information with respect to a call request or status
change. These announcements could be analog audio tones or analog voice or music announcements.
Announcements and tones could be provisioned on the UE or on a network announcement source. When a UE needs
to present an announcement from a network announcement source, the audio format is negotiated between the UE
and the source of the announcement content.
Acoustic or visual announcements by the UE are outside of the scope of this document.
7.1.6.1 Feature Description

North American telephony standards define minimum analog line announcements as a set of tones that are required
for specific services or connection status (reference [GR 506], [GR 674], and [GR 675]).
In addition to these announcement tones, the UE MAY also be capable of requesting audio announcements to be
applied to the analog line from a network announcement application server. The Telcordia [BR 780] Tones and
Announcements specification defines text for some possible announcements.
The UE MAY provide audio announcements from an internal, provisioned, audio application server to the analog
line.
In addition to the analog line signals, the UE could present acoustic or visual displays equivalent to the tone and
voice announcements. Acoustic or visual announcements by the UEs are outside of the scope of this document.
Therefore, there are two types of announcements in PacketCable: tone and audio announcements.
The UE supports the analog line tones listed in the referenced Telcordia, ETSI, or ITU standards for analog
telephony services of the target market, physical location or operator directive within the constraints of this section.
The specific tones are provisioned and map to the tone-identifiers defined in this document.
Audio announcements could be presented by network announcement sources or by audio provisioned locally to the
UE. Audio announcements optionally could be provided with a language preference provisioned by subscriber. The
use of a local or network announcement source is determined by the UE at the time of announcement.
Local (UE-resident) audio announcements could be used to notify the user that the network is unavailable or is not
capable of supporting analog line connections.
Network Application Servers provide announcements that are used to notify the user of network level services or
requirements. The use of a network server minimizes access device memory requirements and allows for
multilanguage support based on the end-user service profile. In general, the procedures described in [TS 23.218]
apply to network announcements, as further described in this section.
7.1.6.2 Activation and Deactivation

The routing of the session requests to an announcement application server is achieved using one of the following
methods:
• The application server re-INVITEs the UE to connect the RTP session to the application server.
• The application server redirects the UE to the announcement server using a 3xx Response Code (Reference
7.1.11, Response Codes) during session signaling.
• The application server specifies a network hosted audio treatment using the alert-info header in a response
message, allowing the UE to initiate a session. The alert-info header could contain a fully-specified URL.

• The application server sends a 183 session progress response and provides an early media session description
that directs the UE to the required announcement.
• If the application server does not provide the announcement, the UE MAY initiate any announcement treatment
per the UE provisioning or capabilities, including application of tones.
In response to the INVITE, the AS or Media Server SHOULD query the HSS (Home Subscriber Server) to
determine if there are any Subscriber specific requirements (such as language selection) and then provide the UE
with the appropriate announcement.
When the announcement is to be provided by a SIP enabled media server in the network which is conformant to
[RFC 4240], the announcement addresses supplied in alert-info headers and contact headers MUST comply with the
annc-url syntax defined by [RFC 4240], SIP Media Services. For example:
sip:annc@ms2.example.net;play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net;play=file://server.example.net//geminii/yourHoroscope.wav
When the announcement is to be provided by a media server in the network that is accessible via other URI
schemes, the announcement address provided by the Application Server could be a URL. A UE supporting network-
based announcements MUST support the file://, sip: and HTTP: URI types. Also, a UE MAY support the FTP
URI. The handling of URL at the UE is defined below:
file:/// Indicates that the UE SHOULD look for the announcement media in local storage and play
locally.
sip: Indicates that the UE SHOULD pass the prompt_url to the configured Media Server in an INVITE
request to establish an RTP session for the announcement. Format is specified in [RFC 3261].
ftp: Indicates that the UE SHOULD download the announcement media from remote storage to play
out locally. The UE MAY look for cached announcement media in local storage. URI format is
specified in [RFC 3986].
http: Indicates that the UE SHOULD download the announcement media from remote storage to play
out locally. The UE MAY look for cached announcement media in local storage URI format is
specified in [RFC 3986].
If the Application Server provides an announcement address using any other URL scheme, the UE MAY forward
the announcement address to the configured Media Server in an INVITE request to establish an RTP session for the
announcement. Otherwise, the UE applies the locally provisioned tone or announcement appropriate to the request
or response code.
The UE MAY be provisioned to map SIP response codes to announcements. However, to minimize the complexity
of the UE, the UE MAY use the SIP Response Code to format the prompt_url in the INVITE message that it sends
to the network announcement source. The format of the prompt_url is:
sip:annc@<operator_announcement_domain>
play=file://<announcement_network_path>/<response_code>.<announcement_mime_type>
The UE needs an operator announcement domain, network path and mime type to allow construction of the
prompt_url using this syntax.
7.1.6.3 Tone Announcement Identifiers

Network initiated tone announcement addresses conveyed in the alert-info header for UE internally stored or
generated tones uses the URI format file:///PacketCableRST/<tone-identifier>, where the <tone-identifier> element
is per Table 6.
Table 6 - Tone Announcement Identifiers
Meaning / Description < tone-identifier > Considerations

DTMF tones 0-9,*,#,A, B,C,D DTMF tones (0-9,*,#,A, B,C,D)
Busy tone bz
Confirmation tone cf

Meaning / Description < tone-identifier > Considerations

Dial tone dl
Message waiting indicator mwi
Off-hook warning tone ot Receiver Off Hook Tone (ROH Tone) sometimes referred to as “Howler” tone.
Distinctive ringing and ring r0, r1, r2, r3, These tone-identifiers may be used for distinctive caller ring back tones. They
back tones (0..7) r4, r5, r6 or r7 may also be used for distinctive power ring to the called party.
Ringing rg The value for rg is as defined for distinctive ringing pattern 1. These tone-
identifiers may be used for distinctive caller ring back tones. They may also be
used for distinctive power ring to the called party.
Reorder tone ro
Ringsplash rs Also known as "Reminder ring" is a burst of ringing that may be applied to the
physical forwarding line (when idle) to indicate that a call has been forwarded
and to remind the user that a Call Forwarding subfeature is active.
Ring back tone rt
Stutter dial tone sl Also called Recall Dial Tone
Call waiting tones wt1, wt2, wt3, wt4
DTMF tones wildcard X The DTMF tones wildcard matches any DTMF digit between 0 and 9.
No tone (i.e., silence) nt
Open interval osi When this is used as one of the permanent sequence tones for extended off-
hook processing treatment, the corresponding timer may be overridden by
device specific requirements.
Network generated tones or Network directed tone generation could use the same <tone-identifier> convention in
the alert-info header for signaling of the desired tone.
7.1.6.4 Audio Announcement Identifiers

PacketCable supports the following basic categories of audio announcements, as described in [BR 780]. All network
announcements, whether provisioned locally on the UE or referenced to resources in the network, are identified by
an announcement identifier. Table 7 describes announcement categories and conditions and the associated
Announcement Identifiers.
Table 7 - Audio Announcement Identifiers
Category/Condition Announcement Announcement

Identifier
Reorder/All Circuits Busy "Your call cannot be completed at this time. Please hang up and try Annc-Reorder
again later."
Reorder/Protocol Errors "Your call cannot be completed at this time. Please hang up and try Annc-Reorder
again later."
Vacant Code/No Route "Your call cannot be completed as dialed. Please check the number Annc-Vacant
and try again."
Intercept/Number Change Implementation dependent Annc-NumberChg
Intercept/Disconnected Number "The number that you have reached has been disconnected. Please Annc-Disconnected
check the number and try again."
Intercept/Nonworking Number "The number that you have reached is not in service. Please check Annc-NonWorking
the number and try again."
Intercept/Temporary Suspension Implementation dependent Annc-TempSusp
Intercept/Incoming Call Restriction "The number you have reached can not accept your call at this time. Annc-Decline
Please hang up and try again later."
No Circuit "Your call cannot be completed at this time. Please hang up and try Annc-NoCircuit
again later."
Ineffective/Dialing Irregularity "Your call cannot be completed as dialed. Please check the number Annc-DialError
and try again."

Category/Condition Announcement Announcement

Identifier
Ineffective/Screened Line Access Implementation dependent Annc-AccessDenied
Denial
As described previously, the UE MAY be provisioned to identify, locate, and play announcements based on the
presence of Alert-info headers or Contact headers provided by other network elements in response messages, or by
the SIP response to announcement mapping table specified in Table 9 if no announcement is requested. When a SIP
response is received for which no explicit action has been specified (i.e., no Alert-info headers or Contact header is
present and no entry exists for the received SIP response in the SIP response to announcement mapping table
specified in Table 9), the UE MUST provide the default treatment specified in Table 8, unless this treatment is
overridden by another section of this specification.
Table 8 - Announcement Map - Default SIP Response Code Mapping
Received SIP Response Code UE Announcement

486 Busy Tone
487 No Tone (silence)
600 Busy Tone
Any other 4xx, 5xx, or 6xx response (other than 401 or 407) Reorder Tone
The UE MUST use the received response code to determine whether or not an announcement has been provisioned,
by examining the Announcement Map specified in Table 9 for a matching entry. When there is a matching entry,
the UE MUST retrieve the Announcement Identifier from the entry and use this to retrieve the Announcement URI
from the Announcement Media Map specified in Table 9. The Announcement URI MAY specify a locally stored
announcement, tone, or bell cadence by using the file syntax, in which case the UE MUST look up the alert media in
its Local Media Table (see Table 10).
Figure 11 illustrates this process.
Figure 11 - Announcement Media Mapping

When there is no entry in the Announcement Map for a response code, the UE MAY construct a URI following the
procedure described in Section 7.1.6.2.
7.1.6.5 Management of Announcement Media Cache

As described in Section 7.1.6.2, the UE MAY cache announcement media fetched using FTP and HTTP in local
storage. Caching announcement media locally provides obvious performance advantages, but when announcement
media is locally cached, there is no assurance that the cached version is the most current. Even though the
announcements typical of a telephony system probably do not change very often, the UE should not keep
announcement media cached indefinitely.
HTTP deals with the aging of cached resources with headers that allow clients and servers to specify expirations.
The UE can make use of these protocol elements. FTP does not have similar protocol elements. The UE also can
control cache contents independently of the protocols.
UE Cache Control
If the UE caches network announcement media, then the UE MUST support a configurable parameter for the
maximum-age of any cached announcement media. This one parameter applies to all cached media fetched by FTP
and HTTP. When the UE needs to access cached announcement media that has aged beyond the configured
maximum-age for cached resources, the UE MUST fetch it from the network media server. The UE MAY discard
cached announcement media that has aged beyond the configured maximum-age for cached resources.
HTTP Cache-Control
HTTP provides the Expires header and the Cache-Control header to help control cache contents. Media Servers
SHOULD use the HTTP Expires header to indicate how clients should treat the announcement media. Media
servers MAY use the cache-response-directive of the Cache-Control header for this purpose. If the UE caches
network announcement media, then the UE MUST NOT use the Cache-Control header in its HTTP requests. The
UE manages its cache contents for announcement media retrieved by HTTP for specific values of the Expires header
and Cache-Control header as follows.
Expires Header and Max-Age Directive
When the media server specifies the Expires header or max-age directive in a Cache-Control header, and the UE is
caches network announcement media, then the UE MUST compare the expiration time/max-age received for the
announcement media with the configured maximum-age for its media cache. If the resource's expiration/max-age is
less than the cache's maximum-age, the UE MUST invalidate the resource after it has aged as defined by the server.
If the media server provides both an Expires header and a max-age directive, the UE MUST apply the more
restrictive value.
No-Store Directive
When the media server specifies the no-store directive in a Cache-Control header, and the UE caches network
announcement media, then the UE MUST NOT store the announcement media in its cache. After playout, the
media MUST be discarded.

This section describes various scenarios for network initiated announcements. Each scenario starts with the UE
originating a call using basic SIP signaling messages. The scenarios describe the ways network-initiated
announcements are executed, given that the network elements could initiate announcements in several ways.
Announcement Address Not Provided by Application Server
The Application Server may not support any audio announcement capabilities for some situations that can be
handled by other means. The UE responds by playing the locally provisioned tone, a local announcement or a
network announcement, depending on its provisioning:
• Locally Provisioned Tone. In the absence of any network announcement provisioning, the UE MUST play the
locally provisioned tone defined for the response code received.

• Local Announcement. If the UE was provisioned with announcement audio media for the received SIP response
code, the UE MUST play this audio announcement file.
• Network Announcement. If the UE is provisioned with network announcement path and type, the UE MUST
attempt to play the provisioned announcement by response code by constructing a prompt_url for the
announcement address and sending an INVITE to the provisioned network announcement source to establish a
media session.
• The network announcement source plays the required announcement. When the playing of the announcement is
complete, the network announcement source ends the media session by sending a BYE to the UE.
• If the announcement source rejects the UE INVITE message (for example, the announcement source can not
map the prompt-url constructed by the UE to a valid announcement media), the UE MUST apply the locally
provisioned tone or announcement appropriate to the request or response code.
Announcement Address Provided by Application Server in Alert-info Header
The Application Server may provide an announcement address in an alert-info header returned with a final response
message.
• The application server provides the UE with the announcement address as a prompt_url in the alert-info header
supplied with a response message.
• The UE originates an INVITE to the provisioned network announcement source to establish a media session.
• The UE performs normal negotiation with the network announcement source to establish the media session.
• The network announcement source plays the required announcement.
• When the playing of the announcement is complete, the network announcement source ends the media session
by sending a BYE to the UE.
Announcement Address Provided by Application Server in Contact Header
This is based on restrictions on header in some SIP requests and responses. The Contact header can be used in places
that alert-info can not be used, and is more appropriate when the AS is making use of an alternate server for a media
session rather than when the AS is directing the UE to playout locally.
The Application Server may provide an announcement address in a Contact header returned with a non-2xx final
response message.
• The application server provides the UE with the announcement address in the Contact header supplied with a
response message.
• The UE originates an INVITE to the provisioned network announcement source to establish a media session.
• The UE performs normal negotiation with the network announcement source to establish the media session.
• The network announcement source plays the required announcement.
• When the playing of the announcement is complete, the network announcement source ends the media session
by sending a BYE to the UE.
Announcement Address Provided by Application Server in Redirect Response
The Application Server may provide an announcement address in a Contact header returned with a redirect response
message. The UE proceeds as described in the preceding section.
Announcement Provided by Application Server in Early Media Response
The Application Server may provide the audio announcement itself, and reflect this by returning a 183 Call Progress
response message with SDP to the UE. The UE responds by negotiating the media session with the server and
playing the audio supplied by the server. In this case, no final response has been generated. When the server network
announcement source has completed playing audio, the server source sends a final response message of 487 Request
Terminated.


Table 9 summarizes the feature data elements defined to support implementation of the Announcement feature.
Table 9 - Announcement Feature Data

Announcement Resource xsd:anyURI (for media server) Per network Config. Config. AS, Mandatory
Server Server UE
Announcement Domain Character string Per network Config. Config. AS, Mandatory
(Domain name) Server Server UE
Announcement Path Character string Per network Config. Config. AS, Mandatory
(URI) Server Server UE
Announcement mime type RFC2045 Per network Config. Config. AS, Mandatory
Server Server UE
Announcement map Variable length array of Per network Config. Config. UE Mandatory
Announcement map entries Server Server
Announcement map Integer Per network Config. Config. UE Mandatory
entry.Response code Server Server
Announcement map entry Character string Per network Config. Config. UE Mandatory
Announcement URI identifying uri for response code Server Server
Announcement media map Variable length array of Per network Config. Config. UE Mandatory
Announcement Media Map entries Server Server
Announcement media map Character string Per network Config. Config. UE Mandatory
entry.Announcement identifying the Announcement Server Server
Identifier Identifier
Announcement media map Character string Per network Config. Config. UE Mandatory
entry.Announcement URI identifying URI for Announcement Server Server
Identifier
Announcement media Integer (Seconds) Per Network Config. Config. UE Optional
cache maximum-age Server Server
Table 10 summarizes the feature data elements defined to support provisioning of local media on the UE.
Table 10 - Local Media

Local Media Character string Per network Config. Config. UE Mandatory
Table Variable length array of Media entries Server Server
Media.URI Character string Per network Config. Config. UE Mandatory
File:/// URI identifying locally stored media Server Server
Media.Type Media Type (from set of bell cadence, tone Per UE UE UE UE Not Applicable
generator specification, or audio file)
Media.Data The actual media data, format depends on Per UE UE UE UE Not Applicable
Media.Type
Local media types supported are audio files, ringing signals or tones. Audio files are identified by the file type (for
example, mp3, wav) are implementation dependent. Ringing signals and tones are defined by Telcordia, ETSI or
ITU standards such as [BR 780] and [GR 506].


To the extent that features need announcements to be played, each feature invocation initiates the announcement
processing.
Announcement processing interaction with the UE is not recorded in the last outgoing call memory or last incoming
call memory (used for recording the most recently placed call and the most recently received call, respectively), in
order to protect the integrity of the Auto Recall, COT, and Auto Callback features.
7.1.6.9 Support for Language Preference (Optional)

PacketCable may optionally support user language preference. This support is provided through several
mechanisms:
• The UE MAY provide hints of language preference to network elements using the locale feature tag in the
Contact header in basic call signaling that establishes dialogs;
• Servers that support network-initiated announcements MAY use hints received from UE or language
preferences provisioned in the subscriber's profile to play an announcement in the subscriber's preferred
language;
• Servers that provide announcement addresses to UE MAY provide multiple language choices to allow the UE to
select the most appropriate presentation.
These capabilities are described in the following subsections.
7.1.6.9.1 Syntax of Announcement Addresses for Language Preferences
UEs indicate language capabilities to application servers using one or more Contact headers in all dialog-
establishing SIP requests and responses. Application servers indicate language preference by either directing the UE
to the appropriate announcement address as described in Section 7.1.6.2, or by providing an [RFC 4240] compliant
prompt_url with locale parameter in a Contact header.
When the UE includes language preferences in Contact headers, it MAY include a Contact header with a locale
parameter listing the preferred languages, using the format of local tags as defined by [RFC 3066]. For example:
Contact: <sip:3035551212@ms2.example.net;user=phone; \
locale="en-us,es-us,fr-ca">
When the application server adds a locale parameter to the prompt_url, the application server also MUST use locale
tags as defined by [RFC 3066]. For example:
Alert-info: <sip:annc@ms2.example.net; \
play=http://audio.example.net/<response_code>.g711;locale=en-us>
When the UE receives an error response without any indication for network announcement, with or without
language preference, and if the UE is configured appropriately, the UE MAY construct a prompt_url for a network-
based announcement using the received response code. Using response codes to the Announcement Server to "map"
to the desired announcements MAY be represented as any one of the following:
Contact: <sip:annc@ms2.example.net; \
play=http://audio.example.net/<response_code>.g711
play=http://audio.example.net/<response_code>.g711;locale=en-us>
play=http://audio.example.net/<response_code>.g711;locale=es-us>
play=http://audio.example.net/<response_code>.g711;locale=fr-ca>
If an application server redirects the UE to an announcement server using a 3xx redirect, then the application server
MAY provide multiple contacts to the UE, allowing the UE to pick which of the contacts to use based upon its
language preferences. For example, an application server could provide all of the above contacts to the UE.

7.1.6.9.2 Behavior of UE for Language Preferences

The UE MAY be provisioned to indicate one or more optional subscriber language preferences. When provisioned
for more than one language, the locally provisioned language MUST be configured.
The UE MAY use the provisioned language preferences to play the appropriate announcement in response to these
events:
Receipt of a basic SIP response message. When the UE receives a SIP response message that does not include any
indication of network announcement to be played, the UE constructs its INVITE for the announcement as described
in 7.1.6.6. To indicate a language preference, it SHOULD include a locale parameter as described in [RFC 4240].
Receipt of SIP re-INVITE, redirect or response message with announcement address. When the UE receives a SIP
re-INVITE, redirect or response message with one announcement address in the form of a prompt_url, per
[RFC 4240], the UE MUST process these messages as described in Section 7.1.6.2. If the UE is provisioned with a
language preference, and if the prompt_url does not contain a locale parameter, then the UE MAY update the
prompt_url to include a locale parameter for its configured (locally provisioned) language preference.
Receipt of SIP re-INVITE, redirect or response message with multiple announcement addresses. When the UE
receives a SIP re-INVITE, redirect or response message with multiple announcement addresses, the UE processes
the message as follows.
When the UE receives a SIP re-INVITE, redirect or response message with multiple announcement addresses and
the UE is not provisioned with language preference, then the UE MUST process the message as described in Section
7.1.6.2.
When the UE receives a SIP re-INVITE, redirect or response message with multiple announcement addresses and is
provisioned with language preference, then the UE MAY scan the offered announcement addresses, and reorder the
announcement addresses, placing its provisioned language preference first. When the UE does not support this
operation, the announcement address placed first by the AS is interpreted as the locally provisioned language
preference.
When the UE is processing a SIP response message, as with any announcement, after the UE has applied optional
language preference processing, the UE MAY play a locally stored announcement if this is otherwise consistent with
the announcement address.
7.1.6.9.3 Feature Data for UE Announcement Language Preference
Table 11 summarizes the feature data items that are defined to support the announcement language preference
feature.
Table 11 - UE Announcement Language Preference Feature Data
Data Type Scope Stored by Written by Read by Config.Server

Requirement
Language Character String Per public user ID Config.Server Config.Server UE Mandatory
7.1.6.9.4 Behavior of Application Server for Language Preference

All language preference support by network elements such as an Application Servers is optional. An Application
Server MAY indicate language preference in several ways:
• Language-specific Announcement Addresses:
Application Servers MAY provide language-specific announcements by simply redirecting the UE to the
appropriate announcement address, or providing the appropriate announcement address in the response
message. The method of determining the correct announcement address is application-dependent, and MAY
use the subscriber's profile or UE hints.

• Subscriber profile preference:
The Application Server MAY include Contact headers containing prompt_urls with locale parameters in SIP
response messages.
• Contact Headers:
Application Servers MAY include Contact headers in redirect and response messages to indicate language
preference. Each Contact header specifies an announcement address in [RFC 4240] prompt_url format, with
locale parameter, as previously described, in preference order. As with Accept-Language headers, the value of
the Contact header locale parameters MAY be derived from provisioning, from the subscriber profile, or from
UE hints. A UE indicates its language preference by including a locale parameter in its contact header.
7.1.6.9.5 Behavior of Network Media Server for Language Preference
A Network Media Server MAY store announcement media in multiple languages. When multiple languages are
supported, the Network Media Server selects the announcement media to play in one of the following ways.
Network Media Servers play announcements specified completely by the [RFC 4240] prompt_url received from an
Application Server or UE. Network Media Servers MAY select an announcement to play based on the locale
parameter received from the UE or the Application Server.
When the network Media Server completes playing an announcement, the network server's behavior depends on
whether it is an early media session. If the media session is not early media, the network Media Server ends the
session by sending a BYE to the UE. If the media session is early media, the network Media Server ends the session
by sending a 487 Request Terminated message to the UE.
7.1.6.10 Call Flows

The call flows are not normative, so if there is a discrepancy between the text requirements and these call flows,
then the text requirements take precedence.
Figure 12 illustrates a call flow involving an Application Server returning an error final response with an
announcement address specified in an alert-info header. In response, the UE sets up a session with a Media Server.

PacketCable
Phone UE Media Server
Network
“A” “A”
Off-hook F1
Dial Tone F2
Digits F3
INVITE F4
408 Request
F5
Timeout
ACK F6
INVITE F7
INVITE F8
200 OK F9
200 OK F10
ACK F11
ACK F12
Announcement F13
BYE F14
BYE F15
200 OK BYE F16
200 OK BYE F17
On-hook F18
Figure 12 - Media Serving - UE INVITE for Network Announcement
F5 408 REQUEST TIMEOUT UE <- SIP NETWORK
SIP/2.0 408 REQUEST TIMEOUT
play=file://operator.anncserver.net//audio/408.wav>
F7 INVITE UE -> SIP NETWORK
INVITE sip:annc@operator.anncserver.net;play=file:///408.wav SIP/2.0
Figure 13 illustrates an Application Server redirecting the UE to the Media Server. The underlying reason for the
redirect is not reflected in the response code. Instead, Application Server provides the reference to the appropriate
announcement in a Contact header.

PacketCable
Network
“A” “A”
OFF-HOOK F1
DIAL TONE F2
DIGITS F3
INVITE F4
380 ALTERNATE
F5
SERVICE
ACK F6
INVITE F7
INVITE F8
200 OK F9
200 OK F10
ACK F11
ACK F12
ANNOUNCEMENT F13
BYE F14
BYE F15
200 OK BYE F16
200 OK BYE F17
ON-HOOK F18
Figure 13 - Media Serving - Server Redirecting UE
F5 380 ALTERNATE SERVICE UE <- SIP NETWORK
SIP/2.0 380 ALTERNATE SERVICE

play=file://operator.anncserver.net//audio/408.wav>
INVITE sip:annc@operator.anncserver.net; \
play=file://operator.anncserver.net//audio/408.wav SIP/2.0

Figure 14 illustrates an Application Server simply connecting the UE to an Announcement Server using early media
SDP returned with a 183 Session Progress response.
PacketCable
Network
“A” “A”
Off-hook
Dial Tone
Digits
INVITE
INVITE
200 OK
183 with SDP
PRACK
200 OK PRACK
ACK
Announcement
BYE
200 OK BYE
487 Request
Terminated
ACK
On-hook
Figure 14 - Media Serving - Server Providing Announcement with Early Media

Figure 15 illustrates an Interactive Voice Response application in which the IVR server accepts spoken word from
the user and plays additional prompts by use of re-INVITE. This type of operation might also be invoked by an
Application Server that does not have announcement capability itself, and during processing of user interactions
needs to play an announcement.
PacketCable
Phone UE IVR Server AS
Network
“A” “A”
Off-hook
Dial Tone
Digits
INVITE
INVITE
200 OK
200 OK
ACK
ACK
Announcement
Audio Response
INVITE
200 OK
INVITE
200 OK
ACK
ACK
Announcement
BYE
BYE
200 OK BYE
200 OK BYE
On-hook
Figure 15 - Media Serving - Network Announcement by Re-INVITE from SIP Network

Figure 16 illustrates how a UE selects an announcement address from those offered by an Application Server. In this
example, assume that the UE has been provisioned with American English as its preferred announcement language.
PacketCable
Network
“A” “A”
Off-hook F1
Dial Tone F2
Digits F3
INVITE F4
408 Request
F5
Timeout
ACK F6
INVITE F7
INVITE F8
200 OK F9
200 OK F10
ACK F11
ACK F12
Announcement F13
BYE F14
BYE F15
200 OK BYE F16
200 OK BYE F17
On-hook F18
Figure 16 - Media Serving - UE INVITE for Network Announcement with Language Preference
F5 408 REQUEST TIMEOUT UE <- SIP NETWORK
SIP/2.0 408 REQUEST TIMEOUT

…
play=file://operator.anncsvr.net//audio/408.wav;locale="en-us,es-us,fr-ca">
INVITE sip:annc@ms2.example.net; \
play=file://operator.anncsvr.net//audio/408.wav;locale=en-us SIP/2.0

7.1.7 In-Service and Out-of-Service States

In the PSTN, dial tone indicates to the caller that he or she is connected to the network (in reality, connected to the
line card of the Class 5 switch). The many years of PSTN experience for most of us have led us to believe that no
dial-tone always means that the telephone is out-of-service. SIP UEs, however, have the intelligence and capability
to generate the majority of call progress tones locally, including dial tone. So dial tone could be provided regardless
of the network connectivity status.
Normal SIP UE operation would call for the registered SIP UE to locally generate dial-tone, then collect dialed
digits and use a previously provisioned digit map that directs the UE when to send and how to form an INVITE to
the network to begin establishing the desired session. Any success or failure indication would not occur until after
the initial INVITE was sent. If the UE was truly "unconnected" to the network, the UE could only interpret this
when no SIP response message was received from the INVITE. This would occur much later in the dialing sequence
and provides a significant departure from PSTN behavior.
The in-service and out-of-service feature described here provides UEs with the ability to reproduce a similar service
representation to subscribers as the one used in the PSTN: the dial-tone indication is provided to the user only if the
UE is in-service. That is, a dial-tone indicates that the UE is successfully registered with the PacketCable network;
furthermore, it is able to initiate sessions to the network (at least to the P-CSCF). Thus, there is no behavioral shift
required for users moving from traditional PSTN to PacketCable services.

A registered UE MUST indicate it is 'in-service' state if keepalive messages are being exchanged between the UE
and the STUN server located within the P-CSCF as defined in [RFC 5626]. This indication is in the form of the
dialtone, which is provided when the user goes off-hook. Otherwise, the UE assumes it is in the 'out-of-service' state.
The mechanism chosen to indicate UE connectivity to the SIP Network is derived from [RFC 5626], and it employs
"keep alive" messages between the UE and the STUN server located within the P-CSCF.
Figure 17 shows the UE connected to the P-CSCF through a NAT/Firewall. The STUN Server shown as an instance
in each P-CSCF is part of the PacketCable architecture to traverse NAT/Firewalls by creating multiple "service
flow" bindings between the UE and P-CSCF. The PacketCable approach to NAT traversal is described in [NFT TR].
These bindings are created when the UE registers. Since only the STUN server is employed by the in-service/out-of-
service feature, the entire ICE/STUN/TURN issues of NAT traversal are not discussed; only the necessary STUN
functionality is described. ICE is described in [RFC 5245] and TURN is described in [RFC 5766].
PacketCable STUN S-CSCF/

NAT/FW Server
P-CSCF
UE Registrar
Figure 17 - Functional Components for Determining In-Service/Out-of-Service State
[TS 23.228] includes requirements for supporting NAT and Firewall traversal. [PKT 24.229] provides procedures
related to signaling and media traversal of NAT and Firewall devices.
The keep-alive mechanism used to maintain the outbound connection from the UE to P-CSCF is described in
[RFC 5626]. The key concept of this draft is when the UE sends a REGISTER request to the Registrar (via the P-
CSCF); the P-CSCF can use the same connection for communication in the other direction (network toward the UE).
The draft is called "SIP outbound" because the UE initiates and maintains this connection (referred to as a "flow" in
the specification). The UE must also determine when a connection or flow has failed, hence the need for the keep-
alive messages.
The STUN protocol is used as a keep-alive mechanism so that one or more flows to the proxy (P-CSCF) and
registrar (S-CSCF) remain alive and connected to the SIP Network. It is assumed that the UE is registered with the

S-CSCF as described in [PKT 24.229]. As such, this mechanism provides a logical indication for the UE to
determine if it is appropriate to provide dial-tone when the user goes off hook.
When in the in-service state, the UE MUST provide the locally-generated dial-tone when the caller initiates a call
session by going off-hook or otherwise indicates that a call is being initiated.
Upon detecting and entering the out-of-service state, the UE MUST:
• Maintain currently active and established session.
• Terminate immediately any transient (not yet established, on-hold) session using basic call procedures to clear
the call.
While in the out-of-service state, the UE MUST:
• Prevent any new session creation by not providing dial tone when local user goes off-hook.
• Follow normal procedures due to local user activity other than going off-hook (e.g., if user hangs up on
established call, send BYE).
• Accept and process incoming SIP request normally (e.g., on receiving INVITE request to establish a new call)
and transition to in-service state.
The complete ICE/STUN/TURN NAT traversal process employed by PacketCable is beyond the scope of this
specification. This feature simply uses the keep-alive mechanism of STUN as an indicator of network connectivity.
Also not described here are the steps a UE would take to re-register once network connectivity has been lost.
The UE MUST NOT use the keep-alive mechanism defined in [RFC 5626] to determine the in-service/out-of-
service status if it is turned off by setting the feature data item in Table 12 to value of 1 ("off"). If the keep-alive
mechanism is turned off, the UE MUST behave as per the requirements for in-service state.
The UE MUST use the keep-alive mechanism defined in [RFC 5626] to determine the in-service/out-of-service
status if it is turned on according by setting the feature data item in Table 12 to value of 2 ("on"). If the keep-alive
mechanism is turned on, the UE can be in-service or out-of service state based on the requirements in this section. In
this case, the UE MUST ignore the indication (or lack thereof) in the 200 OK response to the REGISTER.
It the feature data item in Table 12 is set to value of 3 ("conditional"), the UE MUST either start the keep alive
mechanism (as described above) or not depending on the indication (or lack thereof) in the 200 OK response to the
REGISTER.

Table 12 summarizes the feature data items that are defined to support the in-service/out-of-service feature.
Table 12 - In-service/out-of-service Feature Data

Requirement
Keep alive setting Integer Per UE Config.Server Config.Server UE Mandatory
1 – off
2 – on
3 – conditional
(default)
7.1.8 UE Status Change

UE status change is the method of indicating to the network that the UE is available to make and receive calls.
Typically, UE availability is determined by the registration status of the UE as held by the S-CSCF. The registration
update mechanism is determined by the Border controlling elements of the Network. This is typically by accepting
REGISTER from the device with the subscriber's authorization information. For more detail on this process, please
refer to the PacketCable's 3GPP Security document [PKT 33.203].


Authentication of the UE is required for validation of the subscriber in the Network. This affects both the originating
and terminating service invocation. See [PKT 24.229] and [PKT 33.203] for the detailed requirements for
authentication. The UE MUST require a valid registration for origination for all features except for configuration.
The specification [PKT 24.229] defines the default registration duration. The Network may decide to change the
registration time for a UE. The mechanism for this is either via the Configuration Server or the last registration reply
from the Network.
• If the Registration Expiration (Table 13) has been configured on the UE through the Configuration Server, the
UE MUST use it as the expiration duration requested for any non-refresh registration attempt.
• Upon receipt of a registration response indicating that the requested expiration interval is too brief (a 423
response), the UE MUST use the minimum registration expiration interval value provided in the 423 response
only for the current registration session. The UE MUST NOT use the duration received in the registration
response upon the next non-refresh registration attempt.

In addition to registration data required by [PKT 24.229], the feature data shown in Table 13 is defined to support
implementation of the UE Status Change feature.
Table 13 - UE Status Change Feature Data

Requirement
Registration Expiration Integer (in seconds) Public Identity Config.Server Config.Server UE Mandatory
7.1.9 Early Media

Early media is media exchanged before the call's full dialog is established, as described by [RFC 3960]. The media
stream may be one or two-way. The usual example of one-way media is ringback: A calls B, A hears ringtone from
B via early media even before the SIP dialog is confirmed (which happens when B answers the call). An example of
two-way media is solicitor blocking: A calls B, A is connected to an application server for collection of a greeting.
The media stream is bi-directional; one stream to the application server for greeting record, the other from the
application server to request the greeting. In both examples the call is not considered established as the SIP dialog
initiating transaction is not complete.
In addition to establishing the media stream prior to establishing the session dialog, early media may involve several
intermediate established media sessions called early session media. This form of media is necessary for features like
Solicitor Blocking, Outbound Call blocking, and anytime media is established with a secondary source prior to
connection to the final terminator.
7.1.9.1 Feature Execution, Early Media from Terminating Party

Early media execution involves two parties in a basic call: the originator, who receives early media from the
terminator upon receiving an 18X provisional response, and the terminator, who receives early media after sending a
positive response to a PRACK from the originator.
A UE MUST support PRACK as defined in [RFC 3262].
For the originator in the call:
• Early media MAY be received by the originator at any time after receiving an 18X provisional response from
the terminator. The 18X provisional response for early media MUST include '100rel' in the Require header if
the originating party indicated support for PRACK.
• The UE's application of early media based on the reliable response MUST be in accordance with the rules

• Renegotiation of media by the UE MAY occur any time during an early dialog via UPDATE from the
terminator.
For the terminator in the call:
• The terminating UE receiving a compatible SDP in the initial INVITE MUST send an 18X response with the
negotiated CODEC.
• When the terminating UE receives a PRACK, it SHOULD begin sending any available media to the originating
UE. The terminating UE MAY begin sending any available media to the originating UE before receiving a
PRACK.
• Renegotiation of media by the UE MAY occur any time during an early dialog via UPDATE from the
originator.
7.1.9.2 Feature Execution, Early Media from Intermediate Parties

Early session media may be used for playing announcements as an intermediate step before terminating to a UE.
Examples include Solicitor Blocking, Outbound Call Blocking, etc.
For the originator in the call, in addition to normal Early Media execution:
- UEs supporting early-session MUST support early-session answer of an early-session offer
For the terminator in the call that is providing early media, in addition to normal Early Media execution:
- The call terminator (usually AS) SHOULD support early session media offer answer. The call terminator
(usually AS) MUST send an early-session offer when the originator signals it supports early-session via
population of the Supported header in the initial INVITE.
7.1.9.3 MGC Considerations

For calls placed from the PSTN to a PacketCable network, the MGC plays the role of the originating UE in early
media scenarios. The MGC requirements and procedures (including SIP to ISUP interworking) for support of early
media are specified in [CMSS1.5].

There is no data associated with this feature.

Basic Call
The UE SHOULD render early media as described in Section 7.1.9.1 when early media is received, in lieu of local
ringback.
DND PIN Override
DND PIN override uses two-way early media as described in Section 7.1.9.2 for announcement and collection of
PIN. The DND AS MUST support [RFC 3959].
Solicitor Blocking
Solicitor Blocking uses two-way early media as described in Section 7.1.9.2 for both the collection of greeting and
the playback of greeting to the subscriber. The SB AS MUST support [RFC 3959].
Outbound Call Blocking
Outbound Call Blocking uses two-way early media as described in Section 7.1.9.2 for collection of overriding PIN.
The OCB AS MUST support [RFC 3959].

7.1.9.6 Call Flows

Figure 18 illustrates setup of two-way early media from terminating party, with one-way media as an intermediate
step.
PacketCable
“A” “A” "B" “B”
Off-hook
Dial Tone
Digits
INVITE
INVITE
Power
Ringing
180 with SDP
180 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Early Media Path
Figure 18 - Early Media from terminating party
Figure 19 illustrates setup of two-way early media from an intermediate party.

PacketCable
Phone UE Network Intermediate
“A” “A” Party
Off-hook
Dial-tone
Digits
INVITE
session offer SDP
INVITE
session offer SDP
183
early-session offer SDP
183
early-session offer SDP
PRACK
early-session answer SDP
PRACK
early-session answer SDP
200 OK PRACK
200 OK PRACK
Early Media Path
Figure 19 - Early Media from intermediate party
Figure 20 illustrates setup of early media for calls placed from the PSTN to the PacketCable network.
PacketCable
Network UE Phone
PSTN MGC
"B" “B”
IAM
INVITE
INVITE
Power
Ringing
183 with SDP
183 with SDP
ACM
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Early Media Path
Figure 20 - Early Media - PSTN Origination

7.1.10 No Answer Timeout

A dialog invitation may sometimes be not answered: the destination UE continuously applies "Power Ringing" and
no end user or device (modem/fax) responds to the ringing signal (no change from "On Hook" to "Off Hook" state
on the destination UE). It is undesirable to indefinitely continue in the Power Ring state. Therefore, it is appropriate
to terminate an INVITE request which does not result in a 200 OK response (off hook state detection). The No
Answer Timeout provides the means to terminate such an unsuccessful dialog initiating request when the timer
elapses before the request is answered.
7.1.10.2 Activation & Deactivation

The provisioned timer named 'No Answer Timeout' is used to determine when an INVITE request should be
canceled due to the remote communication peer not answering.
If the originating UE goes back to the on hook state at any time during the No Answer Timeout duration, the
originating UE MUST send a CANCEL message for the original INVITE.

The destination UE MUST implement the No Answer Timeout timer. The following procedures apply for the
processing of No Answer Timeout timer:
• The destination UE MUST start the timer "No Answer Timeout" after sending an 18x response to an initiating
request.
• The destination UE MUST cancel the No Answer Timeout timer if the destination UE detects an "Off Hook"
state.
• If an "Off Hook" state is not detected and the No Answer Timeout timer expires, the destination UE MUST
send a 480 Temporarily Unavailable response to the INVITE and stop ringing the phone.
• In response to the expiration of the no-answer timeout, the destination UE MUST disable the Power Ring state.
The following requirements apply to the originating UE:
• In response to 480 Temporarily Unavailable response, the originating UE MUST respond with an ACK.
• After receiving the 480 Temporarily Unavailable response, the originating UE MAY request a Network
Announcement per Section 7.1.6 Announcements.

Table 14 summarizes the feature data items that are defined to support the No Answer Timeout feature.
Table 14 - No Answer Timeout Feature Data

No Answer timer duration Integer (seconds) Per public user Config. Config. UE Mandatory
(Note 1) identity Server Server
Note 1: It is recommended that the value of this timer be set to a value higher than the timer for Call Forwarding Don't Answer so
that Call Forwarding feature is invoked before the No Answer timer expires. Note that Call Forwarding Don't Answer feature
will CANCEL the INVITE to the destination UE before forwarding the call.

7.1.11 Response Codes

Table 15 specifies the list of response codes that MUST be supported by UE, AS, P-CSCF, S-CSCF, and E-CSCF.
These response codes are defined in [RFC 3261]. Individual features specified in this document may also specify
actions to response codes that override the response codes specified in Table 15.
Table 15 - Response Codes
Response Code Action

180 Ringing If SDP is not specified, the UE MUST apply local ringback tone to the phone.
If SDP is specified, the UE MUST play back audio received in the RTP stream.
If SDP is specified, the UE MUST play back audio received in the RTP stream.
183 Session Progress Action is depending on the situation. For early media, it means setting media stream active, for example,
a=sendrecv or a=recvonly.
200 OK The UE MUST send an ACK.
302 Moved Temporary The receiving UE MUST use the address in the Contact header to send a new request.
433 Anonymity The receiving UE MUST follow the procedures in Section 7.2.7.
Disallowed
480 Temporarily The receiving UE MUST follow the procedures in Sections 7.1.4.2, 7.1.10, 7.4.3.4, 7.4.3.5, and 7.7.1.6.
Unavailable
486 Busy Here The UE MUST apply busy tone or announcement to the phone, respond with an ACK and terminate the
SIP session.
All Other Response The UE MUST respond according to [RFC 3261], and all other IETF RFCs required in this specification
Codes that defines new response codes according to the IANA SIP registry.
7.1.12 Feature State Synchronization between Application Server and User Equipment
Certain RST features require the synchronization of dynamic feature data between an application server and the user
equipment. The features that require this capability are:
• Call Forwarding Variable: for the playing of a special conditions dial tone when the feature is active, and for the
playing of a ringsplash whenever a call is forwarded by the application server.
• Selective Call Forwarding: for the playing of a ringsplash whenever a call is forwarded by the application
server.
• Do Not Disturb: for the playing of a special conditions dial tone when the feature is active.
For these features, the application server may become aware of a change of state information in the network, and
needs a method for notifying user equipment of the change in feature state. The following subsections define the
mechanism by which an application server provides dynamic feature data changes; per feature specifics are provided
in the respective feature sections.
7.1.12.1 Use of ua-profile Event Package for Dynamic Feature Data synchronization
The UE will have discovered as part of its configuration the set of AUIDs that are applicable to it and the features
that are associated with each AUID. Once this set is available the UE MUST send a SUBSCRIBE to the network for
each AUID, in conformance with the general requirements of [ID SIP-CFG], and specifically formed as follows:
• The RequestURI is set to the Public User Identity.
• Contain an Event header containing 'ua-profile' as the event; set the profile-type parameter to a value of
'application' and include an event header parameter termed "auid" populated with the AUID received through
configuration. The ABNF syntax (refer to [RFC 3261]) of the auid parameter is as follows:
- AUID = "auid" EQUAL quoted-string
• Contain an Accept header containing a media type of application/xml.

An application server receiving a SUBSCRIBE as defined above MUST conform to the general requirements of [ID
SIP-CFG], and generate a NOTIFY message populated as follows:
• Contain a content type header set to application/xml.
• Contain a message body in adherence to the schema defined in Section 7.1.12.3.
Note that as this mechanism can result in multiple SUBSCRIBEs being sent (one per AUID) it is therefore possible
for the UE to receive multiple NOTIFY messages from different application servers in the network. The subscription
dialog of the NOTIFY will imply the AUID for which it is providing data. The ActiveFeatureSet enumeration
received as part of the XML document is specific only to the implied AUID of the NOTIFY being received; it is not
the complete set of active features across all known and applicable AUIDs. Thus, when a collection of SetElements
for an ActiveFeatureSet is received for an AUID, the UE MUST view the current complete active feature set as the
sum of all such elements received for all AUIDs.
Inclusion of a SetElement in an ActiveFeatureSet for an AUID indicates that this feature is active. Non-inclusion of
a feature enumeration in a SetElement within a received ActiveFeatureSet for the AUID appropriate to that feature
indicates that this feature is inactive.
7.1.12.2 AUID set for Dynamic Feature Data

The UE MUST support the following set of AUIDs which could be received as part of configuration:
• com.cablelabs.pkt.rst.featureset.1
The UE discovers via configuration which AUIDs from the list provided are applicable to it and also which features
are represented by each AUID. Each AUID discovered via configuration could be associated with one or more
features.
7.1.12.3 XML Schema Definition

The following is the XML schema representing the dynamic feature data that is sent from an application server to a
UE in response to a SUBSCRIBE populated in accordance with Section 7.1.12.1. A UE configured with features
that make use of dynamic feature data MUST support reception of this schema in the NOTIFY body. This schema
carries all data elements identified by the features that require this capability; specifically Table 27 for Call
Forwarding Variable, Table 31 for Selective Call Forwarding and Table 40 for Do Not Disturb.
<?xml version="1.0" encoding="utf-16"?>
<xsd:schema xmlns="http://www.cablelabs.com/namespaces/PacketCable/R2/XSD/v1/CL-PKTC-
RST-FT-DATA" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.cablelabs.com/namespaces/PacketCable/R2/XSD/v1/CL-PKTC-
RST-FT-DATA">
<xsd:annotation>
<xsd:documentation>
This XML Schema represents the dynamic feature data that can be provided by an
application server
to a UE as specified in the PacketCable Residential SIP Telephony (RST) Feature
specification.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="CL-PKTC-FEATURE-DATA">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="pktcFeatureData" type="pktcFeatureDataType"/>

<xsd:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="pktcFeatureDataType">
<xsd:sequence>
<xsd:element name="pktcRSTFTMinorVersion" type="xsd:integer" default="1"/>
<xsd:element name="ActiveFeatureSet">
<xsd:annotation>
<xsd:documentation>
This element is the representation of the following data
elements from within the RSTF:Call Forwarding Variable Activation Status,Selective
Call Forwarding Activation Status,Do Not Disturb Activation Status
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SetElement"
type="ActiveFeatureName" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:unique name="uniqueFeature">
<xsd:selector xpath="SetElement"/>
<xsd:field xpath="."/>
</xsd:unique>
</xsd:element>
<xsd:element name="CFVForwardedCallCount" type="xsd:positiveInteger"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
This element is the representation of the 'Number of Calls
Forwarded Since Activation' data element from within the RSTF section detailing CFV
</xsd:annotation>
</xsd:element>
<xsd:element name="SCFForwardedCallCount" type="xsd:positiveInteger"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
This element is the representation of the 'Number of Calls
Forwarded Since Activation' data element from within the RSTF section detailing SCF
</xsd:annotation>
</xsd:element>
<xsd:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="ActiveFeatureName">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="cfv"/>
<xsd:enumeration value="scf"/>
<xsd:enumeration value="dnd"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
7.1.13 IPv6 Support

As part of the initial provisioning process, the UE determines the IP mode in which it needs to operate. The UE
MUST support IPv4 and IPv6. The UE MUST be able to operate in IPv4-only or IPv6-only modes.

7.1.14 DSCP for Non-Emergency Signaling

The UE MUST set the DSCP value for IP packets carrying non-emergency signaling that it sends towards the
network to the provisioned value indicated in Table 16. This applies to all TCP packets for a TCP connection
established for signaling.
Table 16 - DSCP for Non-Emergency Signaling

Requirement
Non-Emergency Integer Per Network Config.Server Config.Server UE Mandatory
signalling DSCP Value (range of 0..63)
7.1.15 Operator Specific Features

The Operator Specific Features capability defines feature identifier values for use with the digit map FEATURE-
CHECK action. This allows for the creation of digit map controlled features that do not require standardization of
the feature. Those features are only relevant within the scope of a given operator.

Table 17 shows feature data items that are applicable to Operator Specific Features.
Table 17 - Operator Specific Features Data

Operator Specific Features Variable length array of operator Per Public Config. Config. UE Mandatory
specific feature entry User ID Server Server
Operator Specific Integer Per Public Config. Config. UE Mandatory
Feature.Feature Identifier User ID Server Server
Operator Specific Boolean Per Public Config. Config. UE Mandatory
Feature.Availability Status User ID Server Server
Operator Specific String Per Public Config. Config. UE Optional
Feature.Name User ID Server Server
It is a requirement to ensure that any Feature Identifier which is configured as part of Operator Services Feature
Data does not conflict with any of the already allocated feature identifiers for the features standardized in this
specification. Hence, the Feature Identifier assigned as part of the Operator Services Feature Data starts at identifier
100.
7.1.15.3 Example
"900" outbound call blocking, one of the variant of the outbound call blocking feature (described in Section 7.4.1
can be implemented with the rule:
"1(900x{7})" : FEATURE-CHECK("xyz"); RETURN ("+1" #1)
Where 'xyz' is a feature identifier assigned as per the Operator Specific Features Data specified in Table 17 in
Section 7.1.15.2, the identifier 'xyz' is allocated by the network operator and its status is reflected in the
corresponding 'Feature Availability Status' data component.
7.1.16 Event for Registrations

The event package for registrations allows the UE to be notified of its registration status by the network. This is
particularly useful when the network needs to de-registers the UE.

The network can de-register the UE by sending a NOTIFY message to the UE with a "deactivated" or "rejected"
event attribute. According to [PKT 24.229], the UE needs to re-register with the network when receiving a NOTIFY
message with "deactivated" event attribute, but it does not need to re-register when receiving a NOTIFY message
with a "rejected" event attribute.
If the UE does not re-register with the network after being de-registered, it may end up in a state where it cannot
recover without some external stimulus (e.g., manual reset). To avoid such issues, when the UE receives the
"rejected" attribute in the reg event NOTIFY message, it MUST follow the same requirements as for the
"deactivated" attribute described in [PKT 24.229] if the "Override NOTIFY Rejected" flag in Table 4 is set to 'true'.
This will cause the UE to perform re-registration in such cases. If the "Override NOTIFY Rejected" flag in Table 4
is set to 'false', the UE MUST follow the requirements for NOTIFY "rejected" specified in [PKT 24.229].
7.2 Caller ID
7.2.1 Caller ID Presentation
Several features, described in the following sections, cooperate to provide Caller Identification (Caller ID)
functionality. Implementation is distributed among the originating UE, originating P-CSCF, originating Application
Server, terminating Application Server, terminating P-CSCF, terminating UE, ingress and egress MGC.
The following is an outline of the process:
• When a UE registers, the S-CSCF receives calling name information from the HSS, and passes it to the P-
CSCF.
• When making a call the originating UE may provide a hint about the identity of the user originating the request.
It may also indicate preferences regarding the presentation or blocking of the display of the identity information
to a recipient outside the provider's trust domain, such as the terminating UE, as specified in [PKT 24.229].
• The originating P-CSCF, using the hints from the UE if available, inserts an assertion about the identity of the
originator into the request, as specified in [PKT 24.229]. The assertion contains the calling name if it was
received from the S-CSCF.
• In the case of calls originating in the PSTN, an ingress MGC takes identity information from the PSTN request
and uses it to insert an identity assertion in the resulting SIP request. It also takes information about the
presentation status of the PSTN request and uses it to indicate Caller ID representation status in the SIP request.
In some cases it may perform a TCAP query to determine the desired presentation status.
• A terminating Application Server may override the Caller ID blocking status of the request. If calling name
delivery is enabled but the calling name is not included in the identity assertion, then the terminating AS may
perform a TCAP query to obtain the calling name, and insert it into the identity assertion.
• The terminating S-CSCF or P-CSCF removes the identity assertion from the request before forwarding it if
Caller ID blocking is enabled. See [PKT 24.229].
• If the Caller ID display feature is enabled on the terminating UE, and the identity information is present in the
incoming SIP request, a terminating UE displays the available identity information to the user.
• In the case of calls terminating in the PSTN, an egress MGC takes the identity information and blocking status
from the incoming SIP request and transforms it into presentation status for the resulting PSTN message.
The document [GR 391] defines the Caller ID feature using the notion of Presentation Status (PS). Telcordia uses
two presentation status attributes – one for calling number and one for calling name. Each may take the value
"public" or "anonymous." These two attributes may be controlled independently and determine whether,
respectively, the calling number and calling name (if available) are presented to the callee. If the attribute value is
"public," then the corresponding aspect of identity is displayed. If the value is "anonymous," then the identity is not
displayed. The presentation status values for a request are derived starting from a pair of Permanent Presentation
Status (PPS) values (for number and name) and modifying those based on per-call features invoked by the
originating UE.

Within SIP requests, the PacketCable network elements follow the procedures of [PKT 24.229] and assert subscriber
identity using the P-Asserted-Identity header. This header contains a URI and an optional display name. The user
part of the URI is used to represent the calling number, while the display name represents the calling name. There
may be up to two P-Asserted-Identity headers in a SIP request. If only one P-Asserted-Identity is present, it may
contain a SIP, SIPS, or TEL URI. If two P-Asserted-Identity fields are present, then [RFC 3325] requires that one
must contain a SIP or SIPS URI and the other must contain a TEL URI.
If two P-Asserted-Identity headers are present, the UE SHOULD use the following procedures to select the values of
the P-Asserted-Identity header to use for Caller ID display:
• Make a preliminary choice of which P-Asserted-Identity header value to use according to Table 18.
• If the Table does not specify a choice, then if exactly one has a display name, choose that one, else choose the
first one.
• If the chosen one has no display name, but the other one does have a display name, then use the URI from the
chosen one and add the display name from the other one to it.
• The chosen header value is used as the P-Asserted-Identity header in the procedures of this section and
subsections.
If the P-Asserted-Identity header value is required to be modified for the purposes of Caller ID display procedures,
the unmodified or original P-Asserted-Identity header MUST be included in subsequent SIP signaling.
Table 18 - P-Asserted-Identity Header Selection
TEL URI
Global-Number Local-Number
SIP/SIPS URI User=phone Global # — SIP/SIPS
Local # TEL —
User≠phone Global # TEL SIP/SIPS
Local # TEL —
The PacketCable network elements follow the procedures of [PKT 24.229] and the desired presentation status is
specified by the Privacy header as defined in [RFC 3323]. The Privacy header value of 'id' which means to withhold
the P-Asserted-Identity header from untrusted elements including the terminating UE is defined in [RFC 3325].
Network elements such as a P-CSCF or I-CSCF follow the trust model defined in [PKT 24.229]. Such network
elements interpret the lack of a Privacy header, or a Privacy header that does not contain the value 'id' as meaning
that a P-Asserted-Identity header should be retained in the request when it is forwarded by the network element. The
Privacy header does not have the capability to independently control the presentation of calling name and calling
number. Both are either presented or blocked from the UE. For this reason, PacketCable has only one Presentation
Status (PS) attribute per call, and only one Permanent Presentation Status attribute per Public User Identity.
An originating UE uses the P-Preferred-Identity header to indicate which public identity it would like asserted for a
particular request. It has the same format as the P-Asserted-Identity header. It may be inserted by the originating UE
to express a preference, and then is usually considered by the originating P-CSCF (or sometimes another core
element) when choosing what value to include in P-Asserted-Identity. (An originating UE is not permitted to insert a
P-Asserted-Identity header.) When the P-Asserted-Identity header is added to the request the P-Preferred-Identity
header is removed. The P-Preferred-Identity header is not present during termination processing of the request.
When a call is originated by a UE, the UE is solely responsible for determining the Presentation Status of the call.
The UE MUST determine the presentation status for a call by a combination of the Permanent Presentation Status
parameter and the per-call Caller ID feature that has been invoked, if any. Table 19 specifies how these are
combined.

Table 19 - Effects of Per-Call Blocking Features on Presentation Status
PPS value for the originating Per-call Caller ID Blocking feature Resulting Presentation Status
subscriber
anonymous none anonymous
public none public
anonymous Caller-ID Per Call Toggle public
public Caller-ID Per Call Toggle anonymous
anonymous or public CIDS Suppression (see Note 1) anonymous
anonymous or public CIDS Delivery public
Note 1 CIDS: Caller ID Delivery and Suppression
7.2.1.1 Feature Implementation

When the UE originates a call, it MUST determine what presentation status applies for this call, as specified in
Table 19, and so indicate in the request.
The presentation status for a call is denoted in the request as follows:
• If the presentation status is "public":
If the UE has registered with more than one Public Identity, then the UE MUST insert a P-Preferred-Identity
header containing the Public User Identity for the line. This changes a behavior that is optional in IMS
[PKT 24.229] to mandatory. If there is more than one Public User Identity for the line, one in telephone number
format SHOULD be used.
The UE MUST NOT include a Privacy header containing a value of "id."
The UE SHOULD include the chosen Public User Identity in the From header.
The UE SHOULD include the calling name of the chosen Public User Identity as the display name in the From
header.
(While the From header is not used for caller identification by a terminating UE, including it has the potential to
enhance interoperability with peers that are not PacketCable compliant).
• If the presentation status is "anonymous":
The UE MAY insert a P-Preferred-Identity header containing the Public User Identity for the subscriber. If
there is more than one Public User Identity for the line, one in telephone number format SHOULD be used.
The UE MUST include a Privacy header containing a value of "id."
The UE SHOULD include the URI <sip:anonymous@anonymous.invalid> in the From header.
The UE SHOULD include the value "anonymous" as the display name in the From header.
(While the From header is not used for caller identification by a terminating UE, it may be used by a peer that is
not PacketCable-compliant. Using "anonymous" rather than the actual identity protects against disclosure of
identity that is intended to be blocked.)
The UE SHOULD populate the P-Preferred-Identity header with either a TEL URI, or a SIP URI with a parameter
of 'user=phone', otherwise PSTN interoperability may not function correctly.
The actions at the P-CSCF and S-CSCF with regard to handling the received P-Preferred-Identity header are defined
by [PKT 24.229].
When the S-CSCF processes a successful registration, the information it obtains from the HSS may contain a calling
name for the registered public identity. The S-CSCF conveys the calling name to the P-CSCF in the P-Associated-
URI header if the calling name was received from the HSS as a result of a successful registration.

When the P-CSCF processes a successful registration, it saves any display names included in the returned P-
Associated-URI parameter, for use in including calling name in asserted identities.

Table 20 shows feature data items that are applicable to multiple Caller ID features.
Table 20 - Caller ID Feature Data

Requirement
Public User Identity(s) SIP or TEL Per UE HSS HSS UE, S- None
that may be used by the URI CSCF,
UE to originate calls P-CSCF
Calling Name String Per public user ID HSS HSS S-CSCF None
Permanent Enum Per public user ID Config.Server Config.Server UE Mandatory
Presentation Status (public,
(PPS) anonymous)
Per Call Presentation Enum Per public user ID UE UE UE None
Status (public,
(Public/Anonymous) anonymous)
Per Call Presentation Boolean Per Public User ID UE UE UE None
Status Used? (Yes/No)
7.2.2 Caller ID Display

Caller ID Display is a feature that allows a subscriber to see who is calling him before he answers the call. Caller ID
Display consists of two sub-features: Calling Number Display (CND) and Calling Name Display (CNAMD).
Except as noted here, Caller ID functionality must match that described in Telcordia documents [GR 31] (CND),
[GR 1188] (CNAMD), and [GR 30] (Delivery of data).
The user interface descriptions in [GR 31] must be followed for UEs with analog interfaces. UEs with other
interfaces are allowed to provide alternative user interfaces because different types of UEs have widely varying user
interface capabilities. In addition to the wide range of UEs, a service provider may offer a web client mechanism to
allow a subscriber to manage his or her service data. For this section, however, descriptions are limited to
interactions with the telephony client, rather than a service management web client.
In particular for the analog interface, the Caller ID information, consisting of the date and time of the call, plus the
calling party's number, and optionally his name, is delivered to the analog interface in the first four seconds of
silence after the first ring. The information is transmitted as follows:
<2 digit month><2 digit day of the month><2 digit hour (24 hour clock)><2 digit minutes<10 digits
number><15 character name>
If no information can be obtained, an "O" is sent (originally it meant Out of area). If the caller has blocked the
delivery of his information, a "P" is sent (Private).
Caller ID is also delivered with calls that are routed to voice mail systems.

If the Calling Name Display Feature is active, it is recommended that there be a filter in the User Profile that
invokes an Application Server for a terminating request when the following conditions are met:
• The request has a P-Asserted-ID with the Display Name absent;
• The URI in the P-Asserted-ID header contains an E.164 number;

• The request contains no Privacy header, or a Privacy header is present and contains the token "none," or a
Privacy header is present that does not contain either the token "id" or the token "header."
The AS MUST query a CNAM DB and update the display name in the P-Asserted-ID with either the name from the
DB, or a display name of "" if no value can be obtained from the CNAM DB. (The AS may use TCAP, ENUM, or
any other mechanism to perform the query.)
If the Calling Name Display feature is absent or inactive, there may be a filter in the User Profile that invokes an
Application Server for a terminating request when:
• There is no Privacy header; or
• There is a Privacy header containing neither the token "none" nor the token "id".
In this case, the AS MAY insert the token "id" into an existing Privacy header or insert a new Privacy header
containing the token "id".
Note: If there is a Privacy header containing the token "none," the AS is forbidden by [RFC 3323] from removing
the "none" token. In this case, if the AS wishes to prevent the Caller ID from being made available to the
UE, the AS MUST prevent the request from being delivered to the UE.
For calls placed to a public identity that has subscribed to Caller ID Display, the called party's P-CSCF will examine
the Privacy header in the incoming INVITE and forward or strip the P-Asserted-Identity header(s) to the UE
according to the rules that govern transmission of identity information to an un-trusted domain/entity (the UE).
A UE displays the calling number if and only if the CND feature is activated, and displays the calling name if and
only if the CNAMD feature is activated. The following steps specify how the calling number and name is displayed.
For a non-analog UE, the UE MAY display the Caller ID Display information from the P-Asserted-Identity
header(s) in an implementation dependent manner. However, the UE SHOULD display at least the date/time of the
incoming call, the name, and, if present, the telephone number of the caller.
For the analog UE, the UE MUST display the Caller ID Display information in accordance with Telcordia [GR 30].
The date and time of the call is computed by applying the Adjustment from Location Invariant Time to Time at
Current Location provisioned per Table 21 to the location-invariant time-of-day. Furthermore, if the Daylight
Saving Time (DST) provisioned per Table 21 is set to 'true', the UE MUST also adjust for DST in the computation.
Otherwise, the UE MUST NOT perform the DST adjustment. With the Daylight Saving Time set to 'true', if the UE
supports the Daylight Saving Time Information provisioned per Table 21, the UE MUST perform the DST
adjustment with respect to the provisioned transition dates, times, and time adjustment amount. Otherwise, the UE
MUST perform the DST adjustment with respect to a prior knowledge about the DST transition times that, for
example, are hard-coded in its firmware image.
In order to preserve compatibility with the large number of existing analog Caller ID Display units already in
existence in North America, the analog UE conforms to the following requirements for creating the Caller ID
Display data from the information in the INVITE:
1. If no P-Asserted-Identity header is present, then the UE MUST transmit a "P" in the number field and nothing
in the name field.
2. If a SIP or SIPS URI is present in the P-Asserted-Identity header, then the UE MUST transmit the first 15
characters of the display name, if present, in the name field. Otherwise, nothing is transmitted in the name field.
3. If a TEL URI is present in the P-Asserted-Identity header and contains a local-number as defined in [RFC 3966]
(if the first character is NOT a "+"), then the UE MUST extract the local-number-digits component and remove
all visual-separator characters. Then the UE MUST transmit all the remaining characters in the number field.
4. If a TEL URI is present in the P-Asserted-Identity header and contains a global-number as defined in
[RFC 3966] (if the first character is a "+"), then the UE MUST extract the global-number-digits component and
remove all visual-separator characters as well as the leading "+" character. If the initial characters in the result
match the default country code, then the UE MAY strip them out. Then the UE MUST transmit all the
remaining characters in the number field.

5. If no TEL URI is present in the P-Asserted-Identity header, but there is a SIP or SIPS URI with a user part
beginning with "+," the UE MUST use the user part to determine the number field in accordance with the rules
in the preceding step.
6. If none of the steps above cause the number field to be transmitted, then the UE MUST transmit an "O" in the
number field.
The UE MUST activate or deactivate the Caller ID display feature for call waiting as per the setting of CIDCW
activation status in Table 21.

Table 21 shows feature data items that are defined to support the Caller ID display feature.
Table 21 - Caller ID Display Feature Data

Requirement
CND feature activation status Boolean Per public Config.Server Config.Server UE Mandatory
user ID
CNAMD feature activation status Boolean Per public Config.Server Config.Server UE Mandatory
user ID
Current Time of Day – location UTC Per network UE UE UE None
invariant
Adjustment from location Time delta Per UE Config.Server Config.Server UE Mandatory
invariant time to time at current (minutes)
location
Daylight Saving Time Boolean Per UE Config.Server Config.Server UE Mandatory
Daylight Saving Time String Per UE Config.Server Config.Server UE Optional
Information
Default Country Code String Per public Config.Server Config.Server UE Mandatory
user ID
CIDCW activation status Boolean Per public Config.Server Config.Server UE Mandatory
(Default: true) user ID

Interactions with other features defined in this specification are as specified in [GR 31] and [GR 1188], with
limitations as follows:
• Specifications of presentation apply, but specifications of the mechanisms used to obtain the information
displayed do not apply.
• AC/AR subsection does not apply directly. Multiparty Lines subsection has limited applicability because a UE
cannot be a multiparty line.
• CND subsection of [GR 1188] applies except that usage sensitive CND and CNAMD do not apply.
• For interactions with AC and AR, see Section 7.7.2 and Section 7.7.1.
7.2.3 Caller ID Per-Line Blocking

Caller ID Per-Line Blocking is a feature that allows configuration of a default Permanent Presentation Status (PPS)
value of "public" or "anonymous" for the presentation of Caller ID on a per-line (Public User ID) basis. This is
similar to the CIDB feature defined in [GR 391]. CIDB permits specifying PPS of "public" or "anonymous"
separately for calling number and calling name. The feature described here defines a single default value that applies

to both calling number and calling name. This feature is not activated or deactivated through the use of feature codes
– it is activated and deactivated only via provisioning.
When a caller makes a call and does not invoke the per-call Caller ID blocking features, then the Permanent
Presentation Status value defined here applies to both the calling name and calling number of the call.
When a caller makes a call that invokes per-call Caller ID blocking features, those features interact with the
provisioned PPS to determine the Caller ID presentation attributes of the call. The mechanics of invocation are
specified in the sections pertaining to those features.

Caller ID Per-Line Blocking is carried out by the calling UE. The UE MUST be provisioned with read-only versions
of the PPS value for each line it supports, as well as the Public User Identity for that line. The UE MAY also be
provisioned with the Calling Name value for that line.
The application of Caller ID Per-Line Blocking to a call is specified in Section 7.2.4.

Interactions with other features defined in this specification are as specified in [GR 391], with limitations as follows:
• [GR 391] describes multiple features. Only the interactions pertaining to per-line name and number blocking
apply here.
• For PacketCable, there is only one PPS (Permanent Presentation Status) value governing the presentation of
both name and number. References in [GR 391] to the PPS for either name or number refer to this single value.
• Specifications of presentation apply, but specifications of the mechanisms used to obtain the information
displayed do not apply.
• The following [GR 391] interactions do not apply: Basic Business Group, Bulk Calling Line Identification,
Charge-a-call, Coin Service, Multi Party Lines of more than two parties, Multi-Switch Business Groups, Private
Branch Exchange, Remote Switching Units and Two-Party Lines.
• The interactions with CND and CNAMD are specified in Section 7.2.2 of this document.
7.2.4 Caller ID Per-Call Blocking (CIDS-Suppression)

This feature is similar to the CIDS Suppression feature defined by [GR 391]. To use this feature the caller does the
following:
• Goes off-hook and received dial tone.
• Enters the assigned vertical feature code. The feature code is provisioned in the UE.
• Receives dial tone, or a confirmation tone followed by a recall dial tone.
• Dials the telephone number of the called party.
For this one call, the permanent presentation status value is overridden with the value "anonymous" as specified in
Section 7.2. If the caller goes on hook at any point prior to completion of dialing the called party number, the feature
has no effect.
As a minimum implementation, all tones and messages defined by [GR 391] for support of this feature are required.
Optional tone and message sets may be offered as value-added customizable features as long as the required set is
part of the implementation.

CIDS-S is carried out by the calling UE. As part of its CID-SUPPRESS digit map action, the UE MUST check to
see if the CID Suppression feature is available; and if the feature is available, set the local privacy state on the UE to

suppressed. The UE MUST then cause recall dial tone to be played, and be ready to accept dialed digits. If the CID
Suppression feature is not available, then the UE MUST cause an error tone or message to be played.

Table 22 summarizes the feature data items that are defined to support the CIDS-S feature.
Table 22 - Caller ID Per-Call Blocking Feature Data

Requirement
Feature availability status Boolean Per public Config.Server Config.Server UE Mandatory
user ID
Confirmation Tone after vertical Tone Per Action Config.Server Config.Server UE Mandatory
feature code
Error Tone after vertical feature Tone Per Action Config.Server Config.Server UE Mandatory
code failure

ACR
Activating CIDS-S results in call rejection if the called party has invoked the ACR feature.
AC
AC allows customers to place calls to the last call they called. CIDS-S or CIDS-D can be activated before AC
activations and reactivations as well as before the original call is made. When an AC call is finally established, the
most recent CIDS-x that the AC customer activates determines the presentation status associated with the AC
customer.
If no CIDS-x is invoked immediately before AC activation or reactivation, then the AC must be invoked using the
same presentation status that was used when the customer originally entered the telephone number to place the call.
If the feature code for CIDS-S is entered, and followed by the feature code for AC, then the AC must be invoked
with a presentation status of "anonymous". This applies to both activation and reactivation of AC.
AR
AR allows customers to place calls to the last call they received. CIDS-S or CIDS-D can be activated before AR
activations and reactivations. When an AR call is finally established, the most recent CIDS-x that the AR customer
activates determines the presentation status associated with the AR customer.
If the feature code for CIDS-S is entered, and followed by the feature code for AR, then the AR must be invoked
with a presentation status of "anonymous". This applies to both activation and reactivation of AR.
An AR customer may use this feature on the last call that the customer received regardless of the caller's
presentation statuses. However, if the call that the AR customer received was originally marked "anonymous", the
SPCS shall not disclose the Caller ID to the AR customer when the call is finally established and the AR customer
gets ring back.
Calling Number Delivery
If a caller activates CIDS-S then the callee will not receive Caller ID, including calling number. Detailed results are
covered in Section 7.2.2.

Calling Name Delivery

If a caller activates CIDS-S then the callee will not receive Caller ID, including calling name. Detailed results are
covered in Section 7.2.2.
Operator Services
A caller should be able to access CIDS-x and operator services for the same call. A caller is able to dial the CIDS-x
feature access code before dialing a number that invokes operator services. The resulting presentation status is used
for any call the operator makes on behalf of the caller.
Screening List Services
If the called party invokes screening list editing procedures to add the last calling number to a screening list and the
caller's presentation status was anonymous, an "anonymous" indication is included in the new screening list entry.
However, an "anonymous" entry in the screening list will not be displayed or otherwise be made available to the
customer.
Speed Dialing
A CIDS-x feature activation code may be entered as part of an entry in a speed-calling list.
When speed dialing is invoked, if the selected speed-calling list entry contains a CIDS-x feature activation code,
then the call is placed with that feature activated.
A speed-calling invocation may be entered following the entry of the CIDS-x feature activation code. In this case the
call is placed with that feature activated.
It is an error to enter a CIDS-x feature activation code followed by a speed-calling invocation if the selected speed-
calling list entry contains a CIDS-x feature activation code.
Three-Way Calling
A three-way call has two legs. The originator of each leg of the call may use CIDS-x during the initiation of that leg.
7.2.5 Caller ID Per-Call Delivery (CIDS-Delivery)

This feature is similar to the CIDS Delivery feature defined by [GR 391]. To use this feature the caller does the
following:
• Goes off-hook and received dial tone.
• Enters the assigned vertical feature code. The feature code is provisioned in the UE. (The suggested default
value is *82.)
For this one call, the permanent presentation status value is overridden with the value Public, as specified in Section
7.2. If the caller goes on hook at any point prior to completion of dialing the called party number the feature has no
effect.
The deviations from [GR 391] are the same as specified for CIDS-S.

CIDS-D is carried out by the calling UE. As part of its CID-DELIVER digit map action, the UE MUST check to see
if the CID Delivery feature is available, and if the feature is available, set the local privacy state on the UE to

display. The UE MUST then play recall dial tone, and be ready to accept dialed digits. If the CID Delivery feature
is not available, the UE MUST play an error tone or message.

Table 23 summarizes the feature data items that are defined to support the Caller ID Per-Call Delivery feature.
Table 23 - Caller ID Per-Call Delivery Feature Data

Requirement
user ID
Confirmation Tone after vertical Tone Per Action Config.Server Config.Server UE Mandatory
feature code
Error Tone after vertical feature Tone Per Action Config.Server Config.Server UE Mandatory
code failure

AC
AC allows customers to place calls to the last call they called. CIDS-S or CIDS-D can be activated before AC
activations and reactivations as well as before the original call is made. When an AC call is finally established, the
most recent CIDS-x that the AC customer activates determines the presentation status associated with the AC
customer.
If no CIDS-x is invoked immediately before AC activation or reactivation, then the AC is invoked using the same
presentation status that was used when the customer originally entered the telephone number to place the call.
If the feature code for CIDS-S is entered, and followed by the feature code for AC, then the AC is invoked with a
presentation status of "anonymous". This applies to both activation and reactivation of AC.
AR
Auto Recall allows customers to place calls to the last call they received. CIDS-S or CIDS-D can be activated before
AR activations and reactivations. When an AR call is finally established, the most recent CIDS-x that the AR
customer activates determines the presentation status associated with the AR customer.
If the feature code for CIDS-S is entered, and followed by the feature code for AR, then the AR is invoked with a
presentation status of "anonymous". This applies to both activation and reactivation of AR.
SPCS does not disclose the Caller ID to the AR customer when the call is finally established and the AR customer
gets ring back.
If a caller activates CIDS-D then the callee will receive Caller ID, including calling number, regardless of the
permanent presentation status. Detailed results are covered in Section 7.2.
If a caller activates CIDS-D then the callee will receive Caller ID, including calling name, regardless of the
permanent presentation status. Detailed results are covered in Section 7.2.
Operator Services
A caller should be able to access CIDS-x and operator services for the same call. A caller is able to dial the CIDS-x
feature access code before dialing a number that invokes operator services. The resulting presentation status is used
for the call.


caller's presentation status is anonymous, an "anonymous" indication is included in the new screening list entry.
However, an "anonymous" entry in the screening list is displayed or otherwise be made available to the customer.
Speed Dialing
A CIDS-x feature activation code could be entered as part of an entry in a speed-calling list.
When speed dialing is invoked, if the selected speed-calling list entry contains a CIDS-x feature activation code,
then the call is placed with that feature activated.
A speed-calling invocation could be entered following the entry of the CIDS-x feature activation code. In this case
the call is placed with that feature activated.
It is an error to enter a CIDS-x feature activation code followed by a speed-calling invocation if the selected speed-
calling list entry contains a CIDS-x feature activation code.
Three-Way Calling
A three-way call has two legs. The originator of each leg of the call can use CIDS-x during the initiation of that leg.
7.2.6 Caller ID with Call Waiting (CIDCW)

CIDCW can be enabled only when both Call Waiting and Caller ID display features are enabled. It can be disabled
even when both Call Waiting and Caller ID display features are enabled. See Section 7.5.2 for Call Waiting and
Section 7.2.2 for Caller ID display.
7.2.7 Anonymous Call Rejection

The Anonymous Call Rejection (ACR) service allows the user to reject incoming calls where the identity of the
originating user is or has been restricted.
When active the service rejects originator identity restricted calls without alerting the PacketCable subscriber. The
originating user is provided with an appropriate indication that the call has been rejected by an instance of an ACR
service.
The behavior of the service is as described in Telcordia [GR 567] the requirements of which must be met by a
PacketCable network unless otherwise specified here. The following sections and requirements within normative
reference [GR 567] do not apply to PacketCable networks. These deviations are additional to any divergence from
[GR 567] detailed elsewhere in this document:
• The billing requirements found in [GR 567] do not apply.
• All requirements in [GR 567] related to business groups do not apply.
• The traffic and maintenance measurements requirements in [GR 567] do not apply.
• The maintenance requirements in [GR 567] do not apply.
7.2.7.2 Feature Activation and Deactivation

The availability of ACR to a subscriber is via prior arrangement between the subscriber and the PacketCable
network provider. Once available and enabled the user activates and deactivates the service by dialing of vertical
service codes (VSCs). These are typically *77 for activation and *87 for deactivation. Alternately, a service
provider, as part of their service offering, could provide subscriber access to a web portal that supports ACR
activation and deactivation.
On activation of ACR, as part of its ACR-ACTIVATE digit map action, if the ACR feature is available, the UE
MUST send an INVITE with the request URI capturing the VSC as per the network requirements. The request URI
for this INVITE MUST follow the general form as described in Section 7.1.2. On entry of the ACR de-activation

code, as part of its ACR-DEACTIVATE digit map action, if the ACR feature is available, the UE MUST send an
INVITE with the request URI capturing the VSC as per the network requirements. The request URI for this
INVITE MUST follow the general form as described in Section 7.1.2. If the ACR feature is not available, the UE
MUST apply recall dial-tone to the phone and take no further action.
On successful activation or deactivation of the feature the ACR AS MUST provide a confirmation tone or
announcement to the subscriber. If an error occurs in the activation or deactivation of ACR the ACR AS MUST
provide an error tone or appropriate announcement.

The execution of the ACR service is provided by the ACR Application Server (AS) in the terminating (ACR
subscriber's) network.
It is assumed that when an incoming SIP INVITE is received by the terminating S-CSCF it is proxied to the ACR
AS by the S-CSCF if the filtering logic of the called UE's service profile dictates to do so.
If the ACR feature is not provisioned for the terminating subscriber or has been de-activated then the ACR AS
proxies the INVITE back to the S-CSCF.
7.2.7.3.1 Determination of Restricted Identity
The ACR AS determines based on the contents of the INVITE whether the service needs to be applied. The
originating identity of the caller is determined to be restricted if the following conditions hold:
• A Privacy header indicating a privacy level of "id" is present in the INVITE, or
• A Privacy header indicating a privacy level of "user" is present in the INVITE, or
• A Privacy header indicating a privacy level of "header" is present in the INVITE,
and
• The caller is not an authorized user with ACR override privileges. Calls from Emergency Services and Operator
Services personnel are not blocked by the ACR feature, since these calls are not anonymous, and has reserved
values in their P-Asserted-Identity fields.
7.2.7.3.2 Actions when Identity is Restricted
If originating identity is restricted, the ACR AS MUST perform the following actions:
• Provide an appropriate audible indication to the originator that the call is being rejected due to the application of
ACR.
• Reject the INVITE by sending a 433 Anonymity Disallowed final response as defined by reference
[RFC 5079].
If the originating identity is restricted, the ACR AS SHOULD include a Warning header in the final response with a
"warn code" of 399 and "warn text" as determined by the service provider.

Table 24 summarizes the feature data items that are defined to support the ACR feature.
Table 24 - ACR Feature Data

Requirement
Feature Availability Status Boolean Per public user Config.Server Config.Server UE Mandatory
ID
Feature Activation Status Boolean Per public user AS AS AS None
ID
Caller Treatment or URI for media Per network AS AS AS None
Announcement Resource (see server
Note 1)

Note 1: Not required if the announcement resource is integrated with the AS.

The ACR service has the following feature interactions.
Call Waiting
If the called user has activated ACR, then ACR takes precedence over the Call Waiting service.
If ACR is activated while a call is waiting, the state of the waiting call is not changed.
Caller ID Per-Call Blocking
If the activation of Caller-ID Per-Call blocking by an originating user results in a presentation status of anonymous
for the call, and that user is not an authorized user with ACR override, then all calls from that user are rejected by a
subscriber with ACR.
Caller ID Per-Line Blocking
If the originating user has subscribed to Caller-ID Per-Line blocking and that user is not an authorized user with
ACR override, then all calls from that user are rejected by a subscriber with ACR.
Call Forwarding
If the served user has activated ACR, then ACR takes precedence over Call Forwarding Variable.
If the served user has activated ACR then ACR takes precedence over Call Forwarding Busy.
If the served user has activated ACR, then Selective Call Forwarding (SCF) takes precedence over ACR. That is, if
the restricted identity matches that of an entry in the subscriber's SCF screening list, then the call is routed to the
destination specified by SCF and ACR is not applied.
Automatic Callback (AC)
If the served user has activated ACR, then ACR takes precedence over AC.
If AC has been requested and the AC target activates ACR during the recall period, then the call attempt based on
the AC service is subject to ACR.
Automatic Recall (AR)
If the served user has activated ACR, then ACR takes precedence over AR.
Distinctive Ringing/Call Waiting (DRCW)
If a subscriber has both ACR and DRCW, then DRCW takes precedence over ACR. That is, if the restricted identity
is that of an originator that is configured by the ACR subscriber to trigger DRCW, then ACR processing is not
invoked.
Emergency Services
Emergency call back overrides Anonymous Call Rejection.
Operator Services Emergency Interrupt overrides Anonymous Call Rejection.
Solicitor Blocking
Anonymous Call Rejection takes precedence over the screening by keypress version of Solicitor Blocking.
The screening by greeting record version of Solicitor Blocking takes precedence over Anonymous Call Rejection.
Do Not Disturb
Do Not Disturb takes precedence over Anonymous Call Rejection.

7.2.7.6 Call Flows

then the text requirements take precedence. Figure 21 illustrates the call flow for ACR activation or deactivation.
PacketCable
Phone UE AS
Network
“A” “A”
VSC
INVITE
INVITE
Check if originator is allowed to
(de)activate ACR and that
there are no other restrictions
on ACR (de)activation
AS applies confirmation media
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Confirmation
487 Request
Terminated
487 Request
Terminated
ACK
ACK
Figure 21 - Anonymous Caller Rejection (ACR) - Activation/deactivation

Figure 22 illustrates the call flow for the case where the terminating subscriber (B) has activated ACR and the
originator (A) has a restricted identity.
PacketCable
Phone UE AS
Network
“A” “A”
Call B
INVITE
INVITE
Verify that ACR is not
overridden due to originator
type or feature interaction.
Assume that it isn’t.
AS applies ACR denial media
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
ACR Denial Indication
433 Anonymity
Disallowed
433 Anonymity
Disallowed
ACK
ACK
Figure 22 - ACR - Originator has a restricted identity
7.2.8 MGC Considerations

The MGC requirements and procedures (including SIP to ISUP interworking) for supporting Caller Id for calls
between PacketCable and PSTN are specified in [CMSS1.5].
7.2.9 Caller-ID Per Call Toggle

This feature is similar to the Calling Number Delivery Blocking (CNDB) feature defined by [GR 391]. To use this
feature the caller does the following:
• Goes off-hook and receives dial tone.
• Enters the assigned vertical feature code. The feature code is provided to the UE via the digit map. (The
suggested default value is *67.)
For this one call, the permanent presentation status value is toggled: if the permanent presentation status value is
Public then it is changed to Anonymous, and if the permanent presentation status is Anonymous it is changed to
Public.
If the caller goes on hook at any point prior to completion of dialing the called party number, the feature has no
effect.


CNDB is carried out by the calling UE. As part of its CNDB-TOGGLE digit map action, the UE MUST check to see
if the CIDS-Suppression feature is available (i.e., CNDB is enabled if CIDS Suppression is enabled); and if the
feature is available, toggle the local privacy state on the UE. The UE MUST then play recall dial tone and be ready
to accept dialed digits. If the CIDS Suppression feature is not available, then the UE MUST play an error tone or
message.

The CNDB Feature uses the CIDS-S Feature Data specified in Section 7.2.4.3.

ACR
Activating CNDB when the permanent presentation status is public results in call rejection if the called party has
invoked the ACR feature.
AC
AC allows customers to place calls to the last call they called. CNDB can be activated before AC activations and
reactivations as well as before the original call is made. When an AC call is finally established, the most recent
Caller-ID delivery service that the AC customer activates determines the presentation status associated with the AC
customer.
If no Caller-ID delivery service is invoked immediately before AC activation or reactivation, then the AC must be
invoked using the same presentation status that was used when the customer originally entered the telephone number
to place the call.
If the feature code for CNDB is entered, and followed by the feature code for AC, then the AC must be invoked with
a presentation status of "anonymous" if the permanent presentation status is public or with a status of public if the
permanent presentation status is anonymous. This applies to both activation and reactivation of AC.
AR
AR allows customers to place calls to the last call they received. CNDB can be activated before AR activations and
reactivations. When an AR call is finally established, the most recent CIDS-x that the AR customer activates
determines the presentation status associated with the AR customer.
If the feature code for CNDB is entered, and followed by the feature code for AR, then the AR must be invoked with
a presentation status of "anonymous" if the permanent presentation status is public or with a status of public if the
permanent presentation status is anonymous. This applies to both activation and reactivation of AR.
SPCS shall not disclose the Caller ID to the AR customer when the call is finally established and the AR customer
gets ring back.
If a caller activates CNDB and the permanent presentation status is public, then the callee will not receive Caller ID,
including calling number. If a caller activates CNDB and the permanent presentation status is anonymous then the
callee may receive Caller ID, including calling number. Detailed results are covered in Section 7.2.2.


If a caller activates CNDB and the permanent presentation status is public, then the callee will not receive Caller ID,
including calling name. If a caller activates CNDB and the permanent presentation status is anonymous then the
callee may receive Caller ID, including calling name. Detailed results are covered in Section 7.2.2.
Operator Services
A caller should be able to access CNDB and operator services for the same call. A caller is able to dial the CNDB
feature access code before dialing a number that invokes operator services (if allowed by the digit map). The
resulting presentation status is used for any call the operator makes on behalf of the caller.
caller's presentation status was anonymous, an "anonymous" indication is included in the new screening list entry.
However, an "anonymous" entry in the screening list will not be displayed or otherwise be made available to the
customer.
Speed Dialing
A CNDB feature activation code may be entered as part of an entry in a speed-calling list.
When speed dialing is invoked, if the selected speed-calling list entry contains a CNDB feature activation code, then
the call is placed with that feature activated.
A speed-calling invocation may be entered following the entry of the CNDB feature activation code. In this case the
call is placed with that feature activated.
It is an error to enter a CNDB feature activation code followed by a speed-calling invocation if the selected speed-
calling list entry contains a CNDB feature activation code.
Three-Way Calling
A three-way call has two legs. The originator of each leg of the call may use CNDB during the initiation of that leg.
7.3 Call Forwarding

7.3.1 Overview
There are several different variations of call forwarding. UEs that implement any of the forwarding features
described in this section, MUST comply with requirements in Telcordia [GR 586], except as explicitly noted in this
document.
PacketCable call forwarding features include Call Forwarding Variable (CFV), Call Forwarding Busy Line (CFBL),
Call Forwarding Don't Answer (CFDA), Remote Activation of Call Forwarding (RACF), and Selective Call
Forwarding (SCF). These features operate on a per-public identity basis. This means that forwarding affects the
public identity, regardless of how many UEs are registered behind that public identity.
Call forwarding functions whether or not the subscriber has a UE registered with the PacketCable network.
Therefore, most aspects of Call Forwarding features are provided by an Application Server (AS), which is called the
Call Forwarding Application Server (CF AS). For all of the call forwarding features, the original caller's identity is
preserved in the P-Asserted-Identity header when forwarding a call.
The CF feature does not require the CF AS to record-route itself into the signaling path. If a CF AS does record-
route itself into the signaling path for this feature, all signaling is unnecessarily routed through CF AS, which is
inefficient.
7.3.1.1 Preventing Forwarding Loops and Limiting the Number of Forwarding Attempts
For each of the Call Forwarding features, the PacketCable network provides a mechanism to prevent forwarding
loops. A call forwarding loop is the scenario that occurs when a targeted subscriber for a call forwards the call to
another destination; if the forwarded-to destination also has call forwarding configured, the call can forward back
(directly or indirectly) to the original targeted subscriber. When a loop is detected, the network node that performs

the detection performs a configurable action, the default being call rejection. A CF AS MUST detect call forwarding
loops.
The CF AS MUST support a configurable limit on the number of times an individual call may be subject to
forwarding. If the number of forwarding attempts for a single call exceeds this limit, the CF AS MUST perform a
configurable action, the default being call rejection.
The CF AS SHOULD support loop prevention and forwarding limit detection via the mechanisms described in this
section. However, this mechanism alone may not be sufficient to detect loops when calls are forwarded to networks
not supporting these mechanisms (for example, the PSTN or a network not supporting the required SIP headers).
Therefore, a CF AS MAY support additional loop prevention and forwarding limit detection methods as long as the
requirements of forwarding limit restriction and loop detection are met.
If the CF AS supports the prevention of forwarding loops via analysis of the History-Info header present in the
INVITE, then it MUST compare the forward-to address with the set of targeted-to URI (hi-targeted-to-uri) entries
from the History-Info header. If there is a match, then a loop has occurred. If no History-Info header is present, then
it is not possible to perform loop detection via this mechanism.
If the CF AS determines that a loop has occurred (regardless of the loop detection method used), the CF AS MUST
handle the call based upon a configurable action. The CF AS MUST support the default loop detection action of call
rejection. The CF AS MUST send a final response appropriate to the type of call forwarding being performed if the
call is to be rejected. If the forwarding action is CFBL and the call is to be rejected, the CF AS MUST respond with
a 486 User Busy message. If the forwarding action is CFDA and the call is to be rejected, the CF AS MUST
respond with a 408 Request Timeout message. If the forwarding action is CFV or SCF and the call is to be rejected,
the CF AS MUST respond with a 480 Temporarily Unavailable message.
If the CF AS supports the prevention of forwarding loops by enforcing a maximum number of forwarding attempts,
then it MUST calculate the number of forwarding attempts by counting the number of entries in the History-Info
header that have nested Reason headers that include protocol-cause parameters and reason-text parameters populated
as defined in Section 7.3.1.2. If no History-Info header is present, then it is not possible to determine the number of
forwarding attempts via this mechanism.
If the number of forwarding attempts exceeds the configured limit, then the CF AS MUST handle the call based on a
configurable action. The CF AS MUST support the default action of call rejection. The CF AS MUST send a final
response appropriate to the type of call forwarding performed if the call is to be rejected. If the forwarding action is
CFBL and the call is to be rejected, the CF AS MUST respond with a 486 User Busy message. If the forwarding
action is CFDA and the call is to be rejected, the CF AS MUST respond with a 408 Request Timeout message. If
the forwarding action is CFV or SCF and the call is to be rejected, the CF AS MUST respond with a 480
Temporarily Unavailable message.
7.3.1.2 Setting of the Call Forwarding Parameters

After checking the number of forwards, a number of fields of the INVITE request are set by the CF AS as defined in
the following subsections.
7.3.1.2.1 First Forwarded INVITE
The absence of a History-Info header in the INVITE, or the presence of a History-Info with no entries containing a
nested Reason header with a protocol-cause parameter, means that this is the first instance of a forwarding action.
When this is the first forward the INVITE has undergone, the following requirements apply. The CF AS MUST set
the Request URI to the public user identity where the INVITE is to be forwarded. The CF AS MUST NOT change
the contents of the P-Asserted-Identity header in the INVITE.
The CF AS MUST set the History-Info header (redirection information, redirecting number, original called
number). Two History-Info entries MUST be generated as described below.
The first added entry in the History-Info header by the CF AS MUST include, as the hi-targeted-to-uri, the URI of
the called party that was addressed with this INVITE. If the called party's presentation status is set to anonymous,
the CF AS MUST escape the privacy header "history" within the hi-targeted-to-uri; a Reason is not added. If no
History-Info header was previously present in the INVITE, then the CF AS MUST set the Index to index=1. If this

is an additional entry to an already present History-Info header, then the CF AS MUST set the index according to
the rules in [RFC 4244].
The second added entry in the History-Info header by the CF AS MUST include, as the hi-targeted-to-uri, the
address to where the INVITE is forwarded. If no History-Info header was present prior to this procedure, then the
CF AS MUST set the index to index=1.1. If this is an additional entry to an already present History-Info header,
then the CF AS MUST set the index according to the rules in [RFC 4244].
When adding a second entry, the CF AS MUST also include a nested Reason header (redirecting reason and
redirecting indicator) escaped in the History-Info header, this is populated according to the forwarding conditions.
• [RFC 4458] defines the mapping between the forwarding conditions and the coding of the protocol-cause
parameter in the Reason header. The CF AS MUST populate the Reason header with a protocol-cause value of
"486" and a reason-text value of "CFBL" when the forwarding condition is CFBL. The CF AS MUST populate
the Reason header with a protocol-cause value of "408" and a reason-text value of "CFDA" when the
forwarding condition is CFDA. The CF AS MUST populate the Reason header with a protocol-cause value of
"302" and a reason-text value of "CFV/SCF" when the forwarding condition is CFV or SCF.
• Finally, the CF AS MUST set the To header as per the following rules. If the forwarding party does not request
privacy to be applied (that is, the presentation status is set to public), then the CF AS MUST NOT change the
To header. When the forwarding party requests privacy (that is, the presentation status is set to anonymous), the
CF AS MUST change the To header to be the URI to where the INVITE is forwarded.
7.3.1.2.2 Second or Subsequent Forwarded INVITE
When this is the second or subsequent forwarding of the INVITE, the CF AS MUST add a new entry to the History-
Info header according to the rules defined in [RFC 4244]. If the history entry representing the forwarding party
already contains the correct privacy value for the forwarding party (in an escaped privacy header), then the CF AS
MUST NOT modify the History-Info header. Otherwise, if the forwarding party requests privacy (that is, the
presentation status is set to anonymous), the CF AS MUST ensure the privacy header "history" is escaped within the
hi-targeted-to-uri.
The entry MUST contain, as the hi-targeted-to-uri, the address to where the INVITE is forwarded. The CF AS
MUST populate the Reason header (redirecting reason and redirecting indicator) escaped in this history-info header
according to the forwarding conditions and notification subscription option.
The CF AS MUST code the protocol-cause parameter in the Reason header based on forwarding conditions as
defined in [RFC 4458]. The CF AS MUST populate the Reason header with a protocol-cause value of "486" and a
reason-text value of "CFBL" if the forwarding condition is CFBL. The CF AS MUST populate the Reason header
with a protocol-cause value of "408" and a reason-text value of "CFDA" if the forwarding condition is CFDA. The
CF AS MUST populate the Reason header with a protocol-cause value of "302" and a reason-text value of
"CFV/SCF" if the forwarding condition is CFV or SCF. The CF AS MUST set the Request URI to the public user
identity where the INVITE is to be forwarded.
The CF AS MUST NOT change the contents of the P-Asserted-Identity header in the INVITE.
The CF AS MUST NOT change the To header field (original destination number) if the forwarding party does not
request privacy (that is, the presentation status is set to public). The CF AS MUST change the To header field to be
the URI where the INVITE is forwarded if the forwarding party requests privacy (that is, the presentation status is
set to anonymous).
Figure 23 illustrates a multiple forwarding scenario, and Table 25 describes how the headers are populated. In this
scenario, Alice calls Bob and is forwarded to Charlie, and is then forwarded to Ed and is, in turn, forwarded to Bob.
S-CSCF CF AS S-CSCF CF AS S-CSCF CF AS

P-CSCF Hop 1 Hop 2 Hop 3 Hop 4 Hop 5 Hop 6
(Alice) (Bob) (Charlie) (Charlie) (Ed) (Ed)
Figure 23 - Multiple Forwarding Scenario

Table 25 - Parameters And Header Fields that are Modified In A CF AS
Element P-CSCF S-CSCF (Alice)

H-I Index Added 1 1.1
Entry Added Bob@domain Bob@domain
H-I Header Bob@domain; index=1 Bob@domain; index=1,
Bob@domain; index=1.1
Element CF AS (Bob) S-CSCF (Charlie)

H-I Index Added 1.2,1.2.1 1.2.1.1
Entry Added Bob@domain, Charlie@domain
Charlie@domain?Reason=SIP;protocol-
cause=302;reason-text="CFV/SCF"
H-I Header Bob@domain; index=1, Bob@domain; index=1,
Bob@domain; index=1.1, Bob@domain; index=1.1,
<Charlie@domain?Reason=SIP;protocol- <Charlie@domain?Reason=SIP;protocol-
cause=302;reason-text="CFV/SCF">; index=1.2.1 cause=302;reason-text="CFV/SCF">; index=1.2.1,
Charlie@domain; index=1.2.1.1
Element CF AS (Charlie) S-CSCF (Ed)

H-I Index Added 1.2.1.2 1.2.1.2.1
Entry Added Ed@domain?Reason=SIP;protocol- Ed@domain
cause=302;reason-text="CFV/SCF"
H-I Header Bob@domain; index=1, Bob@domain; index=1,
<Charlie@domain?Reason=SIP;protocol- <Charlie@domain?Reason=SIP;protocol-
cause=302;reason-text="CFV/SCF">; cause=302;reason-text="CFV/SCF">; index=1.2.1,
index=1.2.1, Charlie@domain; index=1.2.1.1,
Charlie@domain; index=1.2.1.1, <Ed@domain?Reason=SIP;protocol-
<Ed@domain?Reason=SIP;protocol- cause=302;reason-text="CFV/SCF">; index=1.2.1.2,
cause=302;reason-text="CFV/SCF">; Ed@domain; index=1.2.1.2.1
index=1.2.1.2
Element CF AS (Ed)
H-I Index Added No entry is added since loop detection at Ed's CF
AS detects a Call Forwarding loop. The
forwarding target
Bob@domain is already present in the set of URIs
contained in the received H-I header.
Entry Added None as loop detection detects CF loop
H-I Header None as loop detection detects CF loop
7.3.1.3 MGC Inter-working

To prevent forwarding loops occurring between the PacketCable network and the PSTN, forwarding information
needs to be maintained by the MGC when mapping from SIP History Info header to ISUP and vice versa. The MGC
requirements and procedures (including SIP to ISUP interworking) for support of forwarding loop detection are
specified in [CMSS1.5].

7.3.2 Call Forwarding Variable

Call Forwarding Variable (CFV) is a feature that allows a subscriber to activate forwarding of all calls that go to the
subscriber's public identity to another location. The forward-to address can be provided through subscriber
interaction with the CFV feature, or the network operator can configure the forward-to address for a subscriber.
With CFV, the forwarding happens before the called party's UE alerts (rings) the called party, so the forwarded
public identity has no opportunity to answer the call.
The behavior of the CFV service, as defined in [GR 580], MUST be met by UEs with analog interfaces with the
following exceptions. The following sections and requirements within normative reference [GR 586] do not apply
to PacketCable networks. These deviations are additional to any divergences from [GR 586] detailed elsewhere in
this document:
• Tones may be substituted for the announcements described in [GR 580].
• Restriction for forwarding to "free numbers" found in [GR 580] do not apply.
• Charging requirements in [GR 580] do not apply.
• Billing requirements in [GR 580] do not apply.
• [GR 580] requirements related to business groups do not apply.
• Traffic and maintenance measurements requirements in [GR 580] do not apply.
UEs with non-analog interfaces are allowed to provide alternative user interfaces because different types of UEs
have widely varying user interface capabilities. In addition to the wide range of UEs, a service provider may offer a
web client mechanism the capability of allowing a subscriber to manage his or her service data. For this section,
however, descriptions are limited to interactions with the analog interface telephony client, rather than a service
management web client.
Call forwarding can be broken down into several distinct operations: activating forwarding (which includes
programming the forwarding number), deactivating forwarding, and the actual forwarding of incoming calls.

A user activates or deactivates CFV by dialing a vertical service code (VSC) according to the procedures described
in Section 7.1.2.
The user can activate or deactivate the CFV feature via the telephony user interface (that is, the phone keypad) by
entering a VSC. The CFV VSCs are defined for the UE as part of the Digit Map as defined in Section 7.1.1. Upon
matching the user-entered digits with the CFV VSC, the UE checks that the CFV feature is available (using
FEATURE-CHECK action defined in Table 1). If the feature is available, the UE performs the configured digit map
action as follows:
1. If the digit map action indicates that the UE collects the forward-to address, then the UE plays the recall dial
tone (using RECALL action defined in Table 1) and then carries out the USEMAP action. Within USEMAP,
the UE collects the forward-to address, using a MAKE-CALL action and sends the VSC, along with the
collected forward-to address, in an INVITE request to the CFV AS. The request URI for this INVITE is
specified in the MAKE-CALL and MUST include both the VSC and the forwarded-to-address.
2. If the digit map action indicates that the AS collects the forward-to address, then the UE uses the MAKE-CALL
action to send only the VSC in the request URI of the INVITE. Upon receipt of this INVITE, the AS can decide
whether to play an announcement or provide a dial tone to collect digits in-band.
Upon receipt of an INVITE with the CFV activation code, the CFV AS MUST respond with a 200 OK. When the
CFV AS receives the ACK from the UE, it MUST play a confirmation tone to the user. If the UE is currently
subscribed to the UA-Profile Event Package, the CFV AS MUST send a NOTIFY to the UE informing it that CFV
is activated, as per Section 7.1.12 Upon both activation and re-programming (activation with a new number while

currently active) of CFV, the CFV AS MUST reset its local call forward counter to zero (0) and provide this value in
the NOTIFY. If the UE is not currently subscribed to the UA-Profile Event Package, the UE MUST subscribe as
defined in Section 7.1.12. When the CFV AS receives the 200 OK to the NOTIFY, it MUST send a BYE to the UE
to end the session. If the activation fails, the CFV AS MUST play an error tone or announcement, followed by one
second of silence, and then send a BYE. If while processing user-entered digits, the UE carries out a FEATURE-
CHECK with the CFV feature-id and processes a subsequent MAKE-CALL, the resulting INVITE is considered to
be for either CFV activation or deactivation. Upon receipt of the BYE in response to this INVITE for CFV
activation,, the UE MUST apply dial tone and be ready to accept dialed digits, regardless of CFV activation success
or failure.
Once call forwarding programming is successful, the CFV AS MUST store the forwarded-to number in such a
manner that it remains persistent even in the case of power loss in the UE or network.
If the user-programmable CFV is currently activated, the subscriber tries to activate it to the same number, and
verification calling is enabled, the CFV AS MUST treat the attempt just like a second attempt and play a
confirmation tone (or an announcement) to the subscriber without actually calling the number.
If CFV verification is enabled, an initial attempt to program CFV MUST result in the CFV AS forwarding the call to
the forward-to address. If the call is answered, the CFV AS MUST consider CFV activated. If the call is not
answered, and the second verification call is disabled, the CFV AS MUST consider CFV activated. If the call is not
answered and the second verification call is enabled, the CFV AS MUST start a two minute timer when the
subscriber hangs up on the activation attempt. During the two minutes, the CFV AS MUST store the forward-to
address, but CFV is not yet activated.
If CFV second verification call is enabled, and a repeat attempt is made to activate CFV with the same forward-to
address and during the two-minute interval, the CFV AS MUST NOT attempt to call the forward-to number.
Instead, the CFV AS MUST consider CFV active and play a confirmation tone (or an announcement) to the
subscriber. If an attempt is made to activate CFV to a different forward-to address when a two minute timer is
running from a previous initial attempt, the CFV AS MUST cancel the two minute timer and treat the new activation
attempt as an initial attempt. If a second attempt is made to activate CFV and CFV is not active, but the attempt
falls outside the two minute interval, the CFV AS MUST treat the attempt as an initial attempt.
If while processing user-entered digits, the UE carries out a FEATURE-CHECK with the CFV feature-id and
processes a subsequent MAKE-CALL, the resulting INVITE is considered to be for either CFV activation or
deactivation. After any of the above CFV activation scenarios the UE MUST apply dial tone upon receipt of the
BYE and be ready to accept dialed digits in response to this INVITE for CFV activation.
Upon matching the user-entered digits with the CFV de-activation code, the UE carries out the FEATURE-CHECK
and MAKE-CALL digit map actions. As part of the MAKE-CALL action, the UE sends an INVITE with the request
URI capturing the VSC as per the network requirements. The request URI for this INVITE MUST comply with the
general form described in Section 7.1.2. Upon receipt of an INVITE with the CFV de-activation code, the CFV AS
MUST respond with a 200 OK. When the CFV AS receives the ACK from the UE, it MUST play a confirmation
tone to the user regardless of whether CFV is active or not. If the UE is subscribed to the UA-Profile Event
Package, the CFV AS MUST send a NOTIFY to the UE informing it that CFV is de-activated, per Section 7.1.12.
When the CFV AS receives the 200 OK to the NOTIFY, it MUST send a BYE to the UE to end the session. If
while processing user-entered digits, the UE carries out a FEATURE-CHECK with the CFV feature-id and
processes a subsequent MAKE-CALL, the resulting INVITE is considered to be for either CFV activation or
deactivation. Upon receipt of the BYE, the UE MUST apply dial tone and be ready to accept dialed digits in
response to this INVITE for CFV deactivation.
If the CFV forward-to number is provided by subscriber, the CFV AS MUST remove the number from its subscriber
data on successful deactivation of CFV. If the forward-to number is provided by service provider, CFV is marked
inactive, but the CFV AS MUST NOT erase the forward-to number. If there is a two minute timer running for a
verification second attempt when the CFV deactivation is received, the CFV AS MUST cancel the two minute
timer. CFV deactivation only results in error tone (or announcement) in the unlikely event that CFV is active and
cannot be deactivated.


At boot time, if the UE has received configuration indicating that CFV is part of the user profile, the UE will also
have received an AUID associated with CFV and followed the procedures defined in Section 7.1.12. The initial
NOTIFY from the CFV AS as a result of the initial post-boot time SUBSCRIBE will provide the UE with an
indication of the current activation status (as CFV could have potentially been previously activated). The initial
NOTIFY from the CFV AS also contains the call forward count since the last time the feature was activated or
programmed. The UE MUST set its local call forward count to the value received in the initial NOTIFY from the
CFV AS. Irrespective of feature activation status, the UE MUST continually refresh the subscription by sending a
re-SUBSCRIBE to the CFV AS for the ua-profile event package prior to the expiration of the call forwarding
subscription duration, as described in Section 7.1.12.
If the special conditions dial-tone is enabled for subscribers with the CFV feature activated, then each time a
subscriber with CFV activated goes off hook, the UE MUST play the special conditions dial-tone as a reminder that
CFV is active.
Upon receipt of an INVITE destined to a UE for which CFV is active, the CFV AS determines whether the call can
be forwarded or not (operator services calls and emergency services calls are not forwarded).
If the call can be forwarded, the CFV AS MUST re-write the request-URI with the stored forward-to address, insert
a history-info header in accordance with Section 7.3, follow the route header in the request and send it back to the S-
CSCF.
When a call is forwarded, if the originally targeted UE is subscribed to the ua-profile event package as per Section
7.1.12, the CFV AS MUST send a NOTIFY informing the originally targeted UE that a call has just been
forwarded. Upon receipt of the NOTIFY, the UE examines the received XML document and compares the network
call forward count with its local copy; if the network value is numerically greater than the UE value, this indicates
that a new call has been forwarded and the UE MUST play ringsplash if provisioned to provide ring reminder. The
UE MUST NOT play ringsplash if the call forward count received in the NOTIFY is less than or equal to the value
stored on the UE. The UE MUST set its local call forward count to that received in the NOTIFY, for comparison to
the value in potential future NOTIFY messages.
If the CFV AS determines that the call cannot be forwarded, the CFV AS MUST return an error response to the
requesting UE.
The CFV AS MUST NOT forward the INVITE if the number of sequential forwards allowed is exceeded and
MUST return the error response to the requesting UE.

Table 26 summarizes the feature data items that are defined in support of CFV.
Table 26 - Call Forwarding Variable Feature Data
Data Type Scope Stored by Written by Read Config.Server

by Requirement
Forward-to address SIP or Tel URI Per public AS AS AS None
user ID
user ID
User provided forward-to address Boolean Per public AS AS AS None
user ID
Feature activation status Boolean Per public AS AS AS None
user ID
Verification/courtesy call required indicator Boolean Per network AS AS AS None
Verification/courtesy call 2nd attempt or Boolean Per network AS AS AS None
answer required indicator (see Note 1)
Verification 1st number attempted (see SIP or Tel URI Per public AS AS AS None
Note 1) user ID


by Requirement
Number of sequential forwards allowed Integer, Per network AS AS AS None
0=disabled
Forwarding to toll number allowed indicator Boolean Per public AS AS AS None
user ID
Forwarding to IDDD allowed indicator Boolean Per public AS AS AS None
user ID
Forwarding with carrier access code Boolean Per public AS AS AS None
allowed indicator (see Note 2) user ID
Special conditions dial-tone when Boolean Per network Config.Server Config.Server UE Mandatory
forwarded indicator
Call Forward Ring Reminder Boolean Per public Config.Server Config.Server UE Mandatory
user ID
Call Forwarding Subscription Duration Integer Per public Config.Server Config.Server UE Mandatory
(seconds) user ID
Number of Calls Forwarded Since Integer Per public AS AS AS, None
Activation user ID UE
Note 1: Applicable only if verification/courtesy calls are enabled.
Note 2: See [PKT 24.229] for rules for populating the Request URI for address digits containing carrier access code.
Table 27 - Call Forwarding Variable UA-Profile Event Package Data Elements

by Requirement
Call Forwarding Variable Boolean Per public user ID AS AS AS, None
Activation Status (0=inactive, 1=active) UE
Number of Calls Forwarded Integer Per public user ID AS AS AS, None
Since Activation UE

Call Forwarding Variable has no interaction with calls that originated from a public identity with call forwarding
activated.
Call Blocking
The CFV AS MUST NOT allow the activation of the call forwarding variable to blocked numbers. The CFV AS
MUST give error notification in response to this activation request.
Call Forwarding Busy Line (CFBL)
When CFV is deactivated, CFBL takes precedence.
When activated, CFV takes precedence over CFBL.
Call Waiting (CW)
On a line that is activating CFV, CW is not applied after the answer is received or the confirmation tone is returned.
Cancel Call Waiting (CCW)
When activated, CFV takes precedence over CW. Although CCW has no effect in this situation, the UE SHOULD
still return recall dial tone after the customer dials the CCW access code and receive the telephone number dialed by
the customer. The UE SHOULD allow a customer to disable CW while CFV is activated.
The UE SHOULD allow customers who subscribe to both CFV and CW to dial the access codes for both on a single
call as long as the CCW access code is dialed first. For example, the following dialing sequence is allowed:
1. Customer dials *70 (CCW)

2. Recall dial tone returned

3. Customer dials *72 (CFV)
4. Return recall dial tone
5. Customer dials the telephone number of the remote station
6. Remote station is rung
7. Remote station answers
This sequence results in CW being disabled for the duration of the call, and CFV being activated to the remote
station.
IDDD Via an Operator System
The CFV AS MUST NOT allow 010 and 01+ as "forward to" numbers.
Call forwarding to international destinations outside World Zone 1 on an 011+ basis is permitted, but not required,
when these interLATA calls utilize InterLATA Carrier/International Carrier (IC/INC) interconnection (Feature
Group D) access arrangements. If call forwarding to IDDD is allowed on an 011+ basis, the telephone company
should be provided the ability to inhibit lines from activating call forwarding to 011+ destinations on an office basis
and, optionally, on a per line basis.
Emergency Service (911)
The CFV AS SHOULD NOT allow 911 as a "forward to" number.
IC/INC Interconnection
A 10XXX (+1) + 7/10 digit number may be the remote number whether the CFV feature is activated by the
customer or by subscriber provider provisioning. Calls terminating from an IC/INC may be forwarded. When call
forwarding is initiated without a 10XXX prefix, calls should be forwarded via the presubscribed carrier.
The remote number should be a 7- or 10-digit number, but call forwarding can also be initiated by means of AD2 by
dialing the "call forwarding activation code" +10XXX + a "speed dialing number."
The CFV AS MUST NOT allow 950-WXXX as a "forward to" number.
Call forwarding to international destinations outside World Zone 1 on a 011+ basis is permitted but not required
when these interLATA calls utilize IC/INC interconnection (FGD) access arrangements. If call forwarding to IDDD
is allowed on an 011+ basis, the telephone company should be provided the ability to inhibit lines from activating
call forwarding to 011+ destinations on an office basis and, optionally, on a per line basis.
A CFV customer activates the feature in two ways. In one way, the customer follows the activation procedure and
the attempted call is answered, activating the feature. In the second way, the call is not answered. However, if the
entire activation procedure is repeated within two minutes to the same DN, the feature is activated. In this second
method, the customer need not indicate the same carrier in both activation attempts (using 10XXX prefix or
presubscription). The carrier given on the second attempt is the one used for forwarded calls.
Error conditions during activation and during an attempted forwarding of a call are handled as described in
[GR 580].
Do Not Disturb
Do Not Disturb takes precedence over Call Forwarding Variable.
Network-Based Call Screening
When the Forward-to address for the Call Forwarding Variable feature is the voicemail server, Network-Based Call
Screening takes precedence. Otherwise, Call Forwarding Variable takes precedence over Network-Based Call
Screening.
Solicitor Blocking
Call Forwarding Variable takes precedence over Solicitor Blocking.

Operator Services
The CFV AS MUST NOT allow 0-, 0+, or X11 as a "forward to" number.
For an exception, see the interaction of call forwarding variable with IDDD via an operator system.
The CFV AS SHOULD return a 486 to a Busy Line Verify INVITE with Join header.
Selective Call Forwarding
Selective Call Forwarding takes precedence over Call Forwarding Variable.
7.3.2.6 Call Flows

Call flows contained in this section illustrate the Call Forwarding Variable (CFV) feature. The call flows are for
example purposes only, and are not normative, so if there is a discrepancy between the written text requirements and
these call flows, the written text requirements take precedence.
Figure 24 illustrates CFV activation procedure, where the user at the "forward to" address answers the call.
PacketCable
Phone UE AS UE Phone
Network
“A” “A” "B" “B”
VSC
Recall
Dial Tone
Forward-to
address
INVITE
INVITE
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-B Connected
NOTIFY
NOTIFY
200 OK NOTIFY
200 OK NOTIFY
Figure 24 - Call Forwarding Variable (CFV) - Activation with User-provided Address

Figure 25 illustrates CFV activation procedure, where the user at the "forward to" address does not answer the call.
PacketCable
Network
“A” “A” "B" “B”
VSC
Recall
Dial Tone
Forward-to
address
INVITE
INVITE
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
Tone
On-hook
CANCEL
CANCEL
Forward-to address recorded
temporarily; AS starts two
minute timer
CANCEL
CANCEL
200 OK CANCEL
200 OK
CANCEL
200 OK
CANCEL
200 OK
CANCEL
487 Request Terminated
487 Request
Terminated
487 Request
Terminated
487 Request
Terminated
ACK
ACK
ACK
ACK
Figure 25 - CFV - Activation with User-Provided Address - No Answer at Fwd-to Address

Figure 26 illustrates the CFV activation procedure, in which the user at the "forward to" address does not answer the
call, and the subscriber makes a second attempt to the same number within two minutes of the first attempt.

PacketCable
Phone UE AS
Network
“A” “A”
VSC
INVITE
INVITE
AS activates forwarding
to stored address
200 OK
200 OK
ACK
ACK
Confirmation Tone
NOTIFY
NOTIFY
200 OK NOTIFY
200 OK NOTIFY
BYE
BYE
Dial Tone
200 OK BYE
200 OK BYE
Figure 26 - CFV - Activation with User-provided Address - Second Attempt within Two Minutes to the Same
Address

Figure 27 illustrates CFV activation procedure, where verification call is not enabled.
PacketCable
Phone UE AS
Network
“A” “A”
VSC
INVITE
INVITE
200 OK
200 OK
ACK
ACK
Confirmation Tone
NOTIFY
NOTIFY
200 OK NOTIFY
200 OK NOTIFY
BYE
BYE
Dial Tone
200 OK BYE
200 OK BYE
Figure 27 - CFV - Activation to a Fixed Number

Figure 28 illustrates CFV deactivation procedure.
PacketCable
Phone UE AS
Network
“A” “A”
VSC
INVITE
INVITE
200 OK
200 OK
ACK
ACK
Confirmation Tone
NOTIFY
NOTIFY
200 OK NOTIFY
200 OK NOTIFY
BYE
BYE
Dial Tone
200 OK BYE
200 OK BYE
Figure 28 - CFV - Deactivation

Figure 29 illustrates a call being forwarded when the CFV feature is active for the callee.
PacketCable
Phone UE AS UE Phone UE Phone
Network
“A” “A” "B" “B” "C" “C”
Call B
INVITE
INVITE
INVITE
INVITE
Power
NOTIFY
Ringing
NOTIFY
Ringsplash
200 OK
200 OK
180 Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
Off-hook
Tone
200 OK
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-C Connected
Figure 29 - CFV - Forwarded Call
7.3.3 Call Forwarding Don't Answer

Call Forwarding Don't Answer (CFDA) is a feature that allows forwarding of all unanswered calls to the subscriber's
public identity to another location. With CFDA, the forwarding happens after a pre-provisioned timeout if the
forwarded public identity has not answered the call.
The behavior, as described in Telcordia [GR 586], MUST be followed by UEs with analog interfaces, with the
following exceptions. The following sections and requirements within normative reference [GR 586] do not apply
to PacketCable networks. These deviations are additional to any divergence from [GR 586] detailed elsewhere in
this document:
• UEs are not required to support single key activation/deactivation, as described in [GR 586].
• Forwarding restrictions based on source or destination addresses [GR 586] do not apply.
• Tones may be substituted for the announcements described in [GR 586].
• Restriction for forwarding to "free numbers" found in [GR 586] does not apply.


• Statements in [GR 586] regarding announcement of forwarding do not apply.
• The comments about gain in [GR 586] do not apply.
• Statements in [GR 586] regarding no-answer on local switch do not apply.
have widely varying user interface capabilities. In addition to the wide range of UEs, an operator may offer a web
client mechanism to allow a subscriber to manage his or her service data. For this section, however, descriptions are
limited to interactions with the analog interface telephony client, rather than a service management web client.

The activation and deactivation of the CFDA feature is performed by the service provider as part of the service
provisioning for a user. The associated provisioning procedures are outside of the scope for this specification.
However, the feature activation/deactivation status is made available to the CFDA AS.

For calls placed to a public identity that is subscribed to CFDA, the INVITE is proxied to a CFDA AS. Upon receipt
of the initial INVITE, the CFDA AS MUST forward the INVITE to the target UE. Upon receipt of a 180 Ringing
response to the INVITE, the CFDA AS MUST start the no answer timer unless resource reservation is in progress
and this reservation is not complete. If resource reservation is in progress, then the CFDA AS MUST NOT start the
no answer timer until it proxies an updated SDP from the calling party showing that the resources are now reserved.
If the no answer timer expires before a 200 OK to the INVITE is received, the CFDA AS MUST send a CANCEL to
the target UE, and determine whether this call can be forwarded (for example, operator services calls and emergency
services calls are not forwarded). If the call can be forwarded, the CFDA AS MUST re-write the request-URI with
the provisioned forward-to address, insert a history-info header in accordance with Section 7.3, follow the route
header in the request, and send the INVITE back to the S-CSCF.
If the CFDA AS fails to receive any response to the INVITE from the target UE within the SIP response timeout, the
CFDA AS MUST determine whether this call can be forwarded (for example, operator services calls and emergency
services calls are not forwarded). If the call can be forwarded, the CFDA AS MUST re-write the request-URI with
the provisioned forward-to address, insert a history-info header in accordance with Section 7.3, follow the route
header in the request, and send the INVITE back to the S-CSCF.
If the CFDA AS determines that the call cannot be forwarded, the CFDA AS MUST return an error response to the
requesting UE.
The CFDA AS MUST NOT forward the INVITE if the number of sequential forwards allowed is exceeded and

Table 28 summarizes the feature data items that are defined in support of CFDA.
Table 28 - Call Forwarding Don't Answer Feature Data

Forward-to address SIP or Tel URI Per public user ID AS AS AS None
Feature availability status Boolean Per public user ID AS AS AS None
No answer timeout Integer (seconds) Per public user ID AS AS AS None
Number of sequential forwards allowed Integer, 0=disabled Per network AS AS AS None


CFDA has no interaction with calls originated from a public identity with call forwarding activated.
Call Forward Variable (CFV)
CFV takes precedence over CFDA.
Call Forward Busy Line (CFBL)
When the UE is not registered on the network, CFBL takes precedence over CFDA for determination of the
forward-to address.
In the instance where multiple UEs exist behind the public identity, in which at least one is busy and at least one is
idle, the CFDA AS MUST determine this to be a no answer scenario, not a busy scenario.
Call Waiting (CW)
If a CFDA subscriber receives an additional call offering via CW and the subscriber does not answer the additional
call, CFDA is applied upon expiry of the no answer timer.
Call Blocking
The selection of the remote address is not allowed to violate outbound call blocking restrictions.
Do Not Disturb
Do Not Disturb takes precedence over CFDA.
When the Forward-to address for the CFDA feature is the voicemail server, Network-based Call Screening is
activated upon CFDA timer expiration. Otherwise CFDA takes precedence over Network-based Call Screening.
Selective Call Forwarding takes precedence over CFDA.
7.3.3.6 Call Flows

The following call flows illustrate the CFDA feature. The call flows are not normative, so if there is a discrepancy
between the written text requirements and these call flows, the written text requirements take precedence.

Figure 30 illustrates a call being forwarded due to No Answer timeout.
PacketCable
Network
“A” “A” "B" “B” "C" “C”
Call B
INVITE
INVITE
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
AS starts no
answer timer
180 Ringing
180 Ringing No answer
Ringback timer expires
Tone
CANCEL
CANCEL
200 OK CANCEL
200 OK
CANCEL
487 Request
Terminated
ACK
ACK
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-C Connected
Figure 30 - Call Forward Do Not Answer (CFDA) - Establishment Due to No Answer Timeout

Figure 31 illustrates a call being forwarded due to SIP response timeout.
PacketCable
Network
“A” “A” "B" “B” "C" “C”
Call B
INVITE
INVITE
INVITE
INVITE
SIP response timer
expires before UE replies
with a response
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-C Connected
Figure 31 - CFDA - Establishment Due to SIP Response Timeout
7.3.4 Call Forwarding on Busy

Call Forwarding Busy Line (CFBL) is a feature that allows a subscriber to forward calls addressed to the
subscriber's public identity to another location when the subscriber is not capable of receiving another incoming call.
For CFBL, the forward-to address is configured by the network operator, so, unlike CFV, the subscriber cannot
designate the forward-to address by dialing a feature activation code and entering a forward-to address. With CFBL
the forwarding happens immediately upon detection that the public identity cannot receive the call and the
forwarded public identity has no opportunity to answer the call.
The behaviors, as described in Telcordia [GR 586], are followed by UEs with analog interfaces, with the following
exceptions. The following sections and requirements within normative reference [GR 586] do not apply to
PacketCable networks. These deviations are additional to any divergence from [GR 586] detailed elsewhere in this
document:
• UEs are not required to support single key activation/deactivation, as described in [GR 586].
• Forwarding restrictions based on source or destination addresses, as described in [GR 586], do not apply.
• Tones may be substituted for the announcements, described in [GR 586].
• Restriction for forwarding to "free numbers" found in [GR 586] does not apply.

• Statements in [GR 586] regarding announcement of forwarding do not apply.

• The comments about gain in [GR 586] do not apply.
• Statements in [GR 586] regarding no-answer on local switch do not apply.

The activation and deactivation of the CFBL feature is performed by the service provider as part of the service
provisioning for a user. The associated provisioning procedures are outside of the scope for this specification.
However, the feature activation/deactivation status is made available to the CFBL AS.

For calls placed to a public identity that is subscribed to CFBL, the INVITE is proxied to a CFBL AS. Upon receipt
of the initial INVITE, the CFBL AS MUST forward the INVITE to the target UE. If the CFBL AS receives a 486
BUSY in response to the INVITE, the CFBL AS determines whether the call can be forwarded by checking the
feature availability status for the target UE and for the presence of a forward-to-address. If the CFBL AS determines
the call is eligible for forwarding, the CFBL AS MUST replace the request URI in the original INVITE with the
forward-to address, and forward the INVITE to the new target.
If the CFBL AS determines that the call cannot be forwarded, the CFBL AS MUST return the error response to the
requesting UE.
If the CFBL AS does not receive a response to the forwarded INVITE, the CFBL AS MUST NOT invoke the CFBL
procedures and interprets this as a Call Forward Don't Answer (CFDA) condition.
For all other responses to the forward INVITE, the CFBL AS MUST proxy the response back to the requesting UE.
The CFBL AS MUST NOT forward the INVITE if the number of sequential forwards allowed is exceeded and

Table 29 summarizes the feature data items that are defined for the implementation of CFBL.
Table 29 - Call Forwarding Busy Line Feature Data

Requirement
Forward-to address SIP or Tel URI Per public user ID AS AS AS None
Number of sequential Integer, 0=disabled Per network AS AS AS None
forwards allowed

Call Forwarding Busy Line has no interaction with calls originating from a public identity with call forwarding
activated.
Call Forward Variable (CFV)
CFV takes precedence over CFBL.
Call Waiting (CW)
If a CFBL subscriber is also subscribed to CW, then the UE MUST invoke the Call Waiting procedures, as defined
in Section 7.5.2, for the first additional call offered. Further, if the UE is handling two calls under CW, the UE
MUST return a 486 Busy response to subsequent INVITE requests.

Call Blocking
The remote address is subject to outbound call blocking restrictions.
Operator Services
Busy Line Verification takes precedence over CFBL.
Emergency Interrupt takes precedence over CFBL.
Do Not Disturb (DND)
For calls to CFBL subscribers who have DND activated, the UE MUST reject all INVITE requests with a 486 Busy
response.
7.3.4.6 Call Flows

The following call flow illustrates the CFBL feature. The call flows are not normative, so if there is a discrepancy
between the written text requirements and these call flows, the written text requirements take precedence.
PacketCable
Network
“A” “A” "B" “B” "C" “C”
Call B
INVITE
INVITE
INVITE
INVITE
486 Busy
486 Busy
ACK
ACK
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-C Connected
Figure 32 - Call Forward Busy Line (CFBL) - Establishment
7.3.5 Selective Call Forwarding

Selective Call Forwarding (SCF) is an incoming call management feature that allows customers to define a special
list of addresses and remote addresses. Incoming calls from public identities that are on the list are forwarded to the

remote address. With SCF, the forwarding happens immediately and the original target public identity has no
opportunity to answer the call.
SCF differs from the other call forwarding features in that it is dependent upon the Screening List Editing (SLE)
feature. A subscriber activates, deactivates, and configures the SCF feature by dialing a vertical service code (VSC)
(typically *63 and/or *83). Each VSC typically provides the subscriber with access to the same set of SCF
capabilities. This allows service providers that currently have subscribers using *63 and *83 as separate activation
and deactivation codes to continue such use while permitting other service providers that are not currently providing
screening list features to advertise just one VSC.
The behavior, as described in Telcordia [GR 217], are met by UEs with analog interfaces. The following sections
and requirements within normative reference [GR 217] do not apply to PacketCable networks. These deviations are
additional to any divergences from [GR 217] detailed elsewhere in this document:
• Forwarding restrictions to "free numbers" do not apply.
• Charging requirements do not apply.
• The billing requirements in [GR 217] do not apply.
• Traffic and maintenance measurements requirements do not apply.
• The maintenance requirements do not apply.
client mechanism to allow a subscriber to manage his or her service data. For this section, however, descriptions are
limited to interactions with the analog interface telephony clients, rather than service management web clients.

The user can activate or deactivate the SCF feature via the telephony user interface (that is, the phone keypad) by
entering a VSC. The SCF VSCs are defined for the UE as part of the Digit Map defined in Section 7.1.1. Upon
matching the user-entered digits with the SCF VSCs, the UE carries out the FEATURE-CHECK and MAKE-CALL
actions. If the feature availability status indicates that the SCF feature is not available, then the UE MUST NOT
send the VSC to the SCF AS. If the feature availability status indicates that the SCF feature is available, then the
UE MUST send the VSC in an INVITE to the SCF AS using the general form of request URI described in Section
7.1.2. The SCF AS MAY, in turn, connect the user to an IVR system for SCF programming and activation and
deactivation.
As part of the SCF programming operation, the SCF AS MUST provide the user with an SLE feature, as described
in Section 7.6.7, to program a list of callers (that is, their public user IDs) who are subject to SCF treatment when
the SCF feature is in effect. The list of callers is stored in the Screen List attribute defined in Table 30. Further, the
user has the ability to disable the use of SCF Screen List through the use of the Feature Activation Status attribute
defined in Table 30.
At boot time, if the UE has received configuration indicating that SCF is part of the user profile, the UE will also
have received an AUID associated with CFV and followed the procedures defined in Section 7.1.12. The initial
NOTIFY from the SCF AS as a result of the initial post-boot time SUBSCRIBE will provide the UE with an
indication of the current activation status (as SCF could have potentially been previously activated). The initial
NOTIFY from the SCF AS also contains the call forward count since the last time the feature was activated or
programmed. The UE MUST set its local call forward count to the value received in the initial NOTIFY from the
SCF AS. Irrespective of feature activation status, the UE MUST continually refresh the subscription by sending a
re-SUBSCRIBE to the SCF AS for the ua-profile event package prior to the expiration of the call forwarding
subscription duration, as described in Section 7.1.12.
When the activation state of SCF feature changes, the SCF AS MUST send a NOTIFY to the UE indicating the
activation state of SCF as per Section 7.1.12. Upon activation of SCF, the SCF AS MUST reset its local call forward
counter to zero (0) and provide this value in the NOTIFY. The UE MUST set its local call forward count to the
value received in the confirmation NOTIFY.

Once the remote address is specified, the SCF AS MUST store the forward-to address in such a manner that it
remains persistent even in the case of power loss in the UE or the SCF AS. Similarly, the SCF AS MUST store the
screening list for SCF in such a manner that it remains persistent even in the case of power loss in the UE or SCF
AS.

Upon receipt of an INVITE, the SCF AS decides if the INVITE needs to be presented to the called UE based on the
current status of the SCF feature and whether the calling party is present in the Screen List. The current feature
status is determined by the feature provisioning information and the activation/deactivation status previously set by
the user (via the telephony user interface or the web portal).
If the SCF feature is not active, the SCF AS MUST forward the INVITE to the called party.
If the SCF feature is active, the SCF AS tries to match the calling party's public user ID with an entry in the Screen
List. If a match is established, the SCF AS MUST forward the INVITE to the forward-to address by rewriting the
request URI of the INVITE to that of the forward-to address, insert a history-info header in accordance with Section
7.3, and preserve the originating calling line identification. An address can exist on an SCF list as a Tel URI in an
extension format (when applicable), in its 7/10 digit format, in both formats (that is, two entries on the list) or as a
SIP URI. When the address of an incoming call is compared to the customer's SCF list, a match should be found if
that address exists on the list in any format, regardless of the format of the incoming address.
Further, if the UE is subscribed to the ua-profile Event Package, then the SCF AS MUST send a NOTIFY request
informing the originally targeted UE that a call has just been forwarded. The SCF AS MUST set the contents of the
NOTIFY according to the schema defined in Section 7.1.12.3. The UE examines the received XML document from
the NOTIFY and compares the network call forward count with its local copy; if the network value is numerically
greater than the UE value, this indicates that a new call has been forwarded and the UE MUST play ringsplash if the
Call Forward Ring Reminder is set. The UE MUST NOT play ringsplash if the call forward count received in the
NOTIFY is less than or equal to the value stored on the UE. The UE MUST set its local call forward count to that
received in the NOTIFY, for comparison to the value in potential future NOTIFY messages.
If the SCF feature is active and a match is not found, the SCF AS MUST forward the INVITE to the called party.

Table 30 summarizes the feature data items that are defined for the implementation of SCF.
Table 30 - SCF Feature Data

Requirement
Forward-to address SIP or Tel Per public AS AS AS None
URI user ID
Feature availability status Boolean Per public AS AS AS None
user ID
Feature activation status Boolean Per public AS AS AS None
user ID
Screening List List of SIP or Per public AS AS AS None
Tel URIs user ID
Number of sequential forwards Integer, Per network AS AS AS None
allowed 0=disabled
Forwarding to toll number allowed Boolean Per public AS AS AS None
indicator user ID
Forwarding to IDDD allowed Boolean Per public AS AS AS None
indicator user ID
Forwarding with carrier access code Boolean Per public AS AS AS None
allowed indicator user ID
Call Forward Ring Reminder Boolean Per public Config.Server Config.Server UE Mandatory
user ID

Table 31 - Selective Call Forwarding UA-Profile Event Package Data Elements
Data Type Scope Stored by Written Read by Config.Server

by Requirement
Selective Call Forwarding Activation Boolean (0=inactive, Per public AS AS AS None
Status 1=active) user ID
Number of Calls Forwarded Since Integer Per public AS AS AS None
Activation user ID

Selected Call Forwarding has no interaction with calls originated from a public identity with call forwarding
activated.
Call Blocking
The remote address for SCF is subject to outbound call blocking restrictions.
Speed Dialing
Speed dialing codes may be used to specify the SCF remote DN.
IC/INC Interconnection
The SCF AS MUST NOT allow forward-to addresses to be 950-WXXX numbers.
When a call is forwarded using an Interexchange or International Carrier (IC/INC), the SCF AS MUST provide the
address of the forwarding UE to the carrier for billing purposes.
Call Forwarding
SCF always takes precedence over other Call Forwarding services assigned to the same UE (Call Forwarding
Variable, Call Forwarding Don't Answer, and Call Forwarding Busy Line). When SCF and another Call Forwarding
service exists on the same UE, the remote addresses specified for the respective services may differ and are expected
to differ.
If a forwarded call is received at a line that has SCF active, the SCF AS MUST match the Screen List against the
originating address (not a forwarding address). If the originating address is indicated on the screening list, the SCF
AS forwards the call. See above for restrictions concerning multiple call forwarding sequences.
Distinctive Ringing/Call Waiting (DRCW)
SCF takes precedence over Distinctive Ringing/Call Waiting.
Do Not Disturb (DND)
SCF takes precedence over Do Not Disturb.
Call Waiting (CW)
SCF takes precedence over Call Waiting.
Automatic Callback (AC)
If a person attempts to activate AC to a UE that has SCF active, the AC customer's address is checked against the
SCF list. If the address is on the list, SCF AS MUST reject the AC request since the status of the remote line cannot
be checked. If the number does not match the list, the SCF AS MUST process the INVITE as described in Section
7.3.5.3.
Automatic Recall (AR)
If a person attempts to activate AR to a line that has SCF active, the AR customer's address is checked against the
SCF list. If the address is on the list, the SCF AS MUST reject the AR request since the status of the remote line
cannot be checked. If the number does not match the list, the SCF AS MUST process the INVITE as described in
Section 7.3.5.3.


When the Forward-to address for the Selective Call Forwarding feature is the voicemail server, Network-Based Call
Screening takes precedence. Otherwise, Selective Call Forwarding takes precedence over Network-Based Call
Screening.
7.3.5.6 Call Flows

Figure 33 illustrates selective call forwarding. The call flows are not normative, so if there is a discrepancy between
the written text requirements and these call flows, the written text requirements take precedence.
PacketCable
Network
“A” “A” "B" “B” "C" “C”
Call B
INVITE
INVITE
AS confirms A is on
B’s SCF list
INVITE
INVITE
Power
NOTIFY
Ringing
NOTIFY
Ringsplash
200 OK NOTIFY
200 OK NOTIFY
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
A-C Connected
Figure 33 - Selective Call Forwarding (SCF) - Forwarded Call
7.3.6 Remote Activation of Call Forwarding

The Remote Activation of Call Forwarding (RACF) feature allows a subscriber who also subscribes to call
forwarding variable to control CFV from another location (not from the UE being forwarded). In order to prevent
unauthorized forwarding, the subscriber is required to provide a PIN or password when activating or deactivating
RACF. PIN numbers can be specified by the service provider. The service provider may also allow the subscriber to
create or modify PIN numbers using the SPP feature.
client mechanism which allows a subscriber to manage his or her service data. For this section, however,

descriptions are limited to interactions with the analog interface telephony client, rather than a service management
web client.

To manage RACF, the subscriber places a call to the RACF service access address and follows the RACF service
prompts provided by the RACF AS.
The RACF AS activation and deactivation procedures follow those for CFV. Thus, the RACF AS MUST implement
the CFV procedures as defined in Section 7.3.2.2.
If RACF programming fails for any reason, the RACF AS MUST NOT change the CFV status.
If a subscriber successfully deactivates CFV via RACF, but CFV was not activated in the first place, the RACF AS
MUST play a confirmation indication to the subscriber anyway.
If a subscriber already has CFV activated when he or she successfully programs CFV via RACF, the new forward-to
address provided via the RACF programming overrides the pre-existing CFV programming and the UE MUST
provide a confirmation indication to the subscriber.
If a subscriber dials an invalid forward-to address while programming CFV via RACF (as described in the CFV
section), the RACF AS MUST prompt the subscriber to enter a different address.
If the RACF AS receives a BYE from the UE prior to the confirmation tone on an RACF programming attempt, the
RACF AS MUST NOT change the CFV status.

RACF is solely an activation and deactivation feature. There is no call processing impact for RACF.

Table 32 summarizes the feature data items that MUST be supported for the implementation of RACF.
Table 32 - Remote Activation of Call Forwarding Feature Data

RACF PIN Digits Per public user ID AS AS AS None

Call Forward Variable
RACF is simply another way to program CFV, so RACF and CFV share the same forward-to number and activation
status.
The RACF subscriber is also subscribed to CFV.
If the RACF PIN code is to be user programmable, the RACF subscriber is subscribed to SPP.
Restrictions on the forward-to address are identical to those for CFV.
7.3.7 Call Forwarding to Voice Mail

Call forwarding to voice mail is achieved by the service provider provisioning the CFDA and CFBL features with a
forward-to address of the voice mail system. Some network operators may wish to allow the voice mail system to
know why the call was forwarded (busy versus no answer, for example). The CF AS MAY insert reason information
in the INVITE response per [RFC 4458].

7.4 Call Blocking Features

7.4.1 Outbound Call Blocking
Outbound Call Blocking (OCB) prevents UEs from making calls to specific public identities. Service providers
typically offer this feature as one or more named outbound call blocking services. Examples include International
Call Blocking, Local Directory Assistance Call Blocking, Long Distance Directory Assistance Call Blocking,
900/976 Call Blocking, and Toll Call Blocking.
The digit map syntax supports the ability to allow outbound call blocking for the following dial string types:
• 900/976 Blocking (1900 and 1976)
• Direct-dialed international calls (011+)
• Direct-dialed calls (1+)
• Operated-assisted calls (0+)
• Operator-assisted international calls (01+)
• Operator-request calls (0-, that is, 0 followed by a # or 4-second timeout)
• Local directory assistance calls (411)
• Long distance directory-assistance calls (555)
• Carrier access code (+10XXX)
• Any destination that can be represented as a dial string

AS-Based OCB requires that the OCB AS receive each INVITE transmitted by a subscribing UE. The AS
determines if the destination URI provided in the INVITE is to a blocked public ID. The AS forwards the INVITE
toward its intended destination if it is not addressed to a blocked public ID. If addressed to a blocked public ID, the
OCB AS establishes an early media session with the calling UE and announces the call was blocked.
The OCB AS also supports a PIN override option, which is activated or deactivated through provisioning. If the PIN
override option is activated, the OCB AS includes an override PIN announcement in the early media session. The
caller entered override PIN is forwarded to the OCB AS per the method negotiated in the early media session SDP
offer-answer exchange. If the override PIN is authenticated, the OCB AS forwards the INVITE to the destination
Public Identity. If the PIN override authentication fails, the OCB AS announces the authentication failure and
terminates the early media session by sending a Forbidden (403) response.
If the PIN override option is not activated, the OCB AS sends a Forbidden (403) response after announcing the call
has been blocked. The Forbidden (403) response and acknowledgement ends the early media session.

An OCB subscriber can activate or deactivate call blocking or call blocking options using either of the following
methods:
• User communications with a service provider operator – This method requires subscriber communication with
the service provider. The service provider executes the subscriber's requested OCB changes. The processes for
implementing provisioning changes can be unique to each service provider.
• Web Portal Access – This is an automated method whereby the subscriber accesses a web portal to activate,
deactivate, or modify OCB subscription options. The processes for accessing the portal and implementing the
changes can be unique to each service provider.


Upon receiving an INVITE from the subscriber UE, the OCB AS MUST compare the destination URI provided in
the INVITE to provisioned digit maps that identify the blocked Public ID destinations for the subscriber. If a
destination Public ID does not match any of the provisioned OCB digit maps, the AS MUST forward the INVITE
toward its intended destination. If the destination URI matches a provisioned OCB digit map, the OCB AS MUST
execute early media as specified in Section 7.1.9. The OCB AS MUST play an early media stream announcing that
the call to the destination public identity is blocked
If the AS OCB does not support an override PIN service, it MUST end the early media session by transmitting a
Forbidden (403) Response. The session is terminated after an ACK is received from the UE.
When the AS OCB supports a PIN override service, the early media announcement MUST prompt the caller to enter
an override PIN. The UE MUST forward the caller's PIN entry per the methods established in the early media SDP
offer-answer exchange. The AS MUST compare the collected PIN to the provisioned PIN for the subscriber. If a
matching PIN is entered, the AS MUST send the INVITE toward the specified destination URI. If an incorrect PIN
is entered, the AS MUST play an announcement indicating that the entered PIN was incorrect. The AS MUST re-
attempt to collect the PIN until the correct PIN is entered or the provisioned number of attempts has been reached.
The AS MUST terminate the session by sending the originating UE a Forbidden (403) response if the provisioned
number of attempts has been reached.

Table 33 summarizes the feature data items that are defined to support implementation of OCB feature.
Table 33 - Outbound Call Blocking Feature Data

Feature Activation Status Boolean Per public user ID AS AS AS None
Caller Treatment Indicator Strings representing Per public user ID AS AS AS None
treatment options
Activation Status for OCB Boolean Per public user ID AS AS AS None
Override PIN
OCB Override PIN Digits Per public user ID AS AS AS None
Retry Attempts Integer Per network AS AS AS None

Speed Dialing and Call Forwarding
Speed Dialing and Call Forwarding are invoked prior to the OCB feature.
7.4.1.6 Call Flows

Figure 34 illustrates an example call flow where the OCB feature is subscribed to but the feature is presently
disabled. The call flow assumes the AS is capable of generating all applicable announcements and RTP streams.

PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify OCB is not

active
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 34 - Outbound Call Blocking (OCB) - Feature Function While Deactivated

Figure 35 illustrates an example call flow where the OCB feature is activated, the destination URI matches a call
block category, the originating UE subscribes to an OCB override service, and an invalid override PIN is entered.
The call flow assumes the AS is capable of generating all applicable announcements and RTP streams. The call flow
is not normative, so if there is a discrepancy between the text requirements and these call flows, then the text
requirements take precedence.
PacketCable
Phone UE AS
Network
“A” “A”
Call B
INVITE
INVITE
Verify OCB is enabled for A

and PIN service is supported
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
OCB announcement and PIN collection
Verify no correct override PIN

is entered after N attempts
PIN Override failed announcement

403 Forbidden
403 Forbidden
ACK
On-hook ACK
Figure 35 - OCB - Invalid Override PIN Entry

Figure 36 illustrates an example call flow with OCB activated, the destination URI matches a call block category,
the originating UE subscribes to an OCB override service, and a valid override PIN is entered. The call flow
assumes the AS is capable of generating all applicable announcements and RTP streams. The call flow is not
normative, so if there is a discrepancy between the text requirements and these call flows, then the text requirements
take precedence.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify OCB is active, the call is

to a blocked destination and PIN
override service is enabled
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
OCB Announcement and PIN collection
Verify valid override

PIN is entered
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 36 - OCB - Valid Override PIN Entry

Figure 37 illustrates a call flow in which the OCB feature is activated, the destination URI matches a call block
category, early media announcement is supported, and there is no override PIN subscription. The call flow assumes
the AS is capable of generating all applicable announcements and RTP streams. The call flow is not normative, so if
there is a discrepancy between the text requirements and these call flows, then the text requirements take
precedence.
PacketCable
Phone UE AS
Network
“A” “A”
Call B
INVITE
INVITE
Verify OCB is enabled for A, call

is to a blocked destination and
PIN override service is not
enabled
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
OCB announcement
403 Forbidden
403 Forbidden
ACK
On-hook ACK
Figure 37 - OCB - Override PIN Service Not Enabled
7.4.2 Collect Call Blocking

Collect Call Blocking prevents termination of a collect call to the subscriber's public identity.

A blocked caller receives treatment indicating the subscriber declines to accept the call. Collect Call Blocking is a
network based feature relying on LIDB (Line Identification Database) for feature status.

A Collect Call Blocking subscriber can activate or deactivate call blocking or call blocking options using either of
the following methods:
• User communications with a service provider operator – This method requires subscriber communication with
the service provider. The service provider executes the subscriber's requested Collect Call Blocking changes.
The processes for implementing provisioning changes can be unique to each service provider.
• Web Portal Access – This is an automated method whereby the subscriber accesses a web portal to activate,
deactivate, or modify Collect Call Blocking subscription options. The processes for accessing the portal and
implementing the changes can be unique to each service provider.


The execution of this feature depends on operator interaction with a database external to the PacketCable network.
The typical use is as follows:
• A subscriber calls an operator to place a collect call.
• The operator locates the number to call in the LIDB, to determine if the call is possible.
• If the call is possible, the operator places it; otherwise the operator informs the subscriber that the call is
blocked.
The call is essentially blocked before it reaches the PacketCable network, requiring no resources from the network.

There are no data elements requiring definition in the PacketCable network for this feature.

Collect Call Blocking occurs before the call reaches the PacketCable network; hence there are no feature
interactions.
7.4.3 Solicitor Blocking

Solicitor Blocking (SB) provides an IVR screen between incoming callers and the subscriber. Contrary to its name,
this feature can also be used to block callers other than solicitors. Under these circumstances, the feature is generally
known as privacy screening.
There are two versions of this feature. In the first version, the incoming caller is connected to an IVR system and
played a greeting asking the caller to press a key to be connected to the subscriber, thereby acknowledging the caller
is not a solicitor.
In the second version, the SB AS prompts the caller for a name (greeting) to play to the subscriber. The SB AS then
calls the subscriber, plays the greeting, and offers a menu of choices for handling the call. The subscriber then
selects or rejects the call based on an IVR menu of choices.
In both versions of the feature there is a subscriber specified caller acceptance list of numbers that the subscriber
chooses to allow without screening.
Solicitor Blocking is dependent upon the Screening List Editing (SLE) feature to maintain a Solicitor Blocking
caller list of numbers that bypasses the screening. A subscriber can initiate procedures for modifying the white list
by going off-hook, receiving the dial-tone, and dialing the Solicitor Blocking VSC. Each code provides the
subscriber with access to the same set of Solicitor Blocking capabilities.
As part of its FEATURE-CHECK and MAKE-CALL digit map actions, if the solicitor blocking feature is available,
the UE MUST send the solicitor blocking VSC in an INVITE to the SB AS, using the general form of request URI
described in Section 7.1.2.
Once the solicitor blocking VSC has been successfully entered, the SB AS MUST play announcements providing
the following information (not necessarily in this order):
• The name of the service (that is, Solicitor Blocking)
• The current size of the customer's white list
• Actions and associated dialing codes available to the user:
- Add entry(y)ies to the list
- Delete entry(y)ies from the list
- List review

7.4.3.1 Feature Description, Screening by Keypress

A call is placed to a subscriber with Solicitor Blocking. The S-CSCF directs the call to the SB AS. The SB AS
begins streaming early media, requesting the caller to enter DTMF digits to indicate the caller is not a solicitor and
to connect to the subscriber. If no keypress is detected within a given time the SB AS releases the call with a 480
final response. If the caller presses the accept key, the SB AS transfers the party to the subscriber by initiating a new
call. The subscriber's phone rings with the Caller ID info of the caller. The subscriber answers the call and is
connected to the caller.
7.4.3.2 Feature Description, Screening by Greeting Record

A call is placed to a subscriber with Solicitor Blocking. The S-CSCF directs the call to the SB AS. The SB AS
begins streaming early media, which requests that the calling party leave a greeting to play to the called party. If no
message is detected within a given time, the SB AS releases the call with a 480 final response. If the caller records a
message, the SB AS initiates a new call to the called party with the intent of playing the collected message. The
called party's phone rings with the Caller ID info of the calling party. The called party answers the call and hears the
caller's recorded greeting with a selection of options for handling the caller's call (accept, decline, transfer to VM,
etc.). The calling party is connected to the called party if the called party chooses to accept. The calling party's call is
connected to a treatment if the called party chooses to reject.
7.4.3.3 Feature Activation

The Solicitor Blocking feature is always active once assigned to the subscriber.
7.4.3.4 Feature Execution, Screening by Keypress

Upon establishing an early media session with an incoming caller not on the SB caller acceptance list provisioned by
the subscriber, the SB AS MUST prompt the caller for keypress and attempt to collect the keypress. The SB AS
MUST warn the caller if it fails to detect a keypress, make at least one other attempt to collect, and disconnect the
call if the attempt fails. The SB AS MUST allow the call to proceed to the subscriber if the caller is on the SB caller
acceptance list. The SB AS MUST forward the caller's INVITE to the subscriber's public identity if the caller
presses the accept key.
7.4.3.5 Feature Execution, Screening by Greeting Record

Upon establishing an early media session with an incoming caller not on the SB caller acceptance list provisioned by
the subscriber, the SB AS MUST prompt the caller for a greeting and attempt to record the greeting. The SB AS
MUST warn the caller if no greeting is detected, make at least one other attempt to get a recorded greeting, and
disconnect the call if that attempt fails. The SB AS MUST allow the call to proceed to the subscriber if the caller is
on the SB caller acceptance list. The SB AS MUST initiate a new call to the called party if a greeting is recorded.
The SB AS MUST play that greeting with an appropriate announcement and list of choices for handling the called
party. The SB AS MUST offer accept or decline as options for handling the calling party. The SB AS MAY offer
other choices, like a forward to busy greeting or voicemail. Upon acceptance, the SB AS MUST connect the calling
and called parties by sending an INVITE with Replaces header to the called party. The Replaces header matches the
existing dialog between the SB AS and the called party. The SB AS MUST proxy the final response from the called
party to the calling party without record routing. The SB AS MUST terminate the replaced dialog between itself
and the called party by sending a BYE to the called party. Upon declination, or upon input timeout, the SB AS
MUST play an announcement indicating that the call was declined by the called party (subscriber).


Table 34 summarizes the feature data that are defined to support implementation of the Solicitor Blocking feature.
Table 34 - Solicitor Blocking Feature Data

Requirement
Feature availability status Boolean Per public user ID Config.Server Config.Server UE Mandatory
IVR greeting for collecting caller URI for media Per public user ID AS AS AS None
information server
Acceptance key Key number Per public user ID AS AS AS None
Solicitor treatment URI for media Per public user ID AS AS AS None
server
Busy treatment URI for media Per public user ID AS AS AS None
server
Voice mail address SIP URL Per public user ID AS AS AS None
SBC Caller Acceptance List List of public Per public user ID AS AS AS None
identities

Solicitor Blocking feature interaction is as follows.
Basic Call
Both versions of Solicitor Blocking take precedence over basic calling functionality for call termination.
Incoming calls are rejected with busy treatment while this feature is executing.
Call Forwarding Variable
Call Forwarding Variable takes precedence over both versions of Solicitor Blocking.
Call Forwarding Don't Answer
Both versions of Solicitor Blocking take precedence over CFDA.
CFDA does not execute if the called party fails to answer.
Anonymous Call Rejection
ACR takes precedence over Solicitor Blocking (screening by keypress version) while ACR is active.
Solicitor Blocking (screening by greeting record version) takes precedence over ACR while ACR is active.
Call Waiting
Both versions of Solicitor Blocking take precedence over Call Waiting.
Incoming calls are blocked while the Solicitor Blocking feature executes; therefore, Call Waiting does not execute
while the Solicitor Blocking is executing.
Do Not Disturb
Do Not disturb takes precedence over both versions of Solicitor Blocking.
7.4.3.8 Call Flows

There are three relevant call flows for Solicitor Blocking: the caller is accepted by the callee, the caller is rejected by
the callee, and the caller fails to enter a greeting to play to the callee.

Figure 38 illustrates a call flow in which the caller is accepted by the callee.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Collect Greeting
INVITE from AS
INVITE from AS
Power
Ringing
180 Ringing
200 OK
200 OK
ACK
ACK
Play Greeting and
collect DTMF response
INVITE from A
Replaces: AS
INVITE from A
Replaces: AS
200 OK
200 OK
200 OK
200 OK
BYE
BYE
200 OK BYE
200 OK BYE
ACK
ACK
A-B Connected
Figure 38 - Solicitor Blocking (SB) - Called Party Accepts the Caller

Figure 39 illustrates a call flow in which the callee rejects the caller or fails to respond to the greeting.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Collect Greeting
INVITE from AS
INVITE from AS
Power
Ringing
180 Ringing
200 OK
200 OK
ACK
ACK
Play Greeting and
collect DTMF response
BYE
BYE
200 OK BYE
200 OK BYE
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
A connected to treatment
480 Unavailable
480 Unavailable
ACK
On-hook ACK
Figure 39 - SB - Called Party Rejects the Caller or Fails to Respond to the IVR

Figure 40 illustrates a call flow in which the caller fails to enter a greeting.
PacketCable
Phone UE AS
Network
“A” “A”
Call B
INVITE
INVITE
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Collect Greeting
480 Unavailable
480 Unavailable
ACK
On-hook ACK
Figure 40 - SB - Calling Party Fails to Enter a Greeting
7.5 Multi-Party Features

7.5.1 Hook Flash Processing
The services defined within Section 7.5 all make use of user interaction via hook flash to trigger service logic. A
user performs a hook flash by quickly depressing the button or "hook" that a traditional telephone handset rests upon
when not in use, and then letting the hook rise again. The following sub-sections define the required behavior of the
UE when processing the hook flash action.
The following requirements define the handling of an initial hook flash. When multiple hook flashes are handled
through the invocation of a service, the behavior for each subsequent hook flash is defined within the service
specific section.
• On detection of a hook flash before an active call exists (e.g., the other party is still ringing), the UE MUST
ignore the hook flash. On detection of a hook flash during an answered call, the UE checks the availability
status of the features that involve hook flash (Call Waiting, Call Hold, Call Transfer, and Three-Way Calling).
If none of these features is available, the UE MUST ignore the hook flash.
• If at least one of these features is available and an active call exists, the UE MUST hold the active media
stream, as defined in Section 7.1.5, and then continue with the processing described in the following bullets.
• If there is only a single dialog at the UE, then the UE MUST provide a recall dial tone and begin digit
collection.
• If the service logic requires digit collection and the long inter-digit timer expires during the digit collection, the
action specified by the digit map is taken. If the user flashes during the digit map action, then the UE MUST
retrieve the media as defined in Section 7.1.5.
• If the service logic requires digit collection and the start timer expires, the action specified by the digit map is
taken. If the user flashes during the digit map action, then the UE MUST retrieve the media as defined in
Section 7.1.5.

• If the subscriber flashes subsequent to an initial hook flash and prior to the completion of digit collection, the
UE MUST abandon the second call leg attempt and retrieve the initial call leg media as defined in Section 7.1.5.
• If the subscriber hangs up when only one media stream exists, and that media is held as a result of a hook flash,
then the UE MUST NOT send a BYE to the network. Instead, the UE MUST apply power ringing. If the
subscriber goes off-hook before expiration of the No Answer timer, the held media stream is retrieved as
defined in Section 7.1.5. Otherwise, on expiration of the No Answer timer, the UE MUST release the call by
sending a BYE.
7.5.2 Call Waiting

The Call Waiting (CW) feature provides the subscriber with the ability to detect an incoming call while in an
existing call, and to answer that call by flashing, putting the existing call on hold. The behavior is described by
Telcordia [GR 571] and [GR 572], unless otherwise specified here. There are two parts to this feature:
activation/deactivation (disabling and enabling on a per call basis), and execution.

Service disabling and enabling occur when the subscriber calls a toggling vertical service code (for example, *70).
The subscriber hears a tone indicating the state of the service (enabled or disabled) or a treatment if the service is not
available for control (not assigned). Service control should be allowed any time the subscriber is allowed to place a
call. Service control only applies to an existing call or to a new call (that is, from the time the caller initiates the
control action until the time the caller hangs up).

To enable and disable call waiting, the subscriber dials the VSC as normal call origination or after the flash in a
second call. The UE recognizes the Call Waiting activation code as defined by its digit map and transformation table
and invokes the CW-TOGGLE digit map procedure.
As part of its CW-TOGGLE digit map procedure, the UE MUST check the value of the Per-Call CW status in the
UE. If the CW feature is active for the subscriber and if the Per-Call CW status is enabled, the UE MUST set the
status to disabled in its CW-TOGGLE digit map procedure. If the Per-Call CW status is disabled, the UE MUST set
the status to enabled in its CW-TOGGLE digit map procedure. When the user goes on-hook, the UE MUST reset
the Per-Call CW status to enabled.
When the subscriber goes off hook and dials the CW VSC before originating a call, the UE MUST play a
confirmation tone upon successful execution, play a recall dialtone, and begin to collect digits for call origination
according to the default digit map, in its CW-TOGGLE digit map procedure. The UE MUST play a reorder tone if
the feature is inactive for the subscriber, or upon failure, in its CW-TOGGLE digit map procedure.
When the subscriber dials the CW VSC after performing hook flash during an established call without a waiting call,
the UE MUST play a confirmation tone upon successful execution, and resume the held call in its CW-TOGGLE
digit map procedure. The UE MUST play a short error tone and resume the held call if the feature is inactive for the
subscriber, or upon failure, in its CW-TOGGLE digit map procedure.
If the CW is the only available feature that involves the hook flash and the subscriber performs hook flash during an
established call without a waiting call, the UE checks the value of the Enable Cancel CW During Call feature data in
Table 35. If the value of this feature data is false and the current Per-Call CW status is enabled, the UE MUST
ignore the hook flash. In any other cases, if the subscriber dials any digit string other than the CW VSC after
performing the hook flash, the UE MUST play a short error tone and resume the held call.

Service execution consists of call termination (similar to basic call termination) while the UE is in an established
call. The UE MUST reject the incoming INVITE with a 486 Busy Here final response if the UE is already engaged
in an active call that cannot be held due to any of the following resource or service precedence restrictions:
• There is already a call on hold.
• The current call is an emergency call.

• The current call is a three-way call.

If there is an active call that can be held when another INVITE is received by the UE, the UE MUST play a call-
waiting tone in the handset unless resource reservation is in progress at either the originating or terminating UE. If
the UE is configured to require that network resources are reserved before continuing with the session
([PKT 24.229]), and this reservation is not complete, then the Called UE MUST NOT play call-waiting tone until it
has received an updated SDP from the calling party showing that the remote resources are now reserved. The tone
SHOULD match the agreed cadence for the alert-info header if such a header is present in the INVITE of the
incoming call. Otherwise, the tone MUST be as specified in [GR 571]. The terminating UE MUST play the tone so
that only the terminating subscriber hears the call waiting tone.
If the UE detects a flash, it MUST initiate a hold operation on the existing call's session, as defined in Section 7.1.5.
The UE MUST accept the new call from the network once the re-INVITE for the old call completes, and stop
playing the call waiting tone to the handset. The UE MUST reject the incoming call with a 486 Busy Here final
response if the hold attempt of the existing active call fails.
If the UE detects a disconnect, it MUST release the existing call by sending a BYE to the network. The UE
SHOULD proceed with normal SIP signaling for call termination on the waiting call. The UE MUST play ringtone,
and the ringtone MUST match the agreed cadence for the alert-info header if such a header is present in the INVITE
of the incoming call.
If the UE does not detect a flash or disconnect, it MUST stop playing the call waiting tone after applying the second
tone to the handset for the duration and repetition interval, as defined in [GR 571].
Once CW tone has been applied to the called line, if that line disconnects, the UE MUST re-ring the line and if
answered, set up a talking connection to the party whose call caused the CW tone to be applied.
Consider the scenario where a subscriber with Call Waiting (A) has a held party (B), and is talking with a third party
(C). If the party C now hangs up, the following requirements apply. The UE behavior for the controller party A is
dependent on the value of the feature data element "Call Waiting Disconnect Timing" defined in Table 35. If the
Call Waiting Disconnect Timing is set to 0, the controller UE MUST immediately resume the connection with the
held party. If the Call Waiting Disconnect Timing is set to a non-zero value, the controller UE MUST wait for this
duration before automatically resuming the connection with the held party. If the controller UE detects a hook flash
in the Call Waiting Disconnect Timing duration, then the UE MUST immediately resume the connection with the
held party.

Table 35 summarizes the feature data defined to support implementation of call waiting.
Table 35 - Call Waiting Feature Data

by Requirement
Feature Availability Status Boolean Per public user ID Config.Server Config.Server UE Mandatory
Feature Activation status Boolean Per public user ID UE UE UE None
Enable Cancel CW During Call Boolean Per public user ID Config.Server Config.Server UE Mandatory
Call Waiting Disconnect Timing Integer Per public user ID Config.Server Config.Server UE Mandatory
(seconds)
Default:10

The call waiting feature has the following interactions.
Basic Call
The UE MUST respond with a 486 Busy Here final response when a new INVITE is received and the UE is off
hook but is not yet in a stable two-way call (for example, while dialing). Further, the UE MUST respond with a 486

Busy Here final response when a new INVITE is received and when the UE is on hook but has not yet sent a BYE
(see on-hook processing, Section 7.1.4.3).
Distinctive Alerting
Distinctive Alerting may be applied for a call in wait, as per Section 7.6.3.
DND, network
The interaction is consistent with basic call termination.
Call Forwarding
Selective Call Forwarding and Call Forwarding Variable take precedence over Call Waiting.
Call Hold
Call hold takes precedence over call waiting.
Call Transfer
The precedence of call waiting with call transfer depends on the state of the transfer attempt.
When the subscriber executes a hook flash while a call is waiting, the UE MUST answer the waiting call instead of
performing a call transfer.
Call waiting is disabled after initiating call transfer via flash. The UE MUST reject an incoming call with a 486
Busy Here final response while the call transfer feature executes.
Three-way Call
Call waiting takes precedence over a three-way call when the three-way call is not executing. Call waiting is
disabled after initiation of a three-way call.
Emergency Call Origination
The UE SHOULD not execute the Call waiting feature when the existing call is an emergency call.
Solicitor Blocking
Solicitor Blocking takes precedence over Call Waiting. Since Solicitor Blocking is performed by an AS, and Call
Waiting is performed by the destination UE, Solicitor Blocking always takes precedence over Call Waiting, because
the AS receives the call before offering the call to the UE.

7.5.2.6 Call Flows

Figure 41 illustrates answering a waiting call with the call waiting feature. The UE receives an INVITE for a new
call from the network. The UE sends a provisional response while proceeding to hold the existing call via re-
INVITE. The UE then accepts the new call after holding the existing call.
PacketCable
Phone UE Network UE Phone UE Phone
“A” “A” "B" “B” "C" “C”
Active Call
Call A
INVITE
INVITE
Call Wait
Tone
180 Ringing
Flash 180 Ringing
INVITE Ringback
SDP: a=inactive Tone
INVITE
SDP: a=inactive
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Held Media
200 OK
200 OK
ACK
ACK
A-C Connected
Figure 41 - Call Waiting (CWT) - Answering a Second Call
7.5.3 Hold

The Call Hold (CHD) feature allows a user to put an active call on hold with a VSC for an extended period, while
not sending or receiving any media to or from the held party, and then to retrieve the call at a later time. During the
time that a call is on hold, the UE can place another call. If the user places another call while having a call on hold,
the user is able to alternate the active call and the call on-hold using the same vertical service code.
A UE that supports the CHD feature MUST comply with the CHD requirements in [GR 579].
There are two types of CHD: silent on-hold and music on-hold. Silent on-hold is specified in the following sub-
sections. Music on-hold is out of the scope of this specification. In the following sub-sections, CHD is assumed to
mean silent on-hold.


To activate the CHD feature, the user presses hook flash, hears a recall dial tone, then dials the CHD vertical service
code. The UE recognizes the CHD vertical service code as defined by its digit map and transformation Table and
invokes the HOLD-ACTIVATE digit map procedure.
As part of the HOLD-ACTIVATE digit map procedure, if the feature availability status indicates that Call Hold
feature is not available, then the UE MUST play a denial announcement or tone to the user. Otherwise, the HOLD-
ACTIVATE digit map procedure checks the value of the HOLD-ACTIVATE state in the UE. The state has two
values: Active, indicating a call is on hold and Inactive, indicating no call is on hold.
Given the HOLD-ACTIVATE state of Inactive, the UE MUST play the recall dialtone, and begin collecting digits
according to the default digit map, in its HOLD-ACTIVATE procedure.
Given the HOLD-ACTIVATE state of Active, the UE MUST retrieve the held call, as described in Section 7.5.3.3,
in its HOLD-ACTIVATE procedure.

The UE MUST hold the media (see Section 7.1.5). The UE MAY play comfort noise or silence insertion packets to
and from the user while the media is being held.
When the CHD vertical service code is dialed after the UE receives a hookswitch flash, then the UE MUST apply
the recall dial tone to allow the user to place another call.
If digits are not dialed or partially dialed, the UE MUST apply the Extended Off Hook Processing procedures
specified in Section 7.1.4.4 for Origination Mode. If the user flashes and enters the CHD vertical service code, then
the UE MUST take the held call off hold as defined within Section 7.1.5.
If the new call attempt fails after dialing at least one digit and before the new call attempt becomes a stable call, the
UE MUST play an error announcement to the user as specified by the digit map action or the Announcements
Section 7.1.6 If the user executes a flash hook, the UE MUST retrieve the held call without requiring that the
vertical service code be dialed. This is the only situation in which the user can retrieve the held call without dialing
the vertical service code.
If the UE receives a BYE on the held call's dialog while the user is making another call attempt, the UE MUST
terminate the held call by sending a 200 OK for the BYE. The UE MUST then allow the second call attempt to
continue.
Once the new call attempt is successful, the UE MUST allow the user to alternate the active and held calls by hook
flashing, receiving a recall dial tone, and entering the vertical service code. A held call is retrieved as defined within
Section 7.1.5.
If the UE detects on-hook while a call is on-hold, the UE MUST terminate the active call. The UE MUST apply
ringing to alert the user that there is a held call. If the user doesn't answer after the No Answer timer expires, the
user's UE MUST send a BYE to end the session. When the held party's UE receives a BYE while on hold, the held
party's UE MUST play the reorder tone to the local user.
On reception of a BYE from the non-held, non-controlling UE, the controller's UE MUST play the recall dial tone
and begin digit collection.
The UE MUST set its HOLD-ACTIVATE state to inactive once the held call is retrieved or disconnected. The UE
MUST set its HOLD-ACTIVATE state to active once a call is successfully held.
At any given time, the UE MUST NOT allow more than one call to be held via the CHD mechanism described in
Section 7.5.3.2.


Table 36 summarizes the feature data that are defined to support implementation of Call Hold.
Table 36 - Call Hold Feature Data

Requirement
Feature Activation / Deactivation Tone or Per public user ID Config.Server Config.Server UE Mandatory
Confirmation Indicator announcement
7.5.3.5 Feature Interaction

Basic Call
The UE MUST be able to initiate an outgoing call while having a call on hold.
If the UE already has a call on hold when it receives a new INVITE, it MUST reject the incoming call with a 486
Busy Here response.
Transfer Call
The UE MUST be able to transfer the non-held call without impacting the held call.
The UE MUST NOT be able to transfer the held party and the non-held party to each other in either direction.
Conference Call
The UE MUST NOT permit a conference call between the non-held and held calls.
The UE MUST permit conference calls between non-held parties.
Call Waiting
If the UE has a held call and an active call at the same time, it MUST NOT provide call waiting, because hook flash
is used to retrieve the held call.
Emergency Calling
A UE MUST NOT place emergency calls on hold.

7.5.3.6 Call Flows

The upper half of the call flow in Figure 42 is for UE A to put a party (UE B) on hold. The bottom half of the call
flow is for UE A to retrieve the held party (UE B).
PacketCable
“A” “A” "B" “B”
Active Call
Flash
Recall Dial
Tone
VSC
INVITE
SDP: a=inactive
INVITE
SDP: a=inactive
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Held Media
Flash
Recall Dial
Tone
VSC
INVITE
SDP: a=sendrecv
INVITE
SDP: a=sendrecv
200 OK
SDP: a=sendrecv
200 OK
SDP: a=sendrecv
ACK
ACK
Active Call
Figure 42 - Network Hold - Hold and Retrieve

Figure 43 illustrates network hold, in which the second call attempt fails.
PacketCable
“A” “A” "B" “B”
Held Media
Call C
Call attempt fails

prior to ring
Flash
INVITE
SDP: a=sendrecv
INVITE
SDP: a=sendrecv
200 OK
SDP: a=sendrecv
200 OK
SDP: a=sendrecv
ACK
ACK
Active Call
Figure 43 - Network Hold - Second Call Attempt Failed
Figure 44 illustrates a network hold scenario in which the controller goes on-hook.
PacketCable
“A” “A” "B" “B”
Held Media
On-hook
Power
Ringing
No answer timer
expires
BYE
BYE
Reorder
Tone
200 OK BYE
200 OK BYE On-hook
Figure 44 - Network Hold - Controller Goes On-Hook

7.5.4 Call Transfer

This section specifies the transfer of one caller (the transferee) to another party (the transfer-to party), in which the
transfer is initiated by the originator of the second call (the transferor). As described in the [GR 579], there are two
common varieties of call transfer - consultative and blind. Consultative transfer is specified by [GR 579]. Blind
transfer is not explicitly specified by Telcordia as it is with numerous implementations in Centrex systems, which
have the benefit of additional inputs (such as transfer buttons) or vertical service codes for feature control. This
specification defines blind transfer in terms of the state of the second call: if the call is unanswered before
completion of the transfer sequence, the transfer is considered blind.
7.5.4.1 Feature Activation

Call Transfer (CT) is always active once assigned to the subscriber. Once the service is assigned, a UE MUST
include an Allow header containing REFER in every request in which an Allow header is allowed, according to
[RFC 3261].

7.5.4.2 Feature Execution Overview, Preconditions

It should be noted that the UE only begins transfer execution if there is one active call and there is no other call
present or pending (waiting), as specified in the Feature Interactions sections for Call Waiting and Call Transfer
(Section 7.5.2.5 and Section 7.5.4.8 respectively). In addition, with the Transfer Incoming Call Only in Table 37
being set to 'true', the UE only performs the transfer if the target active call is an incoming one. Figure 45 describes
execution of this feature.
B picks up
Start Hold A
B’s phone
(Call A-B B flashes Play dial tone B hangs up
rings
established) Collect digits
B flashes B dials C
Call to C
begins (digits
B flashes
sent to
network)
B flashes
B waits B hangs up
B hears
A, B hear
ringback from
ringback from B flashes B hangs up
C, C’s phone
C
rings
C picks up
B hangs up A-B
B-C established
connected (service
complete)
B flashes
C hangs up
or B flashes
A-B-C
C picks up
connected
A hangs up
B hangs up
A hangs up
B hears B-C
A transferred
ringback from established
C picks up to C, Call A-B
C (service (service
terminated
complete) complete)
B hangs up
Figure 45 - Call Transfer (CXR) Feature Flow, B Transfers A to C, Not All User Inputs Are Shown for A
The method for invoking call transfer depends on the value of the feature data element "In Dialog REFER" defined
in Table 37.
If the feature data element "In Dialog REFER" is set to "true", the transferor UE MUST initiate call transfer via a
REFER sent within the existing dialog with the transferee, as described in [RFC 3515].
If the feature data element "In Dialog REFER" is set to "false", the transferor UE MUST initiate call transfer via a
REFER sent out of dialog, as described in [RFC 3515], to the transferee.

The UE MUST include a Refer-to header in the REFER to indicate the call legs being connected. The transferor's
UE MUST include a nested Replaces header in the Refer-to header to direct the transferee to the transfer-to party.
The transferor's UE MUST set the Refer-to header to contain a nested Replaces header (as defined by [RFC 3891])
identifying the dialog to replace. The transferor's UE MUST include the Target-Dialog header [RFC 4538] which
describes the existing dialog between the transferor and the transferee. If the transferee does not support the Target-
Dialog header (indicated by the tdialog options tag), the transferor MUST NOT send the REFER to the transferee to
initiate transfer.
In order to preserve the privacy of the parties involved and deter fraudulent use of this feature, the transferor's S-
CSCF should be provisioned by the service provider with an initial filter criterion that sends the REFER to an AS
(the CT AS).
The CT AS receiving the REFER MUST cache the contents of the Refer-to and replace the contents of the Refer-to
with its private URI. The CT AS MUST proxy the REFER to the intended target.
Upon receiving the subsequent INVITE from the transferee, the CT AS MUST verify the originator matches the
destination of a previously proxied REFER, replace the contents of the request URI with the cached Refer-to, add
the Replaces header from the cached Refer-to, and proxy the INVITE accordingly.
The UE receiving the REFER proxied by the CT AS MUST support the Refer-to header, and send subsequent
NOTIFYs to the transferor to indicate transfer status. The MGC requirements for support of REFER method and
Refer-to header for Call Transfer are specified in [CMSS1.5]. An MGC receiving the REFER proxied by the CT AS
supports the Refer-to header. The MGC sends subsequent NOTIFYs to the transferor to indicate transfer status.
7.5.4.3 Feature Execution, Transferor

If the Transfer Incoming Call Only in Table 37 is set to 'true' and the target active call is not an incoming one, the
transferor UE MUST NOT perform the transfer procedure described below. In this case, the UE follows the
applicable hookflash-processing requirements specified for other features (e.g., Three-Way Conference in Section
7.5.5).
If the call transfer feature is enabled for the UE by the Configuration Server via the Feature Availability Status
defined in Table 37, the UE MUST send a re-INVITE to hold the remote party upon detection of a hookflash. The
UE MUST then play dial-tone and collect digits for second call origination. The UE MUST abandon the second call
attempt if the subscriber flashes and return to the first call if digit collection is not completed successfully.
Upon detection of a valid digit string, the UE MUST initiate the second call via an INVITE. The UE MUST apply
all features to the second call as with normal call origination.
If the subscriber flashes after the second call initiation, the transferor's UE MUST perform the following procedure:
• Retrieve the held call with the transferee;
• Mix the received RTP media of the transfer-to party (including any available early-media ringback signal from
the transfer-to party) with the sent media of the transferor; and
• Play back to the transferee the mixed media (the calls are conferenced locally on the transferor).
During the above procedure, if there is no early-media ringback signal (and thus the tone is generated locally by the
transferor), the transferor's UE MUST mix the locally generated ringback signal with its sent media and play the
mixed media to the transferee.
When the subscriber hangs up, the transferor's UE MUST send a REFER to the transferee on a new dialog, having a
Refer-To header containing a nested Replaces header with the transfer-to the party's SIP dialog information and a
Target-dialog header matching the transferee's existing SIP dialog with the transferor. The transferor's S-CSCF is
assumed to be provisioned with an initial filter criterion to send the REFER to the CT AS.
Upon receiving the 202 Accepted response for its REFER request, the transferor's UE MUST stop sending any on-
going ringback signal to the transferee.
The transferor's UE SHOULD wait for NOTIFY message(s) from the final recipient of the REFER indicating the
transfer result.

If the transferor hangs up before the transfer-to party picks up, the transferor's UE MUST send CANCEL to the
transfer-to party and BYE to the transferee upon one of the following conditions:
• Receipt of a NOTIFY message from the final recipient of the REFER indicating successful initiation of the
transfer.
• Expiration of the Notify-timeout before receiving a NOTIFY from the final recipient of the REFER.
If the transferor hangs up after the transfer-to party has picked up, the transferor's UE MUST send BYE to the
transferee and the transfer-to party upon one of the following conditions:
• Receiving a NOTIFY message from the final recipient of the REFER indicating successful initiation of the
transfer.
• Expiration of the Notify-timeout before receiving a NOTIFY from the final recipient of the REFER.
7.5.4.4 Feature Execution, CT AS

When the CT AS receives a REFER from the transferor, the CT AS MUST:
• Validate the subscriber's ability to transfer, and reject if invalid.
• Replace the Refer-to header content with its private URL.
• Proxy the REFER to the destination indicated in the request URI.
• Add its record route entry to the REFER before proxying in order to receive subsequent NOTIFY messages
from the recipient of the REFER.
• Proxy NOTIFY messages to the S-CSCF.
When the CT AS receives an INVITE that matches a previously proxied REFER, the CT AS MUST:
• Replace the request URI in the INVITE with the original Refer-to contents, inserting the embedded Replaces
header as a discrete header within the INVITE.
• Proxy the INVITE.
When the CT AS receives an INVITE that does not match a previously proxied REFER, the CT AS processes it as
per standard SIP procedures.
The process by which the CT AS matches an INVITE to a previously proxied REFER is not specified here. A
possible method that the CT AS could use is to match information it includes in the proxied REFER in the Refer-To
URI to the request URI returned by the UE in the corresponding INVITE.
7.5.4.5 Feature Execution, Transferee

When the transferee's UE receives an out-of-dialog REFER, it MUST:
• Match the Target-dialog in the REFER with an existing dialog for transfer.
• Reject the REFER with a 481 Call/Transaction Does Not Exist final response if no match is found between the
Target-dialog header and an existing dialog.
• Send an INVITE using the Refer-To header in the REFER for the request URI.
• Notify the transferor of call status with a NOTIFY.
7.5.4.6 Feature Execution, Transfer-to party

When the transfer-to party's UE receives an out-of-dialog INVITE, it MUST:
• Match the content of the Replaces header in the out-of-dialog INVITE to the existing dialog with the transferor.
NOTE: Use of the replaces header on an early dialog between the transfer-to and transferee in the case of blind
transfer diverges from the use specified in [RFC 3891].

• Reject the INVITE with a 481 Call/Transaction Does Not Exist final response if the Replaces header does not
match the existing dialog with the transferor.

Table 37 summarizes the feature data items that are defined for the implementation of Call Transfer.
Table 37 - Call Transfer Feature Data

by Requirement
Feature Availability Boolean Per public user ID Config.Server Config.Server UE Mandatory
Status
Notify-timeout Integer (seconds) Per public user ID Config.Server Config.Server UE Mandatory
In-dialog REFER Boolean Per public user ID Config.Server Config.Server UE Mandatory
Default: false
Transfer Incoming Boolean Per public user ID Config.Server Config.Server UE Mandatory
Call Only (Default: ‘false’)

Basic Call
The transferor's UE MUST use the same data as basic call (see Section 7.1) for the second call origination.
Call Waiting
If the subscriber's UE is engaged in an active call, a new INVITE is received at the subscriber's UE, and the
subscriber has the Call Waiting feature, then, for as long as the UE is engaged in two dialogs, the subscriber's UE
MUST NOT invoke the Call Transfer feature when the subscriber hook flashes. If the subscriber's UE receives a
new INVITE at any point after the subscriber has hook flashed to initiate a transfer, and the subscriber has the Call
Waiting feature, then the subscriber's UE MUST respond to the new INVITE with a 486 Busy Here response.
Three-Way Calling
Call Transfer takes precedence over three-way calling.
Call Blocking, Outbound (In General)
If the subscriber invokes the CT feature and receives recall dial tone and dials a blocked phone number in response
to the recall dial tone, the OCB AS MUST block the call according to the procedures in Section 7.4.1. This assumes
that the S-CSCF is correctly provisioned with initial filter criteria to trigger the INVITE to the OCB AS prior to
triggering the call to the CT AS.
Emergency Calling
When the subscriber's UE is engaged in an active Emergency Call and the subscriber performs a hook flash, the
subscriber's UE MUST NOT play the recall dial tone to the user as described in this CT section, but continues with
the Emergency Call instead.
Caller ID Blocking
When sending a REFER, if caller-ID blocking is enabled for the transferor's public identity, the transferor's UE
MUST include an anonymized Referred-By header or no Referred-By header as defined in [RFC 3892].
7.5.4.9 Call Flows

There are two relevant call flows for call transfer. The subscriber originates the second call, waits for ringback, and
then hangs up, as shown in Figure 46.

PacketCable
Network
“A” “A” "B" “B” "C" “C”
Active Call
Flash
INVITE
SDP:a=inactive
INVITE
SDP:a=inactive
200 OK
200 OK
Recall Dial
Tone
ACK
ACK
Held Media
Call C
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
Ringback
Tone
On-hook
REFER
Refer-To:C; Replaces:B
REFER
Refer-To:C
Replaces:B
REFER
Refer-To:AS
REFER
Refer-To:AS
202 Accepted
REFER
202 Accepted
REFER
202 Accepted
REFER
202 Accepted REFER
INVITE AS
INVITE AS
INVITE C
Replaces:B
INVITE C Replaces:B
180 Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
Tone
NOTIFY REFER
NOTIFY
REFER
NOTIFY
REFER
NOTIFY REFER
200 OK NOTIFY
200 OK
NOTIFY
200 OK
NOTIFY
200 OK NOTIFY
ACK
ACK
BYE
BYE
200 OK BYE
200 OK BYE
Offhook
200 OK
200 OK
200 OK
200 OK
ACK
ACK
A-C Connected
Figure 46 - CXR - B Transfers A to C (blind) Using REFER after Initial INVITE but Before C Answers

The subscriber originates the second call, waits for an answer, and then hangs up, as shown in Figure 47.
Figure 47 - CXR - B Transfers A to C (Consultative) Using REFER after Establishing the Call to C with INVITE
7.5.5 Three-Way Calling

Three-Way Calling (3WC) allows a subscriber to add a third party to an existing two-party active call without
operator assistance. The subscriber initiating the 3WC is called the controller. A UE with an analog user interface
for 3WC MUST comply with [GR 577].


3WC feature availability is provisioned via the Configuration Server. UEs not initiating a 3WC do not need to be
provisioned with the 3WC feature in order to participate in a 3WC.
While a subscriber is in an active two-way call, the subscriber activates the 3WC feature by hook switch flash, then
dials the destination address. After the destination is ringing or answered, the subscriber can hook flash again to join
the held with the third party forming a 3WC. The controller can hook flash again to disconnect the third party from
the 3WC. The controller and the remaining party form a Two-Way Call. If the controller hook flashes again, the UE
is treated as if it is initiating another 3WC.
To deactivate the feature, the controller either hook flashes to disconnect the third party or hangs up while a 3WC is
active.

By definition, before a UE can start a three-way call, the UE is assumed to be involved in a stable call. It does not
matter which party originated the call.
Upon detection of a hook flash, the controlling UE MUST place the first call on hold (see Section 7.1.5). Once the
first call is on hold, the UE MUST apply the provisioned recall dial tone and be prepared to collect digits for a
second call leg.
After receiving a recall dial tone, the subscriber dials the address of the third party. The UE MUST initiate a call on
receiving a valid dialed digit string. If the second call attempt fails, the held call can be retrieved by the controlling
UE via a subsequent hook flash.
If the held call is disconnected while the controller is making the second call attempt, the held call MUST be
terminated. After the held call is terminated the second call attempt MUST continue as a two-party call.
If the second call attempt succeeds, the controller may speak to the third party privately. While the first call is on
hold, if the UE receives a 4xx, 5xx, 6xx, or BYE for the call leg to the third party, then the UE MUST provide the
appropriate treatment for the received response or message (e.g., busy for 486, silence for a BYE, etc.) and start a
timer for the duration specified in the feature data element 3WC Disconnect Timing. If this timer expires before the
held party disconnects, the user hangs up, or the user flashes, the UE MUST re-establish the original 2-way
connection, between the controller and the held party.
Otherwise, the controller can join the two call legs together after the ringing is applied and before the third party
answers the call. The subscriber hook flashes again to join the held call with the second call leg to form a Three-
Way Call (3WC). Before the second call is answered, the controller's UE MUST play a ringback signal (same as
what is played to its own subscriber) to the participant of the first call. If a UE has a held call and an active call and
detects a hook flash, the UE MUST create a conference by mixing the audio received on the two call legs with the
audio received from the local party, and send the mixed audio in the RTP streams sent to the two call legs.
If the controlling UE detects a hook flash during a 3WC, the UE MUST send a BYE to disconnect the third party
from the call. After the third party is disconnected, the controlling UE MUST cease mixing the audio and continue a
two-way call with the remaining party.
If the controller's UE detects on-hook while having a call on-hold, before the third party answers, the controller's UE
MUST terminate the call with the third party by sending a CANCEL. If the controller's UE detects on-hook while
having a call on-hold, after the third party answers, the controller's UE MUST terminate the call with the third party
by sending a BYE. In either case, after the controller's UE detects on-hook, the UE MUST apply ringing to alert the
controller. If the UE does not detect off-hook prior to the expiration of the No Answer timer, the UE MUST send a
BYE to the second party to end the session.
If either the second or third party disconnects after a 3WC is established, the remaining call party's UE MUST
continue in a two-way call.
If the controller hangs up the phone in an active 3WC, the controller's UE MUST send BYE to the second and third
parties to terminate each of these call legs, except for the feature interactions between 3WC and Call Transfer

The second or third party in a 3WC can hook flash to put the 3WC on hold and make another call, subject to the
features to which they are subscribed. The remaining parties' UEs in the 3WC MUST continue the two-way media
stream without being impacted.

Table 38 summarizes the feature data defined to support implementation of the three way calling feature.
Table 38 - 3WC Feature Data

Requirement
3WC Disconnect Timing Integer Per public user ID Config.Server Config.Server UE Mandatory
(seconds)
Default:10

Basic Call
Once a controller's UE is in a 3WC and detects a hook flash, it MUST NOT give the user the ability to initiate
another basic call.
A non-controller's UE has no knowledge that he or she is in a 3WC, so the non-controller UE MAY put the 3WC on
hold if it detects a hook flash, and allow the user to make a new outgoing call.
Call Waiting
Call waiting takes precedence over a three-way call when the three-way call is not executing. Call waiting is
disabled after initiation of a three-way call.
Call Transfer
When a controlling UE is in a 3WC, it MUST NOT perform Call Transfer by a hook flash, as this disconnects the
third party in the 3WC.
A controlling UE of a 3WC that has the Call Transfer feature enabled MUST transfer when it detects on-hook.
A non-controlling UE has no knowledge that it is in a 3WC, so it can perform a call transfer.
Call Hold
Call hold takes precedence over three-way call.
Operator Service
When a controlling UE is in a 3WC, and a Busy Line Verify is received, the controlling UE MAY reject the INVITE
if resources are not available to join the operator in the 3WC.
Emergency Call
A UE MUST NOT place an emergency call on hold when it detects a hook flash. When a party is in a two-party
call, and the 3WC feature is enabled, the UE puts the first party on hold when it detects a hook flash and then it
begins digit collection. The UE establishes a session with the PSAP if an emergency call number is dialed. After the
emergency call is answered, the UE MAY join the emergency operator and the held party to form a 3WC if it
detects a hook flash. If the UE detects on hook before the emergency call is answered, the UE MUST send a
CANCEL to the PSAP to release the session when the Call Transfer feature is not active, or transfer the call when
the Call Transfer feature is active. Once the 3WC is established, the UE MUST ignore any detected hook flashes.
While in a 3WC with an emergency operator, the UE MUST adhere to the emergency call procedures defined in
Section 8.

7.5.5.6 Call Flows

Figure 48 shows the call flows for three parties to establish a 3WC.
PacketCable
“A” “A” "B" “B” "C" “C”
Active Call
Flash
INVITE
SDP:a=inactive
INVITE
SDP:a=inactive
200 OK
200 OK
Recall Dial
Tone
ACK
ACK
Held Media
Call C
INVITE
INVITE
Power
Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
ACK
ACK
A-C Connected
Flash
INVITE
SDP:a=sendrecv
INVITE
SDP:a=sendrecv
200 OK
200 OK
ACK
ACK
A-B-C Connected
Figure 48 - Three-Way Call (3WC)

After the second call leg is successfully made, if the controller hangs up before joining the held call, the active call
with the third party is terminated. The controller receives a ringing alert. If the controller goes off-hook again before
the No Answer timer expires, the controller receives a dial tone. The controller can hook flash to retrieve the held
call, or the controller can dial digits again to make another second call attempt to make another 3WC. This is shown
in Figure 49.

PacketCable
“A” “A” "B" “B” "C" “C”
Active Call
Flash
INVITE
SDP:a=inactive
INVITE
SDP:a=inactive
200 OK
200 OK
Recall Dial
Tone
ACK
ACK
Held Media
Call C
INVITE
INVITE
Power
Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
ACK
ACK
A-C Connected
On-hook
BYE
Power
BYE
Ringing
Reorder
Tone
200 OK BYE
200 OK BYE On-hook
Off-hook
INVITE
SDP:a=sendrecv
INVITE
SDP:a=sendrecv
200 OK
200 OK
ACK
ACK
A-B Connected
nd
Figure 49 - 3WC - Controller hangs up during 2 call attempt

If the controller hook flashes after establishing the 3WC, the third party that joins the call is disconnected. The other
two parties continue in a Two-Way Call. This is shown in Figure 50.
PacketCable
“A” “A” "B" “B” "C" “C”
Active Three-way Conference

Flash
BYE
BYE
200 OK BYE
200 OK BYE On-hook
A-B Connected
Figure 50 - 3WC - Controller Flashes the Hook to Disconnect Third Party in a 3WC
If the controller goes on hook during a 3WC, the conference call is disconnected. This is shown in Figure 51.
PacketCable
“A” “A” "B" “B” "C" “C”
Active Three-way Conference

On-hook
BYE
BYE
Reorder
Tone
200 OK BYE
200 OK BYE On-hook
BYE
BYE
Reorder
Tone
200 OK BYE
200 OK BYE On-hook
Figure 51 - 3WC - Controller Disconnects the 3WC
7.6 Miscellaneous Features

7.6.1 Do Not Disturb

The Do-Not-Disturb (DND) feature allows the user to put a UE into a mode in which the UE does not send an alert
when a call is presented.
The user can activate or deactivate the DND feature by entering a Vertical Service Code (VSC). Once activated by
the user, the DND remains in effect for a period of time (for example, three hours) as provisioned by the service
provider. Alternatively, the user can schedule the DND activation and deactivation via a web portal provided by the
service provider.

When the DND feature is in effect, the UE does not alert when a call is presented unless one of the following is true
of the caller:
• The caller has a DND override privilege designated by the service provider,
• The caller is identified by the DND Subscriber as exempt from the application of DND treatment, or
• The caller possesses a DND override PIN.
DND is dependent upon the Screening List Editing (SLE) feature (see Section 7.6.7) for activating or deactivating
the feature, modifying the list of callers who are exempt from DND handling, or obtaining a feature status report.
A subscriber performs these operations by going off-hook, receiving a dial-tone, and dialing the DND access code
(typically *78 and/or *79). Historically, DND once had separate activation and deactivation VSCs, but Telcordia
standards have changed recently and now support a single VSC that provides access to the SLE feature for updating
the DND feature's configuration. In order to maintain backward compatibility with the older, two-VSC method for
DND activation/deactivation, two VSCs may still be used, but either VSC invokes the same SLE feature for
updating the DND feature's configuration. This allows operators who currently have customers using *78 and *79 as
separate activation and deactivation codes to continue such use while permitting other operators who are not
currently providing screening list features to advertise just one code as a single feature code.
Once either DND feature code is successfully entered, the customer receives announcements providing the
following information (not necessarily in this order):
• The name of the service (that is, DND)
• The current status of DND (that is, active or inactive)
• The current size of the customer's DND list
- Add entr(y)ies to the list
- Delete entr(y)ies from the list
- List review
- Change status (that is, active to inactive or inactive to active).

The user can activate or deactivate the DND feature via the telephony user interface (that is, the phone keypad) by
entering a VSC. The DND VSCs are defined for the UE as part of the Digit Map as defined in Section 7.1.1. Upon
matching the user-entered digits with the DND VSC, the UE carries out the FEATURE-CHECK and MAKE-CALL
actions. If the feature availability status indicates that the DND feature is not available, then the UE MUST NOT
send the VSC to the DND AS. If the feature availability status indicates that the DND feature is available, then the
UE MUST send the VSC in an INVITE to the DND AS, using the general form of request URI described in Section
7.1.2. The DND AS MAY, in turn, connect the user to an IVR system for DND programming and activation and
deactivation.
As part of the DND programming, the DND AS MUST provide the user with an SLE feature, as described in
Section 7.6.7, to program a list of callers (which includes their public user IDs) who are exempted from the DND
treatment when the DND feature is in effect. This is the DND Exempt List defined in Table 39. The maximum
length of the list SHOULD be provisionable by the service provider and have a default value of 12. As part of the
data associated with the DND service defined in Table 39, the user has the ability to disable the use of the DND
Exempt list and also to disable the use of PIN override. These capabilities are defined in Table 39 as "DND-Exempt-
List Capability Status" and "DND-Override-PIN Capability Status" respectively.
Once the DND feature is activated, the DND AS MUST ensure that the feature remains in effect for a period of time
provisioned by the service provider (the Do Not Disturb Subscription Duration specified in Table 39), with a default
duration of three hours.
At boot time, if the UE has received configuration indicating that DND is part of the user profile, the UE will also

have received an AUID associated with DND and followed the procedures defined in Section 7.1.12. The initial
NOTIFY from the DND AS as a result of the initial post-boot time SUBSCRIBE will provide the UE with an
indication of the current activation status (as DND could have potentially been previously activated). Irrespective of
feature activation status, the UE MUST continually refresh the subscription by sending a re-SUBSCRIBE to the
DND AS for the ua-profile event package prior to the expiration of the Do Not Disturb subscription duration, as
described in Section 7.1.12.
After reception of a SUBSCRIBE to the ua-profile event package as defined in Section 7.1.12, then upon activation
or deactivation of the DND feature, the DND AS MUST send a NOTIFY for the RST Service Profile to the UE.
The resulting NOTIFY MUST inform the UE about the new activation status, via use of the schema defined in
Section 7.1.12.3, using the mechanism specified in Section 7.1.12.1. Upon receiving the NOTIFY message, the UE
MUST present to the user the Feature Activation Confirmation Indicator or the Feature Deactivation Confirmation
Indicator provisioned per Table 39.
Whenever the UE detects an off-hook condition and the DND feature is active (determined based on the feature
activation status parameter as defined in Table 40), the UE SHOULD present the user with a recall dial tone to alert
the subscriber that the DND feature is active.
The subscriber can activate or deactivate the DND feature via a web portal provided by the service provider. In this
case, the web portal performs the necessary user authentication and makes the user-entered feature status available
to the DND AS. The web portal can provide the subscriber with a tool to schedule DND sessions; however, such a
tool is out of scope.

Upon receipt of an INVITE, the DND AS associated with the callee decides if the INVITE needs to be presented to
the called UE based on the current status of the DND feature. The current feature status is determined by the feature
provisioning information and the activation/deactivation status.
If the DND feature is not active, the AS MUST forward the INVITE to the called party.
If the DND feature is active, the DND AS MUST determine if the caller has an emergency or operator services
public identity and, therefore, has the automatic DND override privilege. If the caller has the automatic DND
override privilege, the AS MUST forward the INVITE to the called UE.
If the DND feature is active, if the caller does not have the automatic DND override privilege, the DND-exempt-list
capability is disabled by the subscriber, and the DND-override-PIN capability is disabled, the DND AS MUST play
a DND announcement to the caller using the Caller Treatment Indicator, provisioned per Table 39, and terminate the
call by sending a 403 Forbidden final response.
If the DND feature is active, if the caller does not have the automatic DND override privilege, and the DND-
exempt-list capability is enabled by the user, the DND AS tries to match the calling party's public user ID with an
entry in the DND-exempt-list. If a match is established, the DND AS MUST forward the INVITE to the called
party. If a match is not found, and the DND-override-PIN capability is disabled by the user (reference Section
7.6.2), the DND AS MUST play a DND announcement to the caller using the Caller Treatment Indicator
provisioned per Table 39, and terminate the call by sending a 403 Forbidden final response.
Otherwise, the DND AS MUST send back to the caller a reliable Session Progress (183) response with an early
session disposition type, as defined in [RFC 3959], and appropriate SDP content for a two-way early media. The
AS informs the caller that the called party is not available for the call and prompts the caller to enter a DND override
PIN. The DND AS MUST validate the caller-entered PIN. If the PIN is correctly entered, the DND AS MUST
forward the INVITE to the called UE. If the PIN is incorrectly entered (after a provisioned number of tries, the
DND Override PIN Attempts in Table 39), the DND AS MUST terminate the call by sending a 403 Forbidden final
response.


Table 39 summarizes the feature data items that are defined for the implementation of DND.
Table 39 - DND Feature Data

by Requirement
Feature Availability Status Boolean Per public user ID Config.Server Config.Server AS, UE Mandatory
Feature Activation Status Boolean Per public user ID AS AS AS None
Caller Treatment Indicator Strings representing Per public user ID Config.Server Config.Server AS None
treatment options
DND Override PIN Digits Per public user ID AS AS AS None
DND Override PIN Attempts Integer Per public user ID AS AS AS None
Feature Activation Tone or Per public user ID Config.Server Config.Server UE Mandatory
Feature Deactivation Tone or Per public user ID Config.Server Config.Server UE Mandatory
DND Exempt List List of public user IDs Per public user ID AS AS AS None
DND-Exempt-List Capability Boolean Per public user ID AS AS AS None
Status
DND-Override-PIN Boolean Per public user ID AS AS AS None
Capability Status
Do Not Disturb Subscription Integer (seconds) Per public user ID Config.Server Config.Server AS Mandatory
Duration
Table 40 - Do Not Disturb UA-Profile Event Package Data Elements

Feature Activation Status Boolean Per public user ID AS AS AS, UE None
(0=inactive, 1=active)

The feature has the following interactions.
Basic Calling Capabilities
UEs with DND activated MUST be able to originate calls.
UEs with both the DND and the MWI feature provisioned and active MUST NOT play on-hook message waiting
audible indicator (ringsplash) if the MWI feature is configured for UE ringsplash when a message is waiting.
Multi-Party Features
Blind Transfer recall results in alerting, even if the DND is activated.
Call History Features
Call-back features, such as Auto Callback and Auto Recall, alert the UE that the requested the Auto Callback and
Auto Recall with DND is activated.
Call Forwarding
DND takes precedence over Call Forwarding Variable.
DND takes precedence over Call Forwarding to Voice Mail.

DND takes precedence over Call Forwarding Don't Answer.

DND takes precedence over Call Forwarding Busy.
Selective Call Forwarding takes precedence over DND.
Do Not Disturb
Busy Line Verify takes precedence over Do Not Disturb.
DND takes precedence over Anonymous Call Rejection.
7.6.1.6 Call Flows

Figure 52 illustrates the call flow for the case where the DND feature is deactivated.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify DND is not

active
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 52 - Do Not Disturb (DND) - Deactivated

Figure 53 illustrates the call flow for the case where the DND feature is activated and the caller either has the DND
override privilege or is on the DND exempt list.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify DND is active and the

caller has DND Override
privilege or is in the exempt list
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 53 - DND - Override/Exempt Privilege

Figure 54 illustrates the call flow for the case where the DND feature is activated and the caller does not have a
valid override PIN.
PacketCable
Phone UE AS
Network
“A” “A”
Call B
INVITE
INVITE
Verify DND is enabled for B
and caller does not have DND
Override privilege and is not in
exempt list
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
DND announcement and PIN collection
Verify no correct override PIN

is entered after N attempts
PIN Override failed announcement

403 Forbidden
403 Forbidden
ACK
On-hook ACK
Figure 54 - DND - Invalid Override PIN
Figure 54 illustrates the early media between the caller and the AS. In actuality, the media server handling the DND
announcement may not be integrated with the AS. Rather, it may be a standalone media resource device that is
utilized by the AS; in this case, the call flow can deviate from what is shown in Figure 54.

Figure 55 illustrates the call flow for the case where the DND feature is activated and the caller has a valid override
PIN.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify DND is active, the caller does

not have DND Override privilege
and is not in the exempt list
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
DND Announcement and PIN collection
Verify valid override

PIN is entered
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 55 - DND - Valid Override PIN

7.6.2 Subscriber Programmable PIN

The subscriber programmable Personal Identification Number (PIN) feature allows a subscriber to manage PIN
codes for features that require personal identification numbers. When a subscriber is given access to a feature that
requires a PIN, the service provider provides an initial PIN. This PIN must be changed the first time that the
subscriber attempts to use the PIN. The Subscriber Programmable PIN (SPP) feature provides an interface for the
subscriber to change PIN codes for different features on an as needed basis (that is, because they are being forced to
change the initial PIN, or because they want to change their PIN for personal reasons).
The SPP feature is accessed from the public identity that is subscribed to the SPP feature. This helps to improve the
security of the SPP feature by preventing someone with a different P-Asserted-Identity from changing the
subscriber's PIN.
If the subscriber is attempting to use a service-provider-supplied PIN for the first time, and the subscriber is calling
from his public identity, the subscriber is prompted to enter a new "N" digit PIN number. If the subscriber enters a
valid length PIN that is different from the PIN supplied by the service provider, the subscriber is then prompted to
enter the same PIN again for verification. If the PIN numbers provided in the initial and confirmation attempts are
the same, the new PIN is stored and the subscriber is notified of the success of the PIN change. If the two PIN
attempts do not match, the subscriber is prompted to try again. The number of PIN programming attempts is limited
to some service provider-provisioned value.
If the subscriber cannot successfully complete PIN programming within the allowed number of attempts, the
subscriber is notified of the PIN programming failure, asked to try again later, and the call is terminated.
If a subscriber desires to change a PIN that was not supplied by the service provider, the subscriber interacts with the
service provider's SPP interface. This interface can be a web based or an interactive voice response system. Only the
IVR interface is described in this specification.
7.6.2.2 Feature Activation/Deactivation

The SPP feature is not provisioned by itself, but is made available whenever a feature requiring SPP is made
available in the UE. Examples of features requiring SPP are Do Not Disturb and Outbound Call Blocking. Whenever
a feature requiring SPP is provisioned on the UE, the procedures for handling the SPP VSC should also be
provisioned on the UE (this may include any combination of digit maps combined with locally-stored procedures).

The user can access the SPP feature via the telephony user interface (that is, the phone keypad) by entering a VSC.
The SPP VSC is defined for the UE as part of the Digit Map defined in Section 7.1.1. Upon matching the user-
entered digits with the SPP VSC, the UE carries out the FEATURE-CHECK and MAKE-CALL actions. If the
feature availability status indicates that the SPP feature is not available, then the UE MUST NOT send the VSC to
the SPP AS. If the feature availability status indicates that the SPP feature is available, then the UE MUST send the
VSC in an INVITE to the SPP AS, using the general form of a request URI described in Section 7.1.2. The SPP AS
MAY, in turn, connect the user to an IVR system for SPP programming.
Upon receipt of an INVITE identifying the SPP feature, and if the SPP feature is determined to be active for that
user, the SPP AS MUST send back to the caller a reliable Session Progress (183) response with an early session
disposition type as defined in [RFC 3959], and appropriate SDP content for a 2-way early media. At this point, the
exact interaction between the SPP AS and the user is left to the service provider.
Upon completion of the SPP process, the SPP AS MUST terminate the session by sending a 487 Request
Terminated message.


Table 41 summarizes the feature data defined to support implementation of the SPP feature.
Table 41 - Subscriber Programmable PIN Feature Data


The following feature interaction applies to SPP:
• Once SPP programming is started, flash processing by the UE MUST be disabled.
7.6.2.6 Call Flows


Figure 56 provides an informative call flow of the Subscriber Programmable PIN editing feature. This flow assumes
a voice- and DTMF-capable IVR with the ability to understand audible and DTMF responses. PIN editing
exchanges are usually performed using such exchanges.
PacketCable
Phone A UE A AS
Network
Off-hook
Dialtone
SPP VSC dialed

SPP VSC INVITE
SPP VSC INVITE
Check to determine if
subscriber has the SPP
feature. That is, does the
subscriber have a feature that
can use a programmable PIN.
183 w/SDP
183 w/SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Confirmation and Request for Feature ID to Edit PIN
Feature VSC entered in-band to IVR
PIN Editing Sequence Commences
PIN Edit Confirmation or Failure Indication
487 Request
Terminated
487 Request
Terminated
ACK
ACK
On-hook
Figure 56 - Subscriber Programmable PIN (SPP)

7.6.3 Distinctive Alerting

The Distinctive Alerting (DA) feature allows different alerting patterns to be rendered to the user on a per call basis.
The selection of a particular alerting pattern for a given incoming call is determined by the Distinctive Alerting
Application Server (DA AS) in the terminating network. The overall execution of the feature is carried out jointly
between the DA AS and the called UE.
The alert-selection logic on the AS may be provisioned by the service provider, a third-party service provider, or by
the users themselves. For instance, a user may specify such logic via a web portal, and may select the alerting
pattern based on the caller information.
The DA AS inserts a reference to the selected alerting pattern in the incoming INVITE and forwards the INVITE to
the called UE (via the terminating S-CSCF), which in turn renders the specified alerting to the user.
Distinctive Alerting is dependent upon the Screening List Editing (SLE) feature. A subscriber can initiate
procedures for activating, deactivating, modifying or obtaining a status report for Distinctive Alerting by going off-
hook, receiving a dial-tone, and dialing the Distinctive Alerting VSC (typically *61 for activation and *81 for
deactivation). In the past, DA had separate activation and deactivation VSCs, but Telcordia standards have changed
to support a single VSC that provides access to the SLE feature for updating the DA feature's configuration. In order
to maintain backward compatibility with the older, two-VSC method for DA activation/deactivation, two VSCs may
still be used but either VSC will invoke the same SLE feature for updating the DA feature's configuration. This
allows operators who currently have customers using *61 and *81 as separate activation and deactivation codes to
continue such use while permitting other operators who are not currently providing screening list features to
advertise just one code as a single feature code.
[GR 219] describes the SLE feature for Distinctive Ringing/Call Waiting.

The activation and deactivation of the Distinctive Alerting feature is performed by the service provider as part of the
service provisioning for a user. The associated provisioning procedures are outside of the scope for this
specification. However, the feature activation/deactivation status is made available to the DA AS.
The dynamic activation and deactivation of the Distinctive Alerting feature is not required.
With the Distinctive Alerting feature activated, the user may be able to configure the alert patterns and their
selection criteria via a web portal.
With the Distinctive Alerting feature activated, the UE MUST be able to initiate an SLE session to configure the
public identities that cause distinctive alerts when an INVITE from any of these public identities is received. Once
either Distinctive Alerting feature code has been successfully entered as part of the FEATURE-CHECK and
MAKE-CALL digit map actions, the UE checks to see if the Distinctive Alerting feature is available. If the feature is
available, then the UE MUST send the VSC in an INVITE. to the DA AS, using the general form of request URI
described in Section 7.1.2. If the feature is unavailable, the UE MUST NOT send an INVITE.
The subscriber receives announcements providing the following information (not necessarily in this order):
• The name of the service (that is, Distinctive Alerting)
• The current size of the subscriber's Distinctive Alerting list
- Add entr(y)ies to the list
- Delete entr(y)ies from the list
- List review


The feature execution of the Distinctive Alerting is carried out jointly by both the terminating Distinctive Alerting
AS and the called UE, with the former performing the selection of an alert pattern for the incoming call and the
latter appropriately rendering the pattern to the user.
For an incoming INVITE request, the DA AS checks to see if the subscriber identified by the request URI has the
DA feature activated. If the feature is not activated for the subscriber, the DA AS MUST NOT perform any
Distinctive Alerting processing before forwarding the INVITE to the called party.
If the feature is activated for the subscriber, and the call is determined to receive a distinctive alert, the DA AS
checks the caller's Caller ID display status against the distinctive alerting precedence over Caller ID blocking. If the
distinctive alerting precedence over Caller ID blocking is enabled, the DA AS MUST insert an Alert-Info header
into the INVITE request to convey the selected alert that the called UE needs to apply. If the distinctive alerting
precedence over Caller ID blocking is disabled and the caller has indicated Caller ID blocking, the DA AS MUST
insert an Alert-Info header into the INVITE request indicating the default alert pattern. If the distinctive alerting
precedence over Caller ID blocking is disabled and the caller has not requested Caller ID blocking, the DA AS
MUST insert an Alert-Info header into the INVITE request to convey the selected alert which the called UE needs to
apply.
Upon receiving the incoming INVITE request with an Alert-Info header parameter, the called UE MUST alert the
user according to the pattern carried in the Alert-Info header parameter. If the Alert-Info header is not present in the
request, the UE SHOULD apply a default alert pattern to the user.
The UE MUST map the value received in the Alert-Info header into a well-defined signal (either audio or visual)
and render it to the user. If the UE determines that the value of the Alert-Info header is in error, the UE MUST play
the locally provisioned standard (rg) Alerting pattern defined in Section 7.1.6.3 (the UE cannot select any specific
Distinctive Alerting pattern since the alert-info header is in error. Use of the standard alerting pattern provides a
basic call announcement to the end user).
Both the UE and the DA AS need to support a baseline set of alert patterns. In particular, the DA AS MUST be able
to populate the Alert-Info header with a URI to indicate a Distinctive Ringing tone identifier, as defined in Section
7.1.6.3. The UE MUST be able to map such an identifier to the corresponding alert signal. The cadence definitions
for these ringing signals may be provisioned according to the cadence requirements in [GR 506].

Table 42 summarizes the feature data items that are defined for the implementation of Distinctive Alerting.
Table 42 - Distinctive Alerting Feature Data

Requirement
Feature Availability Boolean Per public Config.Server Config.Server UE Mandatory
Status user ID
Distinctive Alerting Boolean (0=Caller ID blocking Per public AS AS AS None
precedence over has precedence, 1=Distinctive user ID
Caller ID blocking Alerting has precedence)


Call Waiting
When the Call Waiting feature is activated for the called UE and the Distinctive Alerting AS has access to the Call
Waiting activation status, the Distinctive Alerting AS MAY select a special alert that can either provide distinctive
ringing or a distinctive call waiting alert to the called party. This allows the UE to provide the appropriate alert,
depending on whether the called party is engaged in an active call or not. The Distinctive Alerting AS provides this
alert by populating the Alert-Info header with a URI to indicate Call Waiting tone identifier as specified in Section
7.1.6.3. The UE can interpret this Alert-Info header based upon whether it is in an active call. The called UE MUST
map the dual-mode alert specified by the Alert-Info header to a distinctive ringing alert if the UE is idle. The called
UE MUST map the dual-mode alert specified by the Alert-Info header to a distinctive call waiting tone if the UE is
engaged in an active call.
When an INVITE for a call waiting call is received with an Alert-info containing a distinctive ringing indication r0,
r1, r2, r3, r4, r5, r6 or r7, the UE MUST treat it as if the corresponding call waiting tone specified in Table 43 was
received instead.
Table 43 - Distinctive Tones for Call Waiting
Received Ringing Indication Corresponding Call Waiting Tone

r1, r0, r6, or r7 wt1
r2 wt2
r3 wt3
r4 wt4
Caller ID Display Blocking

When the calling party has requested that his or her Caller ID not be displayed, if the call is determined by the
distinctive alerting algorithm to receive a distinctive alert, and when the DA AS is configured to give Distinctive
Alerting precedence over Caller ID Display Blocking, then the DA AS MUST provide the Distinctive Alerting
Treatment.
When the calling party has requested that his or her Caller ID not be displayed, if the call is determined by the
distinctive alerting algorithm to receive a distinctive alert, and when the DA AS is configured to give Caller ID
Display Blocking precedence over Distinctive Alerting, then the DA AS MUST NOT provide the Distinctive
Alerting Treatment.
Note: Telcordia [GR 219] specifies that Distinctive Alerting should take precedence over Caller ID Display
Blocking, in that the called party receives the distinctive alerting treatment but does not have the number
displayed. This specification also allows the reverse precedence to occur if desired, so that Distinctive
Alerting is not provided when the caller requests anonymity.
Besides the alert selection for the incoming call and the other interactions specified in this section, the Distinctive
Alerting feature does not impact the execution of any other features. In particular, even with the presence of the
Alert-Info header in the INVITE request, the UE MUST NOT render the alert to the user if the normal execution of
other activated features require that the user not be alerted.
On the other hand, if the normal execution of other activated features requires that the user be alerted, the Alert-Info
header MUST be honored in rendering the alert to the user.

7.6.3.6 Call Flows

Figure 57 illustrates a call flow for Distinctive ringing execution.
PacketCable
Network
“A” “A” "B" “B”
Call B
INVITE
INVITE
Verify Distinctive Alerting

treatment and insert Alert-Info
header with selected pattern
INVITE
Alert-Info
INVITE Alert-Info
Distinctive
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 57 - Distinctive Alerting (DA) - Distinctive ringing

Figure 58 illustrates a call flow for Distinctive call waiting execution.
PacketCable
Network
“A” “A” "B" “B” "C" “C”
Active Call
Call A
INVITE
INVITE
Verify Distinctive Alerting

treatment and insert Alert-Info
header with selected pattern
INVITE
Alert-info
INVITE Alert-info
Distinctive
Call Wait
Tone
180 Ringing
180 Ringing
180 Ringing
Flash 180 Ringing
INVITE Ringback
SDP: a=inactive Tone
INVITE
SDP: a=inactive
200 OK
SDP: a=inactive
200 OK
SDP: a=inactive
ACK
ACK
Held Media
200 OK
200 OK
200 OK
200 OK
ACK
ACK
A-C Connected
Figure 58 - DA - Distinctive call waiting
7.6.4 Message Waiting Indicators

Message Waiting Indicators (MWI) are used by the UE to alert the user that the status of a message account
associated with the subscriber is changed. The message account is assigned to the UE by the service provider and is
identified by the account's public user identity. In general, the message account can retain multimedia messages (for
example, voice, fax, video, text, etc.). However, for convenience of description and without loss of generality, this
specification assumes that the message account retains voice messages only; in this case, the message account can
be considered as a voice-mail box.

The MWI Application Server (MWI AS) detects status changes of the message account. The actual detection
mechanism is outside of the scope for this specification, but may involve the MWI AS's signaling with an embedded
or standalone message storage and processing system.
The MWI AS notifies the status change of the message account to the UE as an MWI. This notification follows the
general process of SIP event subscription/notification. Once received, the MWI is presented by the UE to the user as
a visual signal and/or an audible signal.

The service provider performs MWI activation and deactivation as part of service provisioning for a user. The
associated provisioning procedures are outside of the scope for this specification. However, the feature
activation/deactivation status is assumed to be provisioned at the MWI AS by the service provider. User-initiated
activation and deactivation of the MWI feature is not required.

The MWI feature is built on the basis of the SIP event subscription/notification framework. The UE and the MWI
AS, as the subscriber user agent and the notifier user agent respectively, MUST meet the general PacketCable
requirements for SIP event subscription/notification, as described in [PKT 24.229].
If the Feature Availability Status (Table 44) is enabled, the UE MUST send out a SUBSCRIBE request after the UE
completes its initial registration and provisioning, subscribing to the Message Summary and Message Waiting
Indication Event Package (defined in [RFC 3842]) associated with the subscriber's message account. Once
successfully subscribed to the MWI Event Package, the UE MUST refresh the subscription during the runtime
before the currently active subscription is timed out. The subscription duration is configured as the Subscription
Duration parameter as described in Table 44. The UE MUST use the value of the Subscription Duration, if
provisioned, in the Expires header of the SUBSCRIBE request to indicate the desired length of the subscription.
The recipient MWI AS is responsible for the authorization of all incoming SUBSCRIBE requests. The complete
criteria for such authorizations are specific to the service provider and are outside of the scope for this specification.
However, if the requestor is not provisioned with the MWI feature, the MWI AS MUST reject the request by
sending back to the requesting UE a 403 (Forbidden) or 603 (Declined) response. If the authorization is successful,
the MWI AS MUST respond with a 200 OK response and start to detect the status change for the message account.
As required by [RFC 3265], the MWI AS MUST also send a NOTIFY message to the UE, notifying it of the current
status of the message account. Upon receipt of a SUBSCRIBE without the Expires header, the MWI AS MUST use
the provisioned Subscription Duration value to populate the Expires header in the 200 OK response to indicate the
subscription duration.
The MWI AS detects the occurrences of the subscribed events that are associated with the subscriber's message
account. Such events are triggered to the MWI AS by the embedded or standalone message storage and processing
system. If the MWI AS detects an MWI event and the subscription from the UE has not expired, the MWI AS
MUST send a NOTIFY message to inform the UE of the status change of the message account. If the subscription
from the UE has expired, the MWI AS SHOULD NOT send a NOTIFY message to the UE.
The formatting of the above-mentioned SUBSCRIBE and NOTIFY messages MUST conform to [RFC 3842].
When the NOTIFY message is received from the MWI AS, the UE MUST render the corresponding MWI to the
user or user's CPE device, per client capabilities. The UE presentation to the user or user's CPE device could be an
electrical signal (for example, telephony RJ-11 ports) and/or a visual signal and/or an acoustic (audible) signal as
supported by the UE.


Table 44 summarizes the feature data items that are defined for the implementation of MWI.
Table 44 - MWI Feature Data

Requirement
Feature Availability Status Boolean Per public user ID Config.Server Config.Server AS, UE Mandatory
Subscription Duration Integer Per network Config.Server Config.Server AS, UE Mandatory
(seconds)

Do-Not-Disturb (DND)
If both DND and MWI are in effect, any audible alert for waiting messages should not be presented by the UE until
the DND is deactivated, but a visual MWI MAY still be presented by the UE.
The MWI feature does not interact with any feature other than DND.
7.6.4.6 Call Flows

Figure 59 shows a call flow for the UE's successful subscription to the Message Summary Event Packet.
PacketCable
Phone UE AS
Network
“A” “A”
UE inits or refreshes
subscription
SUBSCRIBE
Msg Sum Ev Pkg
Msg Acc “A” SUBSCRIBE
Msg Sum Ev Pkg
Msg Acc “A”
Verify authorization for

MWI SUBSCRIBE
200 OK
SUBSCRIBE
200 OK
SUBSCRIBE
NOTIFY
Msg Acc “A”
NOTIFY
Msg Acc “A”
200 OK NOTIFY
MWI 200 OK NOTIFY
Figure 59 - Message Waiting Indicator (MWI) - Successful subscription authorization

Figure 60 shows a call flow for the UE's rejected subscription to the Message Summary Event Package. The
rejection was a result of the failed authorization for the MWI feature.
PacketCable
Phone UE AS
Network
“A” “A”
UE inits or refreshes
subscription
SUBSCRIBE
Msg Sum Ev Pkg
Msg Acc “A” SUBSCRIBE
Msg Sum Ev Pkg
Msg Acc “A”
Deny authorization for

MWI SUBSCRIBE
403 Forbidden
403 Forbidden
Figure 60 - MWI - Failed subscription authorization

Figure 61 shows a call flow for the MWI triggering that is a result of a new voice mail left by a caller.
PacketCable
Network
“A” “A” "B" “B”
Call A
INVITE
INVITE
Verify voicemail
is enabled for A
200 OK
200 OK
ACK
ACK
B leaves message for A
Onhook
BYE
BYE
200 OK BYE
200 OK BYE
Msg Acc A
changes status
NOTIFY
Msg Acc A Stat
NOTIFY
Msg Acc A Stat
200 OK NOTIFY
MWI 200 OK NOTIFY
Figure 61 - MWI - Message account status change
7.6.5 Speed Dialing

The network based Speed Dialing feature allows the user to dial frequently-called public user IDs by assigning them
either one-digit or two-digit speed-dialing codes. One-digit Speed Dialing usually accommodates eight IDs (2 - 9).
Two-digit Speed Dialing can accommodate up to 99 IDs, but is usually limited to a more reasonable set of
frequently-dialed IDs (for example, 30). If both one- and two-digit dialing are allowed simultaneously, then two
different Vertical Service Codes (VSC) are needed (for example, *74 for one-digit Speed Dialing and *75 for two-
digit Speed Dialing) for the programming of the speed dialing list.
After the speed-dialing code is entered, and a 4-second timer expires or a pound sign (#) is dialed by the subscriber,
the call is placed for the user as if the ID represented by the speed-dialing code was dialed.
There are different schemes to program the frequently-dialed public user IDs associated with a UE. The IDs can be
programmed by using a UE to interact with an IVR system managed by the service provider or via a web-based
subscriber management function. Such programming allows for the creation of the list of IDs and the associated
speed-dialing codes.

This specification supports a network-based approach for implementing the Speed Dialing feature. It also optionally
allows the operator to configure the UE to implement the SD feature locally. The local implementation is needed in
support of the SD feature for special digit strings such as "911" or VSCs. In this case, it is assumed that the SD
information (codes and corresponding digit strings) are captured by the network when the user performs the SD
programming via a web portal or via a handset associated with the UE.
Refer to Telcordia LSSGR: Speed Calling (FSD-01-02-1101) for more detail on the PSTN equivalent feature. This
is also known as [GR 570].

The activation and deactivation of the Speed Dialing feature is performed by the service provider as part of the
service provisioning for a user. The associated provisioning procedures are outside of the scope for this
specification. However, the feature activation/deactivation status is assumed to be available to the Speed Dialing
Application Server (SD AS) and the UE.
The dynamic activation and deactivation of the speed dialing feature is out of scope.
With the feature activated, the subscriber MUST be able to initiate the programming of the speed-dialing list by
entering a VSC (for example, *74 for one-digit Speed Dialing and *75 for two-digit Speed Dialing). Upon matching
the user-entered digits with a Speed Dialing VSC, the UE carries out the FEATURE-CHECK and MAKE-CALL
actions. If the feature availability status indicates that SD feature is not available, then the UE MUST play a denial
announcement or tone to the user. Otherwise, the UE MUST follow the general requirements provided in Section
7.1.2 to send the VSC to the SD AS, which in turn connects the user to an IVR for the programming. Alternatively,
a web portal can also be provided to the user by the service provider for programming the speed-dialing list. In
either case, the requirements for the valid speed-dialing codes in Telcordia [GR 570] MUST be followed.

7.6.5.3.1 Network Implementation
If the feature data Speed Dialing Local Implementation Enabled (Table 45) is ''false', the UE supports only the
network-based SD implementation. The following requirements apply to the network-based approach to SD
implementation.
When the user invokes the Speed Dialing feature, the UE MUST construct and initiate an appropriate INVITE with
the captured speed-dialing code in the Request URI as follows:
sip:<SD>@domain; user=dialstring
where <SD> is the 1 or 2 speed dial digit that the user entered.
Upon receiving the INVITE request, the SD AS performs the necessary authorization to determine whether or not
the Speed Dialing feature is activated for the originating UE. If the authorization fails, the SD AS MUST respond to
the INVITE with a 403 Forbidden response to reject the call attempt. Upon receiving the 403 Forbidden response,
the UE MUST apply the reorder tone to the user.
If the authorization succeeds, the SD AS MUST map the speed-dialing code in the Request URI into the public user
ID of the intended destination party. If the mapping is successful, the SD AS MUST replace the original Request
URI in the received INVITE with the resulting public user ID of the intended destination party, and forward the new
INVITE. If the mapping fails (that is, there is no entry corresponding to the speed-dialing digit), the SD AS MUST
indicate the failure to the UE. One possible mechanism used for this failure indication is the SD AS rejecting the
INVITE, so that the UE plays an error tone or announcement. Another option is for the SD AS to play an
appropriate announcement to the user by setting up an early media between the UE and the SD AS (or any stand-
alone announcement machine).
7.6.5.3.2 Local Implementation
If the feature data Speed Dialing Local Implementation Enabled (Table 45) is ''true', the UE enables the local UE-
based SD implementation. The following requirements apply to the local approach to SD implementation.

During the processing of the user digits input, the UE MUST try to match input digits with any of the values in the
SD Code field of the Speed Dialing Local Map table, starting from the top entry to the bottom entry of the table. In
this matching operation, the UE MUST assume that each SD Code is appended with a short inter-digit timer at the
end. If a match is established, the UE MUST apply the resulting digit string to the Digit Map as the user input digits
and follow the usual Digit Map processing from the very beginning, assuming that there is no delay between the
digits of this input string and there is a delay after the last digit that is longer than the short inter-digit timer. The
assumed delay at the end of the resulting string is added for the purpose of pattern matching. The UE SHOULD
NOT include this delay for inter-digit timing, if additional digits are expected to follow the matched pattern
according to the Digit Map.
If a match is not found for the dialed speed code in the Speed Dialing Local Map table, then the UE executes the
requirements for Network Implementation specified in Section 7.6.5.3.1.

Table 45 summarizes the feature data items that are defined for the implementation of Speed Dialing.
Table 45 - Speed Dialing Feature Data

by Requirement
Speed Dialing Map Table Table Per public user ID AS AS AS None
VSC for Programming 1-Digit VSC Per public user ID AS AS AS None
Speed Dialing
VSC for Programming 2-Digits VSC Per public user ID AS AS AS None
Speed Dialing
Speed Dialing Local Boolean Per public user ID Config.Server Config.Server UE Mandatory
Implementation Enabled Default: false
Speed Dialing Local Map Variable length Per public user ID Config.Server Config.Server UE Mandatory
array of SD
Local Map
entries
SD Local Map Entry.SD Code String Per public user ID Config.Server Config.Server UE Mandatory
SD Local Map Entry.SD Digit String String Per public user ID Config.Server Config.Server UE Mandatory

If the originating UE subscribes to speed dialing and OCB, speed dialing needs to be invoked first so that the OCB
service knows the actual destination number to check for blocking.
Three-Way Calling
Speed Dialing is usable for entering the called party ID during Three-Way Calling.
Call Forwarding
Speed Dialing is usable for entering the called party ID during various Call Forwarding features.
7.6.5.6 Call Flows


Figure 62 shows a call flow for the normal execution of the Speed Dialing feature:
PacketCable
Network
“A” “A” "B" “B”
Speed Dial
Digits
INVITE
SD Digits
INVITE
SD Digits
Verify SD is active and the

digits are mapped
INVITE B
INVITE B
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
A-B Connected
Figure 62 - Speed Dialing (SD)
For the Speed Dialing Feature, the AS does not need to record the route. Therefore, only the responses associated
with the INVITE request are sent back to the AS.

Figure 63 shows a call flow for the case of failed authorization for the Speed Dialing feature.
PacketCable
Phone UE AS
Network
“A” “A”
Speed Dial
Digits
INVITE SD Digits
INVITE
SD Digits
Deny Speed Dial
403 Forbidden
403 Forbidden
Reorder
Tone
ACK
On-hook ACK
Figure 63 - SD - Failed authorization
Figure 64 shows a call flow for the case where the user-provided speed-dialing digit cannot be mapped into a
destination public user ID.
PacketCable
Phone UE AS
Network
“A” “A”
Speed Dial
Digits
INVITE SD Digits
INVITE
SD Digits
SD is enabled, but digits

are not mapped
183 with SDP

183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
SD announcement
On-hook
CANCEL
CANCEL
200 OK
CANCEL
200 OK CANCEL
487 Request
Terminated
487 Request
Terminated
ACK
ACK
Figure 64 - SD - No Mapping

7.6.6 Customer-Originated Call Trace

The customer-originated call tracing (COT) feature allows the receiver of an obscene, harassing, or threatening call
to initiate a call trace. This terminating call feature is often called Malicious Call Tracing, but the COT feature adds
the capability for the offended party to invoke the trace. After the offended customer invokes the call trace
procedure, the appropriate service authorized agency handles the disposition of the malicious call or calls.
The intent of this COT specification is to simulate the user behavior and general feature operation as defined in
[GR 216].
After receiving and ending the malicious call, the COT customer activates the feature by going off hook, listening
for a dial tone, and then dialing the call trace activation code (usually *57) to begin the tracing activities. The COT
customer needs to activate the feature immediately, prior to the arrival of a new incoming call, since only the
information of the last call is stored by the COT feature.
7.6.6.2 Actions Prior To Feature Execution

Whenever the UE has been configured to provide the COT feature, via the Feature Availability Status parameter, the
UE MUST store the public identity of the most recent non-emergency and non-operator caller contained within the
P-Asserted-Identity header, Dialog-ID, and time stamp of the last calling party for which the call was answered.
The UE MAY persistently store this information. If the most recent non-emergency and non-operator caller was
anonymous (either because the caller blocked the delivery of their identity, or because the identity was unavailable),
the UE MUST store the call ID, as presented in the CallID header of the anonymous call.
Further, whenever a public identity is subscribed to the COT feature, all anonymous calls placed to the public
identity are sent to the COT Application Server (COT AS). This allows the COT AS to log the most recently
blocked public identity (which is contained in the P-Asserted-Identity header of the INVITE). The COT AS stores
call data for all terminating calls that originate from a UE who has privacy invoked and for which a 200 OK was
received from the called UE. The COT AS MUST record both the most recent terminating call that originates from a
UE who has privacy invoked, and any additional terminating calls that originate from a UE who has privacy invoked
that arrive within the defined Call History Time Period. It is recommended that the Call History Time Period be set
to at least two minutes.

The user can activate the COT feature by entering the VSC for COT. The COT VSC is defined within the UE's Digit
Map as defined in Section 7.1.1. Upon matching the user-entered digits with the COT VSC, the UE carries out the
COT-ACTIVATE action. If the feature availability status indicates that the COT feature is not available, then the
UE MUST play a denial announcement or tone to the user.
If the feature availability status indicates that the COT feature is available, then the UE MUST send an INVITE with
the COT VSC to the COT AS using the general form of request URI described in Section 7.1.2. In this INVITE, the
UE MUST include a P-DCS-TRACE-PARTY-ID header and set the value of this header as defined by [RFC 5503].
If the identity is known to the UE, the UE MUST set the addr-spec contained in the name-addr of the P-DCS-
TRACE-PARTY-ID header to include the calling UE's public identity (P-Asserted-ID). If the identity is unknown
to the UE, the UE MUST set the P- DCS-TRACE-PARTY-ID header as specified for the non-anonymous case, but
with "anonymous" in place of the P-Asserted-ID (anonymous@anonymous.invalid). In both cases the UE MUST
include a Target-Dialog header [RFC 4538] as described in [RFC 5503].
Following is an example of an INVITE where the identity of the original caller is known:
INVITE sip:*57@example.com;user=dialstring SIP/2.0
...
P-DCS-Trace-Party-ID: <sip:+15619235918 @serviceprovider.com;
user=phone>;timestamp=3434688831.2327
Target-Dialog:a84b4c76e66710; local-tag=a6c85cf; remote-tag=1928301774

Following is an example of an INVITE where the identity of the original caller is not known:
INVITE sip:*57@example.com;user=dialstring SIP/2.0
...
P-DCS-Trace-Party-ID: <sip:anonymous@anonymous.invalid>;timestamp=3434688831.2327
Target-Dialog:a84b4c76e66710; local-tag=a6c85cf; remote-tag=1928301774
Upon receipt of an INVITE identifying the COT feature, the COT AS checks the contents of the P-DCS-TRACE-
PARTY-ID header. If the P-DCS-TRACE-PARTY-ID header indicates the call is not anonymous the COT AS
MUST prompt the user to confirm that the trace is wanted.
If the P-DCS-TRACE-PARTY-ID header indicates the call is anonymous, the COT AS searches its network-based
call logs to discover the identity of the anonymous caller identified in the Target-Dialog header. If the COT AS is
not able to find the identity of the caller matching the call ID provided by the requester, the COT AS MUST fail the
COT request by playing an error announcement to the requester, according to the procedures specified in Section
7.1.6. If the COT AS does find the identity of the caller matching the call ID provided by the requester, the COT AS
MUST prompt the user to confirm that the trace is wanted.
Upon confirmation of the feature by the subscriber, the AS MUST complete the feature execution and play a
confirmation message indicating success or failure of the trace collection procedure.
If confirmation is not provided by the subscriber, the AS MUST NOT complete the feature execution.

Table 46 summarizes the feature data defined to support the implementation of the COT feature.
Table 46 - Customer Originated Trace Feature Data
Data Type Scope Stored By Written By Read By Config.Server

Requirement
Feature Availability Status Boolean Per public Config.Server Config.Server UE Mandatory
user ID
P-Asserted Identity Header ASCII string Per session AS or UE (Note 1) P-CSCF, S-CSCF AS, UE None
Call History Time Period Integer Per network AS AS AS None
(seconds)
Note 1: Depends on the presentation status of the call originator

Call Forwarding
If the malicious call was forwarded enroute to the COT subscriber, the UE captures the public identity of the
originating caller, not the customer who forwarded the call.
Speed Dialing
If a user programs the call trace VSC as a speed dial number, then the COT feature is not invoked when the speed
dial number is dialed. This is because speed dialing is a network based service, while COT is a UE-based service, so
the Speed Dial Application Server would not have the necessary information to process a call trace request when it
is received.
Auto Recall
If a new call is received but not answered, the UE MUST NOT over-write the last answered calling party
information, but rather MUST store this as a new un-answered call attempt. When the user invokes the AR feature,
the UE MUST use the stored information (un-answered or answered call) with the most recent time stamp.
7.6.6.6 Call Flows


Figure 65 shows how the COT AS collects the tracing information for all terminating calls in which the call
originator has elected privacy in delivering Caller ID information to the called party.
UE P-CSCF S-CSCF AS Network

“A”
INVITE
Evaluation of initial
Filter Criteria
INVITE
Store trace data
INVITE
INVITE
INVITE
Figure 65 - COT - Collection of tracing information when caller's identity is restricted
7.6.7 Screening List Editing

Screening List Editing (SLE) is a set of procedures that is intended to allow customers to activate and deactivate
features that use lists, obtain feature status reports, and create and modify lists of addresses in the form of Directory
Number, Tel URIs or SIP URIs. Each list is associated with a particular feature to identify those calls that should be
given special treatment.
UEs with analog interfaces MUST conform to the service behavior requirements in Telcordia [GR 220] unless
otherwise specified here.
have widely varying user interface capabilities. In addition to the wide range of UEs, an operator can offer a web
client mechanism to allow a subscriber to manage his or her service data. The current description is limited to
interactions with the analog interface telephony UE, rather than with service management web clients.
In general, SLE supports revenue-producing features that are intended for residential as well as small business
public identities. These features can support applications between networks in which signaling methods capable of
transmitting calling-line identification are deployed.
SLE is used to support features such as Selective Call Forwarding (SCF – see Section 7.3.5), Distinctive
Ringing/Call Waiting (DRCW – see Section 7.6.3), the Do Not Disturb white list (see Section 7.6.1), Selective Call
Rejection (SCR – not specified at this time), Solicitor Blocking (see Section 7.4.3), Selective Call Acceptance (SCA
– not specified at this time), and, potentially, other new feature applications as well.
Regardless of the screening-list feature that SLE is supporting, once the feature code has been processed by the AS,
and the AS has connected the UE with an SLE announcement server and digit collection function, the DTMF digit
interaction method used ([RFC 2833] or in-band RTP) is governed by SDP offer-answer exchange. A SLE
supporting server typically operates with a voice-menu style prompt, response, and action pattern.
7.6.8 Network-Based Call Screening

The network-based call screening (NBCS) feature allows the NBCS customer to monitor a call that has been
forwarded to a network-based voicemail server. The customer is able to listen automatically to the voicemail

greeting and the message being left by the caller in real-time without the need for customer intervention. At any
point during the NBCS operation, the customer may accept the call and terminate the NBCS operation.
Network-based call screening operates in conjunction with Call Forwarding Don't Answer (CFDA), Call Forwarding
Variable (CFV) and Selective Call Forwarding (SCF). In all cases; the NBCS feature is activated once it has been
determined that the call is to be forwarded to an address that identifies a voicemail server.
This feature is not applicable to devices that are not equipped with a speakerphone. This feature is not mandatory for
devices that are equipped with a speakerphone. UEs that are equipped with a speakerphone are required to have the
ability to automatically answer an incoming call by activating the speakerphone. The requirements in this
specification apply only to UEs with a speakerphone.

The availability of the NBCS feature is performed by the service provider as part of the service provisioning of the
user. The associated provisioning procedures are outside of the scope of this specification. However, the feature
availability status is made available to the NBCS AS. User-initiated activation and deactivation is outside of the
scope of this specification.

When CFV, CFDA or SCF is invoked with a Forward-to address that identifies voicemail and the NBCS feature is
available, then the NBCS AS will receive the INVITE that was originated by the CF AS based on appropriate Initial
Filter Criteria. The NBCS AS MUST proxy the INVITE to the UE with an Alert-Info header containing
"urn:cablelabs:packetcable:applications:rst:alert:silence".
Upon receiving an INVITE with an Alert-Info header containing
"urn:cablelabs:packetcable:applications:rst:alert:silence", the actions at the UE are dependent on the hook state and
the dialog state of the UE as explained below.
If the UE is involved in an existing provisional or confirmed SIP dialog, or if the hook state of the device is off-hook
(irrespective of Call Waiting status); then the UE MUST respond with a 486 Busy response.
Otherwise, if the UE is idle then the UE MUST respond to the INVITE with a 18x response message and follow the
Basic Call Signaling procedures defined in Section 7.1.4.2 with the following exceptions:
• The UE MUST NOT alert the user.
• If a new out of dialog INVITE containing an offer SDP is received by the UE while an NBCS operation is
already in progress, the UE MUST reject the INVITE with a 486 Busy response.
When the NBCS AS receives an 18x response to this INVITE from the UE, the NBCS AS continues execution of
the NBCS feature.
If the NBCS AS receives a 486 Busy response for the INVITE request that it proxied to the UE, then the NBCS AS
MUST terminate the NBCS feature and allow the call to continue per the triggered terminating services. For
example, if the NBCS feature is invoked as a result of CFV with a Forward-to address identifying voicemail, and the
NBCS AS received a 486 Busy response for the proxied INVITE, then the terminating services associated with CFV
continue such that the call is routed to voicemail.
In the rest of this subsection, the term "original INVITE" or "original dialog" refers to the first INVITE request that
is sent from the NBCS AS to the UE.
Following reception of the 18x response for the original INVITE, the NBCS AS MUST send a SIP INVITE to the
UE populated as follows:
• Request URI identifying the same public user identity as the original INVITE
• Join header field identifying the dialog ID of the original INVITE
• Answer-Mode header field with a value of "Auto"
• From header field copied from the INVITE originated by the CF AS that was received by the NBCS AS (only
the public user identity, not the tag)

• To header field copied from the INVITE originated by the CF AS that was received by the NBCS AS (only the
public user identity, not the tag)
• no SDP (i.e., this is an offer-less INVITE)
The terminating S-CSCF does not apply the terminating service logic for the terminating UE to this INVITE. As
such this specification notes that the combination of a Join header and Answer-Mode header uniquely identify the
NBCS INVITE within a PacketCable environment and it is recommended that Initial Filter Criteria (iFC) are
designed accordingly.
This new SIP dialog is used to create a mixing resource in the UE which mixes audio between the caller, the UE,
and the VM server. For the remainder of this section, this SIP dialog is referred to as the Mixing dialog.
Upon receipt of the INVITE with Join header and Answer-Mode header and if the phone is on-hook, the UE MUST
take the following actions:
• respond with a 200 OK which includes an SDP offer for the Mixing dialog
• respond with a 200 OK which includes an SDP answer to the SDP offer in the original INVITE if no answer
SDP has yet been provided; otherwise responds with a 200 OK with no SDP.
Upon receipt of the INVITE with Join header and Answer-Mode header and if the phone is off-hook, the UE MUST
take the following actions:
• respond with a 486 Busy for the Mixing dialog
• respond with a 486 Busy for the original INVITE
If the NBCS AS receives a 486 Busy response for the INVITE for the Mixing dialog, the NBCS AS MUST
terminate the NBCS feature and allow the call to continue per the triggered terminating services. For example, if the
NBCS feature is invoked as a result of CFV with a Forward-to address identifying voicemail, and the NBCS AS
received a 486 Busy response for the INVITE for the Mixing dialog, then the terminating services associated with
CFV continue such that the call is routed to voicemail.
Upon receipt of the 200 OK to the original INVITE, the NBCS AS MUST proxy this response as per [PKT 24.229].
Upon receipt of the 200 OK for the Mixing dialog the NBCS AS MUST respond with an ACK which contains an
SDP answer that represents the VM server.
After both the original call dialog and the Mixing dialog are established, the UE MUST take the following actions:
• relay the audio streams between the two dialogs, transcoding if necessary
• allow for the presentation of a mixed version of the received streams of both established dialogs to the
speakerphone on the UE, if available
The UE MUST NOT mix any audio from the called party into either of the audio streams between the two dialogs.
The following paragraphs describe one possible method of joining the VM server into the mixing resource at the
UE.
Upon receipt of the 200 OK for the Mixing dialog, the NBCS AS creates a new SIP dialog to the VM server. This is
done by sending a SIP INVITE with an offer SDP copied from the UE's offer SDP given in the 200 OK to the
INVITE for the dialog with the NBCS AS. This allows the VM server to send RTP directly to the UE.
Upon receipt of the 200 OK to the INVITE to the VM server, the NBCS AS performs the following actions:
• send a SIP ACK to the VM server to acknowledge the 200 OK
• send a SIP ACK to the UE with the SDP answer received from the 200 OK to the INVITE sent to the VM
server and follow all applicable procedures as per [PKT 24.229] for completing a SIP dialog.
At this point the NBCS feature is established and the called party starts hearing the VM server prompts as well as
the message being left by the calling party.
If the called party wishes to answer the call, the following requirements apply.

Upon indication that the called party wishes to answer the call after active setup of the NBCS sessions (that is after
the mixer has been established and audio is being relayed) then the UE MUST terminate the Mixing dialog by
sending a SIP BYE request over that dialog. Upon receipt of a BYE request from the UE over the Mixing dialog, the
NBCS AS terminates the VM SIP dialog by sending a SIP BYE request over that dialog.
If the INVITE for the mixing dialog is subsequently received the UE MUST respond to the mixing dialog INVITE
with a 486 Busy response. Upon indication that the called party wishes to answer the call while the NBCS
procedures are being invoked (that is at any point after the original INVITE and prior to rendering of audio) then the
UE MUST respond to the original INVITE with a 200 OK which includes an SDP answer to the SDP offer in the
original INVITE if no answer SDP has yet been provided; otherwise the UE responds with a 200 OK with no SDP
If the called party does not answer the call and the caller hangs up, the following requirements apply. Upon receipt
of a BYE request from the caller, the UE MUST terminate the Mixing dialog by sending a BYE request over that
dialog. Upon receipt of a BYE request from the UE over the Mixing dialog, the NBCS AS terminates the VM
server SIP dialog by sending a SIP BYE request over that dialog.
If the call is not answered and the VM server hangs up for any reason during the execution of the NBCS feature, the
following requirements apply. One scenario when this could happen is if the message it too long and the VM server
is not able to handle it. Upon receipt of a BYE request from the VM server, the NBCS AS terminates the Mixing
dialog by sending a BYE request over that dialog. Upon receipt of a BYE request over the Mixing dialog, the UE
MUST terminate the original call by sending a SIP BYE request over that dialog.
The NBCS Feature Execution described above assumes that there is only one registered instance of the NBCS user.
The case where there are multiple registered instances of the NBCS user is not explicitly addressed by this
specification. However, implementations should ensure that the NBCS feature works in a deterministic manner
when there are multiple registered instances of the NBCS user. For example, in the case where there are multiple
registered instances, the NBCS AS could offer the feature to one of the registered instances following the procedures
described above, and using the GRUU of the target registered instance. The NBCS AS could select the registered
instance based on some criteria such as data configured locally in the AS, the registered contact q-value, or the
supported capabilities advertised by the registered UE (e.g., UE supports auto-answer).

Table 47 summarizes the feature data items that are defined in support of the NBCS feature.
Table 47 - Network-Based Call Screening Feature Data


NBCS has no interactions with calls originated from a public identity with network-based call screening activated.
Call Forwarding Don't Answer (CFDA)
When the Forward-to address for the CFDA feature is the voicemail server, NBCS is activated upon CFDA timer
expiration. Otherwise CFDA takes precedence over NBCS.
Call Forwarding on Busy (CFBL)
Call Forwarding on Busy takes precedence over NBCS. The NBCS feature is not triggered even if the CFBL feature
is configured to go to voice mail.
Do Not Disturb
Do Not Disturb takes precedence over NBCS. When DND feature is active, the NBCS feature is not triggered.

Call Forwarding Variable (CFV)

When the Forward-to address for the CFV feature is the voicemail server, NBCS takes precedence. Otherwise, CFV
takes precedence over NBCS.
Selective Call Forwarding (SCF)
When the Forward-to address for the SCF feature is the voicemail server, NBCS takes precedence. Otherwise, SCF
takes precedence over NBCS.
7.6.8.6 Call Flows

then the text requirements take precedence. Figure 66 illustrates the call flow for the CFDA scenario where the
calling party (A) leaves a message for the called party (B) who is subscribed to the NBCS feature. The called party
(B) goes off hook to answer the call upon hearing the message.
The VM Server is not defined as a component in the PacketCable architecture, so the interaction between the NBCS
AS and the Voice Mail Server in Figure 66 is to be viewed as an illustrative example.

Phone UE PacketCable NBCS UE Phone

CF AS VM Server
“A” “A” Network AS “B” “B”
INVITE(vms)
INVITE(vms)
INVITE(original)
INVITE (original)
Alert=silence
SDP “A”
180 Ringing
180 Ringing
INVITE (Mixing dialog)
No SDP
INVITE (Mixing dialog)
No SDP
200 OK (Mixing dialog)
Mixing Offer SDP
200 OK (Mixing dialog)
Mixing Offer SDP
INVITE (VM dialog)
Mixing Offer SDP
INVITE (VM dialog)
Mixing Offer SDP
200 OK (VM dialog)
Mixing Answer SDP
200 OK (VM dialog)
Mixing Answer SDP
ACK (VM dialog)
ACK (VM dialog)
ACK (Mixing Dialog)
Mixing Answer SDP
ACK (Mixing Dialog)
Mixing Answer SDP
200 OK (original)
SDP “B” Mixer
200 OK
200 OK (vms)
SDP “B” Mixer
200 OK (vms)
200 OK (vms)
SDP “B” Mixer
200 OK (vms)
SDP “B” Mixer
ACK
ACK
RTP audio
RTP audio
Offhook
BYE/200 OK Mixing Dialog
BYE/200 OK Mixing Dialog
BYE/200 OK VM Dialog
BYE/200 OK VM Dialog
Figure 66 - A leaves message while B screens call

7.6.9 Hotline

The Hotline feature allows a call to be made to a pre-configured destination address when the phone goes off hook,
without any intervention from the user. Such a hotline call can be made immediately upon offhook or after an
appropriate delay time, depending on the operator configuration.
This feature may be used by the operator to fulfill a legal requirement to assist a law enforcement agency (LEA)
during a hostage situation. In this case, the hotline call is made to an LEA-provided destination address. Another
usage of this feature is for the public phones in lobbies or airports. Other usages of this feature may also be possible.

The Hotline feature is provisioned for the UE by the operator via the feature data Feature Availability Status
(Table 48). If this data is set to 'true', the feature is available to the UE; otherwise, it is not available for the UE.
With the feature available to the UE, the operator can also configure the dynamic activation status via the feature
data Feature Activation Status (Table 48). If this data is set to 'true', the feature is activated for the UE; otherwise, it
is not activated.

If the Hotline feature is activated and the value of the feature data Hotline Offhook Timer is not "0", the UE MUST
start the Hotline Offhook Timer upon detection of offhook status. Before this timer expires, if the UE detects the
onhook status or any user digit input, the UE MUST reset the timer and follow the usual call origination processing.
If this timer expires, the UE MUST start the call origination by sending an INVITE to the network using the feature
data Hotline Destination Address (Table 48) as the request URI. If the Hotline Destination Address is not
configured, the UE MUST generate an appropriate warning tone to the subscriber.
If the Hotline feature is activated and the value of the feature data Hotline Offhook Timer is "0", the UE MUST
immediately start the call origination upon detection of offhook status by sending an INVITE using the feature data
Hotline Destination Address (Table 48) as the request URI. If the Hotline Destination Address is not configured, the
UE MUST generate an appropriate warning tone to the subscriber.
If the Hotline feature is not available or not activated, the UE MUST perform the usual call origination processing
upon detection of offhook status.

Table 48 summarizes the feature data items that are defined for the implementation of the Hotline feature.
Table 48 - Hotline Feature Data

by Requirement
Default: false
Feature Activation Status Boolean Per public user ID Config.Server Config.Server UE Mandatory
Default: false
Hotline Destination Address SIP or TEL URI Per public user ID Config.Server Config.Server UE Mandatory
Hotline Offhook Timer Integer (seconds) Per public user ID Config.Server Config.Server UE Mandatory
Default: 0

Upon determining that a Hotline call has been placed (see Section 7.6.9), the UE involved in the Hotline call
conforms to a number of specific feature interaction requirements, as defined in this section.

As described in Section 7.6.9.1, the Hotline feature is used to support two general cases:
a) For a line that is dedicated for Hotline service (e.g., public phone in airport or hotel lobby that calls a
dedicated number), or
b) For a line that is temporarily repurposed to provide Hotline service (e.g., Hotline service is temporarily
activated on a residential line to call the LEA during a hostage situation).
For case a), where the line is dedicated to Hotline service, there will be no other features enabled on the line, and
therefore feature interaction is not an issue. However, for case b), a line that is temporarily reprogrammed to
perform hotline service may have any number of other RST features activated. In most cases, these other features
should be disabled as long as the line is provisioned to support Hotline service. For example, all variants of call
forwarding should be disabled, and all multi-party features such as call waiting and hold/conference/transfer should
be disabled. The remainder of this section describes the feature interaction behavior between each RST feature and
Hotline service.
Caller ID Display
No interaction. Feature works as specified. Since Call Waiting calls are blocked when a hotline call is active, no
Caller ID for Call Waiting calls are delivered during hotline calls.
A UE provisioned for Hotline service MUST NOT block Caller ID when a hotline call is made. Essentially, the
provisioned Permanent Presentation Status value is overridden when a hotline call is initiated by the UE, and all
hotline calls are treated as “public”.
No interaction. If the Hotline Offhook Timer is non-zero, and the user dials the Caller ID Per-Call Blocking VSC
before the timer times out, then the Caller ID Per-Call Blocking feature will apply as specified. If the Hotline
Offhook timer value is ‘0’ (in which case the user has no opportunity to enter a Caller ID Per-Call Blocking VSC) or
the Hotline Offhook Timer value is non-zero and the user doesn’t enter the Caller ID Per-Call Blocking VSC, then
the Hotline call will be established normally without invoking the Caller ID Per-Call Blocking feature.
Caller ID Per-Call Delivery
No interaction. If the Hotline Offhook Timer is non-zero, and the user dials the Caller ID Per-Call DeliveryVSC
before the timer times out, then the Caller ID Per-Call Delivery feature will apply as specified. If the Hotline
Offhook timer value is ‘0’ (in which case the user has no opportunity to enter a Caller ID Per-Call Delivery VSC) or
the Hotline Offhook Timer value is non-zero and the user doesn’t enter the Caller ID Per-Call Delivery VSC, then
the Hotline call will be established normally without invoking the Caller ID Per-Call Delivery feature.
No interactions. Feature works as specified. Calls initiated by the LEA are not anonymous, and so will always be
established normally to a line provisioned for Hotline service. Feature interactions between ACR and CW don’t
occur, since Call Waiting calls are always blocked when a Hotline call is active.
The CFV AS MUST disable Call Forwarding Variable for calls terminating to a line that is provisioned for Hotline
service.
Call Forwarding Do Not Answer
The CFDA AS MUST disable Call Forwarding Don’t Answer for calls terminating to a line that is provisioned for
Hotline service.
Call Forwarding Busy Line
The CFBL AS MUST disable Call Forwarding Busy Line for calls terminating to a line that is provisioned for
Hotline service.


The SCF AS MUST disable Selective Call Forwarding for calls terminating to a line that is provisioned for Hotline
service.
Remote Activation of Call Forwarding
No interactions. Feature works as specified.
The OCB AS MUST disable Outbound Call Blocking for hotline calls initiated by a line provisioned for Hotline
service. Outbound Call blocking should operate as specified for regular (non-hotline) calls initiated by a line
provisioned for Hotline service and a non-zero Hotline Offhook Timer value.
Solicitor Blocking
The SB AS MUST disable Solicitor Blocking for calls terminating to a line provisioned for Hotline service.
Collect Call Blocking
900/976 Call Blocking
Call Waiting
A UE provisioned for Hotline service MUST reject all incoming calls received while the UE is busy with an existing
call, by responding to the incoming INVITE request with a 486 Busy Here response. Note; this requirement applies
whether the Hotline UE is busy with an existing hotline or non-hotline call.
Hold
A UE provisioned for Hotline service MUST NOT put a call on hold.
Call Transfer
A UE provisioned for Hotline service MUST NOT transfer a call.
Three Way Calling
A UE provisioned for Hotline service MUST NOT invoke the three-way calling feature.
Do Not Disturb
The DND AS MUST NOT block incoming calls to a line provisioned for Hotline service.
Subscriber Programmable PIN
No interactions. Feature works as specified. The SPP feature can only be used when the Hotline Offhook Timer is
provisioned with a non-zero value. The feature that uses the PIN may be disabled due to feature interactions
specified elsewhere in this section.
Message Waiting Indicators
Speed Dialing
No interactions. Feature works as specified. Speed dial calls can be initiated only if the Hotline Offhook Timer is
provisioned with a non-zero value.

Customer-Originated Call Trace (COT)

No interactions. Feature works as specified. COT can only be used when the Hotline Offhook Timer is provisioned
with a non-zero value.
Screen List Editing (SLE)
No interactions. Feature works as specified. SLE can only be used when the Hotline Offhook Timer is provisioned
with a non-zero value.
Auto Recall
A UE provisioned for Hotline service MUST disable the invocation of the Auto Recall feature.
Auto Callback
A UE provisioned for Hotline service MUST disable the invocation of the Auto Callback feature.
Busy Line Verification
Emergency Interrupt
Call Completion
Emergency Services
No interactions. Feature works as specified. Emergency calls can only be initiated when the Hotline Offhook Timer
is provisioned with a non-zero value.
7.7 Call History Features

7.7.1 Auto Recall

The Automatic Recall (AR) feature allows a UE to automatically return a call to the last calling address (the target
address is the P-Asserted-ID of the caller) that sent an INVITE to this UE, whether the INVITE was answered by
this UE or not. The AR feature should work even when the last call received at the UE did not supply a Caller ID.
Therefore, the AR feature invocation has the following two variations:
1. Non-Anonymous AR: The Caller ID of the last received call at an AR requesting UE is known, and the AR can
be placed at the target address directly by either entering the last Caller ID or pushing a button on the requesting
UE. This case of AR feature invocation does not require the use of an AS and thus becomes of a case of basic
session establishment call.
2. Anonymous AR: This means that the public identity of the last caller is not known to (not supplied at) the AR
requesting UE, the AR feature invocation becomes that of an "Anonymous AR" feature, and involves the
intervention of an AR Application Server(AR AS).
A detailed description of the user interface specified by Telcordia may be found in [GR 227]. This is the desired user
interface for UEs that provides an interface to an analog telephone-like device.
7.7.1.2 Actions Prior to Feature Activation

If the AR feature is available on the UE, it MUST locally store the public identity of the most recent non-emergency
and non-operator caller contained within the P-Asserted-Identity header of the INVITE and the current per-call
presentation status setting, whether the call was answered or not. The UE MAY persistently store this information.
If the most recent non-emergency and non-operator caller was anonymous (either because the caller blocked the

delivery of the identity, or because the identity was unavailable), the UE MUST store the call ID, as presented in the
CallID header, of the anonymous call.
Further, whenever a public identity is subscribed to the AR feature, all anonymous calls placed to the public identity
are sent to an AR Application Server. This allows the AR AS to log the most recently blocked public identity in case
the subscriber requests an AR on the call. The AR AS stores call data for all terminating calls that originate from a
UE who has privacy invoked and for which a 180 ringing was received from the called UE. The AR AS MUST
record both the most recent terminating call that originated from a UE who has privacy invoked, as well as any
additional terminating calls that originated from a UE who has privacy invoked that arrived within the most recent X
minutes, where X is a provisioned timer specified in Table 50. It is recommended that the value of X be set to at
least two minutes.
7.7.1.3 Actions at Feature Activation Time and Deactivation Time

The subscriber can invoke or revoke the AR feature via the telephony user interface (for example, the phone keypad)
by entering the AR activation or deactivation VSCs, respectively. The AR VSCs are defined for the UE in Section
7.1.2 and their usage is described as part of the Digit Map in Section 7.1.1. Upon matching the user-entered digits
with the AR VSC, the UE carries out the AR-ACTIVATE or AR-DEACTIVATE action. If the feature availability
status indicates that the AR feature is not available, then the UE MUST NOT execute the AR feature request.
For feature activation, if the feature availability status indicates that the AR feature is available, then the UE checks
the identity of the most recent caller. If the identity is known to the UE, the UE MUST send an INVITE with the
request URI set to the public identity of the most recent caller, and a Call-Info header declaring
purpose=answer_if_not_busy to the target identity. If the identity is unknown to the UE, the UE MUST send an
INVITE with the request URI containing the AR activation code and the call ID of the most recent call attempt
received by this UE. The UE MUST use the following syntax for a SIP URI that includes a VSC and a call ID:
sip:<input VSC parameter>.<call-id>@<domain>;user=dialstring
where <input VSC parameter> represents the VSC used to invoke AR and is obtained from the input parameter of
AR-ACTIVATE function; <call-id> is the SIP call id of the most recent answered call; and <domain> is the domain
name provisioned to the UE. The following is an example of such a SIP URI:
sip:*69.a84b4c76e66710%40provider.atlanta.com@mydomain.com;user=dialstring
The "@" sign in the call-id in the above example is escaped as "%40" so that the call-id can conform with standard
URI syntax.
Regardless of whether the AR is to an anonymous identity or not, the UE sets the presentation status based on the
stored per-call presentation status and the procedures defined in Table 49. The resulting Presentation Status for the
AR call MUST be used in accordance with the use of the privacy header as specified in Section 7.2.
Table 49 - Effects of Per-Call Presentation Features on Presentation Status for Auto Recall
PPS value for the Per-call Presentation Per-Call presentation Resulting Name and
originating UE (according to feature activated before feature activated before Number Presentation
procedures in Section 7.2) AR Activation AR Reactivation Status
Public None None Public
Anonymous None None Anonymous
Public Caller-ID Per Call Toggle None Anonymous
Anonymous Caller-ID Per Call Toggle None Public
Anonymous/Public CIDS Suppression None Anonymous
Anonymous/Public CIDS Delivery None Public
Anonymous/Public None/Any CIDS Suppression Anonymous
Anonymous/Public None/Any CIDS Delivery Public
Public None/Any Caller-ID Per Call Toggle Anonymous
Anonymous None/Any Caller-ID Per Call Toggle Public

If the UE receives either a 180 Ringing or 200 OK in response to its INVITE, the UE MUST continue with normal
call processing according to Section 7.1. If the target is anonymous, the UE MUST update its outgoing call memory
with the call ID of the call, and the fact that the call is anonymous.
If the UE receives either a 486 Busy Here or 600 Busy Everywhere in response to its INVITE, the UE MUST follow
the procedures described in Section 7.7.1.4.
The AR procedure re-starts for each new INVITE attempt against a new target.
For all other responses the UE MUST fail the AR request by playing an error announcement according to the
procedures specified in Section 7.1.6.
Upon receipt of an INVITE identifying the AR feature, the AR AS searches its network-based call logs to discover
the identity of the anonymous caller identified in the request URI. If the AR AS is not able to find the identity of the
caller matching the call ID provided by the requester, the AR AS MUST fail the AR request by playing an error
announcement to the requester according to the procedures specified in Section 7.1.6. If the AR AS does find the
identity of the caller matching the call ID provided by the requester, the AR AS MUST replace the request-URI in
the INVITE with the target identity, include a Call-Info header declaring purpose=answer_if_not_busy, add itself to
the record-route header, and forward the INVITE.
An in-progress AR feature activation process will be terminated upon expiration of its provisioned "AR Feature
Timer" specified in Table 50, Section 7.7.1.11. However, before the AR Feature Timer expires and before the UE
receives a NOTIFY indicating the idle state for the target UE, it is possible to deactivate the AR feature by the user
entering the AR deactivation code. When the user goes off-hook and enters the AR deactivation VSC, the requesting
UE MUST perform the following procedure depending on whether the AR target UE address is public or
anonymous:
1. When the target UE address is public, the requesting UE sends a SUBSCRIBE message with Expires Header =
0 to the target UE, which cancels the subscription.
2. When the target UE address is anonymous, the requesting UE sends an INVITE message with request URI
containing the AR deactivation VSC and the call ID to the AR AS with the format sip:<VSC>.<call-
id>@<domain>;user=dialstring. Upon receiving this deactivation INVITE message, the AR AS identifies the
most recent AR call activation request and sends a SUBSCRIBE message with Expires Header = 0 to the target
UE, which cancels the subscription.
For the case when the AR Feature Timer has already expired or the requesting UE has already received the
NOTIFY message indicating the idle state for the target UE, the AR feature deactivation is not applicable since the
AR feature execution has been completed successfully as per Section 7.7.1.7. If the user tries to deactivate the
feature in such a case, the UE MUST NOT send the INVITE to the AS for the deactivation. In this case, the UE
MUST play an error tone or appropriate announcement to the user.
7.7.1.4 SUBSCRIBE Procedures

The UE requesting AR subscribes to the target UEs dialog state using the following procedures. The UE MUST
send a SUBSCRIBE to the target UE subscribing to the target's dialog event package. The UE MUST set the
SUBSCRIBE duration to a value provisioned in the UE (AR Feature timer in Table 50), and construct the request
URI using the rules as described in Section 7.7.1.3 for the INVITE request.
If the target UE responds to the SUBSCRIBE with an initial NOTIFY (in addition to a 200 OK to the
SUBSCRIBE), the requesting UE MUST play a delayed processing announcement (either a voice or tone
announcement) according to the procedures in Section 7.1.6. If the initial NOTIFY indicates the target UE is idle,
then as soon as the requesting user hangs up, the requesting UE MUST invoke the procedure in Section 7.7.1.7.
If the target UE rejects the SUBSCRIBE message from the requesting UE, then the Requesting UE MUST fail the
AR request by playing an error announcement (either a voice or tone announcement) according to the procedures in
Section 7.1.6.
Upon receipt of a SUBSCRIBE identifying the AR feature, the AR AS searches its network-based call logs to
discover the identity of the anonymous caller identified in the request URI. If the AR AS is not able to find the
identity of the caller matching the call ID provided by the requester, the AR AS MUST fail the AR request by
playing an error announcement to the requester according to the procedures specified in Section 7.1.6. If the AR AS

does find the identity of the caller matching the call ID provided by the requester, the AR AS MUST replace the
request-URI in the SUBSCRIBE with the target identity, add itself to the record-route header, and forward the
SUBSCRIBE.
If the target UE rejects the SUBSCRIBE message from the AR AS, then the AR AS MUST fail the AR
SUBSCRIBE request by either returning a received response code to the requesting UE, or by playing an error
announcement to the caller according to the procedures specified in Section 7.1.6.
If the target is anonymous, the NOTIFY sent as an initial response to the SUBSCRIBE is delivered to the AS that
inserted the identity of the anonymous caller on the requester's behalf. When the AS receives the NOTIFY, the AS
MUST replace all URIs identifying the target UE with the URI that the requesting UE used in its SUBSCRIBE
message, and proxy the NOTIFY to the requesting UE.
7.7.1.5 Actions at Feature Activation Time at the Terminating AS

If a terminating AS receives an inbound INVITE with a Call-Info header declaring purpose= answer_if_not_busy,
then the terminating AS MUST ignore any active CFBL service for the target public identity, not forward the call if
the target is busy, and instead, deliver the INVITE to the target UE for normal AR processing. If a terminating AS
receives an inbound INVITE with a Call-Info header declaring purpose= answer_if_not_busy, and if the target has
CFV, SCF (where the calling party is on the SCF screening list), DND, or Solicitor Blocking (where the calling
party is not on the solicitor blocking white list) active, the terminating AS MUST reject the INVITE with a 480
Temporarily Unavailable.
7.7.1.6 Actions at the AR Target UE

If the target UE receives the SUBSCRIBE while not already having the maximum number of subscriptions in
progress, it MUST respond with a 200 OK response for the SUBSCRIBE and send a NOTIFY including its current
busy/idle status. The target UE SHOULD NOT include dialog IDs or identities of the participating parties in the
dialogs in the NOTIFY.
The target UE is provisioned with a maximum number of simultaneous SUBSCRIBEs that it will honor via the Max
Simultaneous Subscriptions parameter. If the target UE receives a SUBSCRIBE message when the maximum
number of subscriptions are already in progress, then the UE MUST reject the new SUBSCRIBE request with a 480
Temporarily Unavailable response code. The target UE MUST send an additional NOTIFY to the subscribing UE
whenever there is a change in the dialog state of the UE, and the active dialog is ended.
7.7.1.7 NOTIFY Processing Procedures

It is often the case that, before the provisionable AR feature timer expires, the requesting UE receives a NOTIFY
from the target UE indicating the target is not engaged in any dialogs. In such cases, as soon as the requesting UE is
also idle, it MUST apply a special ringing as defined in [GR 227] at the local analog telephone. If the phone is
answered, then the requesting UE terminates the subscription by sending a SUBSCRIBE with a value of zero in the
Expires header and sends an INVITE to the target UE per the procedures in Section 7.7.1.3. Upon receiving this
SUBSCRIBE, the notifier sends a 200 OK response and a NOTIFY with a Subscription-State header value of
"terminated."
If the local user does not answer the phone when special ringing is applied within the AR Special Ringing Duration
time, the requesting UE MUST continue its subscription to the target UE for the remaining time on the AR duration
timer. If the requesting UE receives another response indicating the target UE is still idle, it MUST wait a
provisionable time period (AR Special Ringing Retry Wait Interval in Table 50) and apply special ringing again.
This cycle is repeated until either the requesting local user answers the phone or the AR duration timer expires.
The requesting UE MUST repeat this process until either the special ringing phone is answered, the AR timer
expires, or the AR Special Ringing Retries is reached, whichever comes first, after which the AR feature is
complete and the UE MUST terminate any existing subscription to the target's dialog event package by sending a
SUBSCRIBE with a value of zero in the Expires header.
Upon receiving this SUBSCRIBE, the notifier sends a 200 OK response and a NOTIFY with the Subscription-State
header value of "terminated."

When special ringing is applied at the requesting UE, and the requesting UE has the Caller ID display capability
activated, the requesting UE MUST provide the target's Caller ID if available.
In the case where the AR target is anonymous and the UE's SUBSCRIBE request is routed to an AR AS, then the
AR AS is the entity receiving the NOTIFY from the target UE indicating the target is not engaged in any dialogs.
When the AR AS receives this NOTIFY message, the AR AS MUST send a NOTIFY to the requesting UE, as if it
were from the target originally specified by the requesting UE in its initial subscription. The NOTIFY MUST be
sent with the From header set to the request URI received in the SUBSCRIBE. If there is a P-Asserted-Identity and
a no privacy header with privacy=id in the NOTIFY, then the AS MUST remove the P-Asserted-Identity from the
proxied NOTIFY message.
7.7.1.8 Other Scenarios and Issues

If the requesting UE receives an error response to its SUBSCRIBE message, it MUST provide an error indication to
the requesting UE's user, either through a locally-stored announcement or tone, or through a streamed announcement
played from a network resource, as defined in Section 7.1.6.
When a user dials the AR activation code again after the AR feature has already been activated on the local UE, if
the new AR activation request is associated with the same target as the previously activated AR request, and if the
previous AR request timer has not yet expired, then the UE MUST send a new SUBSCRIBE message to the target
UE, with a subscription duration set to the full AR duration value provisioned in the requesting UE. This has the
effect of resetting the AR request timer to the maximum feature request duration.
When a user dials the AR activation code again after the AR feature has already been activated on the local UE, if
the new AR activation request is associated with a different target from the previously activated AR request, and if
there are not already a number of simultaneous subscriptions outstanding equal to the Max Subscribes allowed from
this public identity, then the requesting UE MUST execute the AR procedure described Section 7.7.1.3 for the new
target.
If a target UE receives multiple subscriptions to its dialog event package, implying that multiple remote UEs are
requesting AR or Auto Callback service targeting this UE, then there is no requirement for the UE to NOTIFY the
subscribers in order of subscription (no subscription needs to have priority over another). The order in which a UE
honors subscriptions is subject to implementer discretion.
7.7.1.9 Actions Required when a UE Requests Auto Recall to a PSTN Target

When the target of an AR request is on the PSTN, the requesting UE is not aware of the network that the target
resides on, so the actions of the requesting UE are identical whether the target UE is in a PacketCable network or is
the PSTN.
If the AR target is on the PSTN, then the initial INVITE sent by the requesting UE (in response to the requesting
user dialing the AR invocation code) is forwarded to an MGC according to normal IMS routing procedures. The
MGC requirements and procedures (including SIP to ISUP interworking) for support of Auto Recall are specified in
[CMSS1.5].
7.7.1.10 Actions Required for a PSTN Endpoint Requesting Auto Recall to a UE Target
When a PSTN-based endpoint requests Auto Recall on a UE target, the PacketCable network receives a TCAP
Network-Ring-Again request at an MGC, indicating the telephone number of the UE targeted for AR. The MGC
requirements and procedures (including SIP to ISUP interworking) for support of Auto Recall are specified in
[CMSS1.5].


Table 50 summarizes the feature data defined to support implementation of Auto Recall feature.
Table 50 - Auto Recall Feature Data
Requirement
Feature Availability Boolean Per public user Config.Server Config.Server UE, AS Mandatory
Status ID
AR Feature Timer Integer (seconds of feature Per public user Config.Server Config.Server UE Mandatory
duration, 0 to1800 seconds, ID
default is 1800 seconds)
AR Special Ringing Integer (number of special Per public user Config.Server Config.Server UE Mandatory
Duration ringing ring cycles) ID
AR Special Ringing Integer (number of seconds Per public user Config.Server Config.Server UE Mandatory
Retry Wait Interval to wait between attempts to ID
alert the user with special
ringing)
AR Special Ringing Integer (number of times to Per public user Config.Server Config.Server UE Mandatory
Retries retry special ringing before ID
canceling the AR request)
Max Simultaneous Integer (max number of Per public user Config.Server Config.Server UE Mandatory
SUBSCRIBEs simultaneous subscribes the ID
UE should send)
Max Simultaneous Integer (max number of Per public user Config.Server Config.Server UE Mandatory
Subscriptions simultaneous subscriptions ID
the UE should honor)
AR Timer (X) Integer (minutes, min 2 min) Per public User AS AS AS None
ID

The feature interactions of Auto Recall feature are specified in [GR 227].
When AR is used with the CNAM feature, the called station's name need not be delivered to the customer when
special ringing is applied. This differs from the requirements of [GR 227].
Speed Dialing
Programming the AR activation code as a speed dial number won't invoke the AR feature correctly.
Call Forwarding Busy
An AR Request to a target with CFB activated is not allowed to be forwarded.
Do Not Disturb
An AR Request to a target that has Do Not Disturb enabled is rejected with a 480 Temporarily Failure unless the
requester is on the Do Not Disturb white list.
An AR Request to a target that has Selective Call Forwarding enabled is rejected with a 480 Temporarily Failure if
the requester is on the Selective Call Forwarding screening list.
An AR Request to a target that has Call Forwarding Variable enabled is rejected with a 480 Temporarily Failure.

7.7.1.13 Call Flows


Figure 67 illustrates an example call flow for the case where UE A targets non-anonymous target UE B for the Auto
Recall feature.
Originating Terminating
Phone UE PacketCable PacketCable UE Phone
“A” “A” Network Network "B" “B”
VSC
INVITE
Off-hook
Last Caller
INVITE
Last Caller
INVITE
Last Caller
486 Busy
486 Busy
486 Busy
ACK
ACK
SUBSCRIBE
ACK
Dialog Ev Pkg
SUBSCRIBE
Dialog Ev Pkg
SUBSCRIBE
Dialog Ev Pkg
200 OK
SUBSCRIBE
200 OK
SUBSCRIBE
200 OK
NOTIFY Busy
SUBSCRIBE
NOTIFY Busy
NOTIFY Busy
Delayed
processing
annc 200 OK
NOTIFY
On-hook 200 OK NOTIFY
200 OK
NOTIFY
On-hook
NOTIFY Idle
Cancel Subscribe
NOTIFY Idle
Cancel Subscribe
NOTIFY Idle
Special Cancel Subscribe
Power
Ringing 200 OK
NOTIFY
Off-hook 200 OK NOTIFY
200 OK
INVITE
NOTIFY
INVITE
INVITE
Power
Ringing
180 Ringing
180 Ringing 200 OK
Ringback
200 OK
Tone
200 OK
ACK
ACK
ACK
A-B Connected
Figure 67 - Automatic Recall (AR) - Target not anonymous

Figure 68 illustrates an example call flow for the case where UE A targets anonymous target UE B for the Auto
Recall feature, and UE B is busy.
Originating
AS
VSC
INVITE
Off-hook
VSC.InbdCallID
INVITE
VSC.InbdCallID
INVITE
Last Caller
INVITE Last Caller
INVITE
Last Caller
486 Busy
486 Busy
486 Busy
486 Busy
486 Busy
ACK
ACK
ACK
ACK
SUBSCRIBE
VSC.CallID ACK
Dialog Ev Pkg SUBSCRIBE
VSC.CallID
Dialog Ev Pkg
SUBSCRIBE
Dialog Ev Pkg
SUBSCRIBE Dialog Ev Pkg
SUBSCRIBE
Dialog Ev Pkg
200 OK
SUBSCRIBE
200 OK SUBSCRIBE
200 OK
SUBSCRIBE
200 OK
SUBSCRIBE
200 OK
NOTIFY Busy
SUBSCRIBE
NOTIFY Busy
NOTIFY Busy
NOTIFY Busy
NOTIFY Busy
Delayed
processing
annc
200 OK NOTIFY
On-hook 200 OK NOTIFY
200 OK NOTIFY
200 OK NOTIFY
200 OK NOTIFY
Figure 68 - AR - Anonymous target is busy

Figure 69 illustrates an example call flow for the case where the anonymous target becomes available.
Originating
AS
On-hook
NOTIFY Idle
Cancel Subscribe
NOTIFY Idle; Cancel Subscribe
NOTIFY Idle
Cancel Subscribe
NOTIFY Idle
NOTIFY Idle Cancel Subscribe
Special Cancel Subscribe
Power
Ringing
200 OK NOTIFY
200 OK NOTIFY
200 OK NOTIFY
Off-hook 200 OK NOTIFY

INVITE
200 OK NOTIFY
VSC.CallID
INVITE
VSC.CallID
INVITE B
INVITE B
INVITE B
Power
Ringing
180 Ringing
180 Ringing
180 Ringing
180 Ringing 200 OK

Ringback
200 OK
Tone
200 OK
200 OK
200 OK
ACK
ACK
ACK
ACK
ACK
A-B Connected
Figure 69 - AR - Anonymous target becomes idle

7.7.2 Auto Callback

The Automatic Callback (AC) feature allows a UE to automatically call back the last called address to which the last
INVITE was sent from this UE, whether the INVITE was answered by the called party or not. The AC feature
should work even when the last call made from the UE did not supply a called ID. Therefore, the AC feature
invocation has the following two variations:
1. Non-Anonymous AC: The called ID of the last sent call from an AC requesting UE is known, and the AC call
can be placed at the target address directly by either entering the last called party's public ID or pushing a button
on the requesting UE. This case of AC feature invocation does not require the use of an application server (AS)
and thus becomes a case of a basic session establishment call.
2. Anonymous AC: The called ID of the last sent call from an AC requesting UE is not known. This happens
when the last call from the AC requesting UE is an anonymous Auto-Recall (AR) call. In this case, the AC
feature invocation becomes that of an "Anonymous AC" feature and involves the intervention of an AC AS.
A detailed description of the user interface specified by Telcordia may be found in [GR 215]. This is the desired user
interface for UEs that provides an analog interface to an analog telephone-like device.
7.7.2.2 Actions Prior to Feature Activation

Whenever the UE has been configured to provide the AC feature, the UE MUST locally store the address of the
most recent non-emergency and non-operator called party, along with the caller's per-call presentation features (see
Section 7.2) used at the time of the call, whether the call is answered or not. The UE MAY persistently store this
information.
If the most recently called party is the target of an anonymous Auto Recall request, then the most recently called
party for the AC feature is anonymous. In such a case, the UE should locally store the fact that the most recently
called party was anonymous, along with the call ID of the anonymous call.
7.7.2.3 Actions at Feature Activation and Deactivation Time

Similar to the AR feature, the user may invoke or revoke the AC feature via the telephony user interface by entering
the AC activation or deactivation VSCs. These AC VSCs are defined for the UE in Section 7.1.2 and their usage is
described as part of Digit Map in Section 7.1.1. Upon user's entering the AC VSC, the requesting UE performs its
digit analysis, matches the user-entered digits with the AC VSC, and carries out either the AC-ACTIVATE or AC-
DEACTIVATE action. If the feature availability status indicates that the AC feature is not available, then the UE
MUST NOT execute the AC feature request.
Upon activation of the AC feature, the UE checks the identity of the most recent callee, and if that identity is known
to the UE and permitted for the UE to call, the UE MUST send an INVITE with a Call-Info header declaring
purpose=answer_if_not_busy to the target identity and the request URI identifying the target UE.
If the target identity is not known, the UE MUST send an INVITE with the request URI containing the AC
activation code and the call ID of the most recent call attempt originated by this UE. The UE MUST use the
following syntax for a SIP URI that includes a VSC and a call ID:
sip:<input VSC parameter>.<call-id>@<domain>;user=dialstring
where <input VSC parameter> represents the VSC used to invoke AC and is obtained from the input parameter of
AC-ACTIVATE function; <call-id> is the SIP call id of the most recent call attempt; and <domain> is the domain
name provisioned to the UE. The following is an example of such a SIP URI:
sip:*66.a84b4c76e66710%40provider.atlanta.com@mydomain.com;user=dialstring
The "@" sign in the call-id in the above example is escaped as "%40" so that the call-id can conform with standard
URI syntax.

Regardless of whether the AC feature call is to an anonymous target UE or not, the UE sets the presentation status
based on the stored per-call presentation status and the procedures defined in Table 51. The resulting Presentation
Status for the AC call MUST be used in accordance with the use of the privacy header as specified in Section 7.2.
Table 51 - Effects of Per-Call Presentation Features on Presentation Status for Auto Callback
PPS value for the originating Per-call Presentation Per-Call presentation Resulting Name and
UE (according to procedures feature activated before feature activated before Number Presentation
in Section 7.2) AC Activation AC Reactivation Status
Public None None Public
Anonymous None None Anonymous
Anonymous/Public CIDS Suppression None Anonymous
Public Caller-ID Per Call Toggle None Anonymous
Anonymous Caller-ID Per Call Toggle None Public
Anonymous/Public CIDS Delivery None Public
Anonymous/Public None/Any CIDS Suppression Anonymous
Anonymous/Public None/Any CIDS Delivery Public
Public None/Any Caller-ID Per Call Toggle Anonymous
Anonymous None/Any Caller-ID Per Call Toggle Public
If the UE receives either a 180 Ringing or a 200 OK in response to its INVITE, the UE MUST continue with normal
call processing according to Section 7.1. If the target is anonymous, the UE MUST update its outgoing call memory
with the call ID of the call, and the fact that the call was anonymous.
If the UE receives either a 486 Busy Here or 600 Busy Everywhere in response to its INVITE, the UE MUST follow
the SUBSCRIBE procedure described in Section 7.7.1.4.
If the UE receives either a 415 Unsupported Media Type or 420 Unsupported Extension, the UE MUST follow the
procedures in [RFC 3261] to attempt to complete the INVITE.
If the UE receives either a 300 Multiple Choices, 301 Moved Permanently, or 302 Moved Temporarily, the UE
SHOULD retry one or more addresses according to [RFC 3261]. The AC procedure re-starts for each new INVITE
attempt against a new target.
For all other responses the UE MUST fail the AC request by playing an error announcement according to the
procedures specified in Section 7.1.6.
Upon receipt of an INVITE identifying the AC feature, the AC AS searches its network-based call logs to discover
the identity of the anonymous last called party identified in the request URI. If the AC AS is not able to find the
identity of the called party matching the call ID provided by the requesting UE, the AC AS MUST fail the AC
request by playing an error announcement to the requesting UE according to the procedures specified in Section
7.1.6. If the AC AS does find the identity of the called matching the call ID provided by the requester, the AC AS
MUST replace the request-URI in the INVITE with the target identity, include a Call-Info header declaring
purpose=answer_if_not_busy, add itself to the record-route header, and forward the INVITE.
An in-progress AC feature activation will be terminated upon expiration of its provisioned "AC Feature Timer"
specified in Table 52, [Section 7.7.2.11]. However, before the AC Feature Timer expires, it is possible to deactivate
the AC feature by the user entering the AC deactivation code. The procedure for AC deactivation is the same as the
procedure described for AR deactivation in Section 7.7.1.3.
7.7.2.4 SUBSCRIBE Procedures

The AC AS MUST implement the requirements defined in Section 7.7.1.4.
The UE requesting AC MUST implement the requirements defined in Section 7.7.1.4.
7.7.2.5 Actions at Feature Activation Time at the Terminating AS


7.7.2.6 Actions at the AC Target UE

The target UE MUST implement the requirements defined in Section 7.7.1.6.
7.7.2.7 NOTIFY Processing Procedure

7.7.2.8 Other Scenarios and Issues

7.7.2.9 Actions Required when a UE Requests Auto Callback to a PSTN Target

The MGC requirements and procedures (including SIP to ISUP interworking) for support of Auto Callback are
7.7.2.10 Actions Required for a PSTN Endpoint Requesting Auto callback to a UE Target
The MGC requirements and procedures (including SIP to ISUP interworking) for support of Auto Callback are

Table 52 summarizes the feature data that are defined to support implementation of the Auto Callback feature.
Table 52 - Auto Callback Feature Data

Requirement
Feature Availability Boolean Per public Config.Server Config.Server UE, AS Mandatory
Status user ID
AC Feature Timer Integer (seconds of feature Per public Config.Server Config.Server UE Mandatory
duration, 0 to1800 seconds, user ID
default is1800 seconds)
AC Special Ringing Integer (number of special Per public Config.Server Config.Server UE Mandatory
Duration ringing ring cycles) user ID
AC Special Ringing Integer (number of seconds to Per public Config.Server Config.Server UE Mandatory
Retry Wait Interval wait between attempts to alert user ID
the user with special ringing)
AC Special Ringing Integer (number of times to Per public Config.Server Config.Server UE Mandatory
Retries retry special ringing before user ID
canceling the AR request)
Max Simultaneous Integer (max number of Per public Config.Server Config.Server UE Mandatory
SUBSCRIBEs simultaneous subscribes the user ID
UE should send)
Max Simultaneous Integer (max number of Per public Config.Server Config.Server UE Mandatory
Subscriptions simultaneous subscriptions the user ID
UE should honor)
AC Timer (X) Integer (minutes, min 2 min) Per public AS AS AS None
User ID


The feature interactions are specified in [GR 215].
When AC is used with the CNAM feature, the called station's name need not be delivered to the customer when
special ringing is applied. This differs from the requirements of [GR 215].
Speed Dialing
Programming the AC activation code as a speed dial number won't invoke the AC feature correctly.
Call Forwarding Busy
An AC Request to a target with CFB activated is not allowed to be forwarded.
Do Not Disturb
An AC Request to a target that has Do Not Disturb enabled is rejected with a 480 Temporary Failure unless the
requester is on the Do Not Disturb white list.
An AC Request to a target that has Selective Call Forwarding enabled is rejected with a 480 Temporary Failure if
the requester is on the Selective Call Forwarding screening list.
An AC Request to a target that has Call Forwarding Variable enabled is rejected with a 480 Temporary Failure.
7.7.2.13 Call Flows

The AC call flows are identical to the AR call flows in Section 7.7.1.13 with the following exceptions. The public
identity of the last callee (instead of the caller) is used by the initiating UE for a non-anonymous call. The call id of
the last outbound call (instead of the last inbound call) is used by the initiating UE for an anonymous call.
7.8 Operator Services

PacketCable Residential SIP Telephony services require an operator services platform to be able to verify that a line
is busy and to interrupt a call in progress. The operator services platform may or may not use UEs for its operator
stations, and therefore, may be using traditional circuit switched components, so the specification for operator
services functions provides options for interoperating with a circuit switched operator services platform.
In Busy Line Verification Service (BLV), a user calls an operator services position by dialing 0 or 0+[NPA] NXX-
NXXX to determine if a line is in use. In Emergency Interrupt Service (EI), the operator provides a Busy Line
Verify Service, then interrupts the call in progress, and relays a message from the requester of the interrupt to the
interrupted party. If the interrupted party is willing to hang up, the call can then be placed by the caller to the called
party. If the caller requests the feature from the operator, the connection between the caller and the interrupted party
can be reinitiated by the operator using the Call Completion Service after the called party hangs up.
A conventional North American telephone environment requires a BLV trunk between the operator services system
and the core telephone system. These trunks typically use Multi-Frequency tone-based signaling.
The Busy Line Verification, Emergency Interrupt, and Call Completion services MUST follow the requirements
specified in [GR 1176] and [GR 531].

7.8.1 Busy Line Verification

From the North American network, requesters access the Busy Line Verification service by dialing 0+[NPA] NXX-
NXXX. [NPA] NXX-NXXX is the line to be verified. This connects the requester to the operator services position.
The requester asks the operator to perform the Busy Line Verification. The line to be verified (the target line) may
be directly accessible by this operator services position. In that case, the operator services position first calls the
target line to verify that it is busy. If the line is not busy (it rings) or if the call cannot be completed due to some non-
busy type of failure returned by call processing signaling, the operator informs the subscriber of the status of the
called line. If the line is busy, the operator position bridges into the target's call in progress and listens to the called
line with automatic scrambling of the called line speech to ensure privacy while the operator listens for
conversation. This scrambling is provided as a local function to the operator services position.
Lines may be provisioned to deny busy line verification. In that case, the operator notifies the requester that busy
line verification is not possible.
In the case where the line is not directly accessible by the operator services position, the line may be indirectly
accessible via another, remote operator services system. In this case, the local operator services position contacts the
remote operator services system and the remote operator services system performs the function. This may be
implemented via a human to human telephone call between operators.
The operator must provide credentials to the network to vouch for its identity.
If the target of a BLV request has more than one UE behind a public identity, and at least one UE is not in use, then
the public identity is not considered busy since the operator cannot verify that the public identity is busy and,
therefore, cannot interrupt the caller.
Information sufficient to bill the requesting party for the use of the BLV service must be collected, either by the
operator services platform or by the PacketCable network, or both.
Busy Line Verification behaves as described in Telcordia LSSGR [GR 1176], but in the context of the PacketCable
architecture. The feature implementation assumes an analog phone connected to a PacketCable-certified UE.

The operator services UE first places a test call to the target UE using basic call procedures as described in Section
7.1 to determine if the target UE is busy. If the target UE is busy, the operator services UE clears the call attempt
using the basic call procedures as described in Section 7.1 and proceeds with the busy line verification procedure as
described below.
After an initial test call has determined that the targeted line is busy, then the operator services position UE sends a
SUBSCRIBE to the targeted public ID dialog event package with an Expires value of zero, which polls the target
public ID's dialogs. The P-Asserted Identity in the SUBSCRIBE message MUST be the reserved operator ID, which
is provisioned on both the operator position and on each subscriber UE via the BLV Operator Identity attribute as
defined in Table 53.
If the Feature Availability Status attribute indicates the BLV feature is disabled, the target UE MUST respond to a
SUBSCRIBE to the dialog event package from the operator BLV UE with a 403 Forbidden.
If the Feature Availability Status attribute indicates the BLV feature is enabled, the target UE MUST respond to a
SUBSCRIBE to the dialog event package from the operator BLV UE with a 200 OK, followed by a NOTIFY
message with a list of established dialogs at the UE. The UE SHOULD list the active dialog first.
Upon receiving the NOTIFY identifying the dialogs, the operator services UE MUST send an INVITE to the target
UE with a JOIN header containing the first dialog ID in the NOTIFY. Upon receipt of the INVITE with a JOIN
header identifying one of the active dialogs, the target UE MUST mix the RTP from the operator BLV UE and all
existing dialogs after verifying that the P-Asserted ID in the INVITE is that of the operator. The mixed audio is sent
to the operator UE. The audio is scrambled at the operator station prior to presentation to the operator.

If the operator determines that there is a call in progress, the operator can interrupt, per Section 7.8.2. If the
requesting party declines the interrupt, or if the operator is incapable of interrupting the call, operator UE MUST
send a BYE to the target public ID.
If the target UE is in a non-idle, non-talking state such as ringing or dialing, the target UE MUST reject the INVITE
with JOIN header with 481 Call/Transaction Does Not Exist. When the operator services UE receives this 481
Call/Transaction Does Not Exist, it MUST play the reorder tone to the operator position.
If the target public identity no longer has an active dialog as indicated in the JOIN header within the INVITE, then
the UE MUST respond to the INVITE with a 481 Call/Transaction Does Not Exist. If the target fails the JOIN
request for any other reason, the UE SHOULD return a 488 Not Acceptable. If the JOIN request fails for any
reason, the operator services UE MAY attempt an INVITE with a JOIN header identifying the next dialog ID on the
list of dialog IDs in the original NOTIFY. If none of the JOIN attempts succeeds, the operator UE MUST play
reorder tone to the operator.
If the NOTIFY did not indicate at least one active dialog, the operator services UE MUST send an INVITE without
a JOIN header to the public identity of the target UE. If CFV is active at the public identity, the target UE MUST
respond with a 486 Busy. If the public identity is idle without CFV active, the target UE MUST respond with 180
Ringing, and the operator UE MUST alert the operator with a ringback tone.
To minimize audio disruption in the call being verified, the UE SHOULD use the mixing services local to that UE
rather than a network-based conference service. Wherever possible, the UE SHOULD avoid doing a reINVITE to
other parties in the call to minimize audio disruption. A UE MAY reject an INVITE with JOIN header if it is
already in a 3-way conference.
If the UE knows that it is in a TDD, FAX, or Modem call, the UE MUST answer the SDP with a=recvonly. The
TDD, FAX, or Modem call between the users MUST NOT be disturbed because of BLV or Operator Interrupt.
An operator service uses a special trusted identity which is only allowed to be used for Busy Line Verification and
Operator Interrupt. For security reasons, this identity MUST NOT be used by any UE other than the operator
services UE. The UE MUST accept INVITEs with the JOIN header that uses this special identity unless specified
otherwise in this section.
For a legacy based service, the operator service position attaches to the PacketCable network using a dedicated trunk
circuit, called a No Test Trunk, which is attached to a Media Gateway. In this case, the MGC plays the role of the
operator position UE as specified herein. See PacketCable [CMSS1.5] and [TGCP1.5] specifications for further
information on how the MGC incorporates Busy Line Verification and Operator Interrupt related requirements.
If the target UE goes on-hook, the target UE MUST drop the BLV session by sending a BYE.

Table 53 summarizes the feature data defined to support the implementation of the Busy Line Verify feature.
Table 53 - Busy Line Verify Feature Data

Feature Availability Boolean Per public Config.Server Config.Server UE Mandatory
Status user ID
BLV Operator Identity String network Config.Server Config.Server UE, HSS, P-CSCSF, S- Mandatory
(Note 1) CSCF MGC, Operator UE
Note 1: It is recommended that this data element be stored in a secure manner on the customer UE (with limited access).


Switch-hook flash is disabled in the target UE while the Busy Line Verification procedure is active.
If the target UE has enabled Call Forward Variable to forward all calls, the Call Forwarding AS MUST return 486
Busy in response to the INVITE with JOIN header from the operator services UE. If the operator services UE
receives 486 Busy as a response to an INVITE, the operator services UE MUST play the busy tone to the operator.
Do Not Disturb
If the target UE has enabled DND, the DND AS MUST forward operator interrupt and BLV attempts to the UE.
7.8.1.5 Call Flows

Figure 70 shows an example call flow for Busy Line Verification.
Dedicated PacketCable
MG/MGC UE Phone UE Phone
CAS Trunk Network
“A” “A” “B” “B”
Seize
Active Call
MF digits SUBSCRIBE
ID=”Operator”
expires=0 SUBSCRIBE
ID=”Operator”
expires=0
200 OK
SUBSCRIBE
200 OK
SUBSCRIBE
NOTIFY
NOTIFY Dialog ID
Dialog ID
200 OK
NOTIFY
200 OK NOTIFY
INVITE
ID=”Operator”
Join:(Dialog ID) INVITE
ID=”Operator”
Join:(Dialog ID)
200 OK
200 OK
Answer
ACK
ACK
Operator-A-B Connected
Release
BYE
BYE
200 OK BYE
200 OK BYE
Active Call
Figure 70 - Busy Line Verify (BLV)

7.8.2 Operator Interrupt

Operator Interrupt is performed as a follow-on step after the Busy Line Verification service. The requester asks the
operator to interrupt the call. Operator Interrupt is allowable during the call-processing state (waiting for a call to
complete) and the communications state (talking in a call) as defined in [GR 506]. Lines may be provisioned to deny
Operator Interrupt. This provisioning is done through LIDB and the check of this provisioning is done by the
operator services position. The UE doesn't need to know its provisioning status in this regard. If Operator Interrupt is
provisioned as denied for the line being requested, the operator notifies the requester that Operator Interrupt is not
possible. If the service is allowed, the operator services position removes the scrambler from the line and injects an
intrusion tone such as a 440 Hz Call Interrupt tone into the call and interrupts the called party's conversation. The
cut-through time for this intrusion is limited to 15 seconds. If the called party is willing to establish conversation
with the caller, the called party can hang up to allow the caller to re-originate the call.
If the caller desires Operator Interrupt followed by Call Completion, the operator informs the caller of the verified
line's status and whether the interrupted party is willing to establish conversation. If the interrupted party is willing
to establish conversation, the operator services system then connects the calling and called parties. If the interrupted
party refuses to establish conversation, the call is not completed. With Call Completion, the operator connects the
calling party to the called party directly without routing the call through the operator services platform.
Information sufficient to bill the requesting party for the use of the Operator Interrupt and Call Completion services
must be collected, either by the operator services platform or by the PacketCable network, or both.

Operator Interrupt implementation is identical to Busy Line Verification with the exception that the operator
services position removes the scrambler from the receive path and takes the transmit path off of mute. From the
point of view of PacketCable, the two features are identical.

Feature interactions for Operator Interrupt are identical to Busy Line Verification.
7.8.3 Call Completion

The Call Completion feature allows the operator services position to transfer a call from a requesting UE to a target
UE. In the legacy circuit switched environment, the operator services position may keep the call on a local loop to
monitor the call; or the operator services position may transfer the call using either Release Link Trunk methods for
MF trunks or FACILITIES messages for Primary Rate ISDN or SS#7 signaling arrangements. In the case where the
operator services position keeps the call on a local loop, the cross connect is made locally within the operator
services position, and the PSTN sees two separate phone calls that terminate at the operator services position; one
from the requesting UE to the operator and a second from the operator to the target UE.

The operator services UE MAY keep the call on a local loop connecting the requesting UE to the target UE using
facilities local to the operator services UE. In this case, the operator services UE MUST use basic call procedures,
as described in Section 7.1, to terminate the call from the requesting UE and initiate the second call to the target
UE. The voice path between the two calls MUST be cross connected locally within the operator services UE.
The operator services UE MAY transfer the call to connect the requesting UE to the target UE. When transferring
the call, the operator services UE MUST use the Call Transfer procedures described in Section 7.5.4.
The Operator Services position MAY be a legacy circuit switched service that attaches to the PacketCable network
using a dedicated trunk circuit attached to a Media Gateway. In this case, the Media Gateway Controller MUST
play the role of the operator position UE as specified herein.

8 EMERGENCY SERVICES
This section provides a technical overview and specifies requirements for the support of emergency services in
PacketCable. The requirements are based on the referenced IETF Internet-Drafts and emerging documents from
NENA.
Support for emergency services in a PacketCable network involves multiple network elements, specifically the P-
CSCF, E-CSCF, MGC, SG, and the MG.
8.1 Overview of NENA E9-1-1 VoIP Migration Phases

NENA is an organization which has a mission of fostering the technological advancement, availability, and
implementation of a universal emergency telephone number system (9-1-1) in North America. NENA has created a
VoIP/Packet Technical Committee to define how 9-1-1 calls that originate on a VoIP service provider network
should be handled. This committee has specified an implementation plan in three phases based on interim
architectures:
• i1: NENA i1 documents mechanisms in use today to support 9-1-1 services by some VoIP service providers. It
allows for VoIP 9-1-1 calls to be delivered to the correct PSAP via a PSAP-designated 10-digit number.
• i2: NENA i2 defines a transition mechanism that is roughly based on the cellular 9-1-1 process to allow a VoIP
Service Provider to terminate VoIP calls to a 9-1-1 operator with an automatic location and without requiring
"Public Safety Answering Points" (PSAPs) to upgrade their current systems [NENA i2].
An intermediary phase, termed "Pre i2" has also been introduced. NENA pre-i2 allows that a VoIP 9-1-1 call be
delivered to the correct PSAP via dedicated access to the Selective Router, which then routes the call to the
appropriate PSAP.
• i3: NENA i3 defines a new, all IP-based architecture for PSAPs that allows VoIP emergency calls to be
terminated as VoIP directly at the PSAP (requiring network upgrades for PSAPs) [NENA i3].
This section specifies the technical requirements for the support of NENA's Interim VoIP architectures for Enhanced
9-1-1- Services, i1, Pre i2, i2 [NENA i2], and i3 [NENA i3].
8.2 Scope
The following requirements are considered to be in scope for PacketCable Emergency Services Support:
• Identifying the location of the UE and storage of location information by the UE.
• Identifying emergency calls at the UE and/or CSCF servers.
• Conveying location information in the SIP signaling for emergency calls, following the IETF protocol
mechanisms.
• Special handling of emergency calls, including establishing QoS and priority treatment for emergency call
media and signaling, and special SIP signaling prioritization processing or marking. QoS and priority treatment
are not addressed in this version of the specification.
• Handling of emergency calls at SIP Proxies and other PacketCable routing server functions.
8.3 Assumptions
The following are the assumptions made in support of PacketCable Emergency Services.
• Given the scope of PacketCable, the on-going work in 3GPP IMS on emergency services, and the importance of
E-911 support in VoIP networks, the applicability of the NENA i1, pre-i2, i2, and i3 interim phases for North
America is assumed.
• The use of IETF protocols and methodologies for location determination and conveyance is assumed; and at the
time of this writing, the approach is in line with the work-in-progress in 3GPP.

• On the network side, this specification assumes that location determination on access networks where UEs may
roam is available, including location determination on DOCSIS cable access networks.
• This specification assumes that location information is provided to the UE via DHCP. The mechanisms for
providing location information on DOCSIS access networks may vary and the detection of a location change on
cable networks are out of scope of this specification.
For UEs operating behind local DHCP servers (for example, home routers with NAT capabilities), the location
information DHCP option should be relayed. In the absence of a DHCP relay for the location information, a
dynamic location may not be reliably provided by the UE, and the E-CSCF handles the emergency call without
location and attempts to do a static mapping.
• The UE supports the DHCP protocol and the associated DHCP options for geographical location [RFC 3825]
and civic location [RFC 4676]. The UE also supports SIP multipart MIME as specified in [RFC 3261] to
convey location information in SIP message bodies as defined below.
8.4 Emergency Call Handling

This informative section describes the basic steps in emergency call handling in NENA i1, [NENA i2], and
[NENA i3] environments. They include:
1. At boot time, the UE requests its location from the access network using DHCP. The UE must request the
DHCP Option for Civic Addresses Configuration Information [RFC 4676] by including the option 99 in the
DHCP 'parameter request list' option value (DHCP option 55) of the broadcast DHCPv4 DISCOVER message
in IPv4.
In IPv6, the UE must use DHCPv6 [RFC 3315] to request its location from the access network. The UE must
include an Option Request option (OPTION_ORO) with a requested-option-code value of 99
(GEOCONF_CIVIC) in a Solicit, Request, Renew, Rebind, Confirm or Information-request message in order to
inform the DHCPv6 server about DHCP civic option the client wants the server to send to the client.
Other configuration parameters related to emergency services support may also be provided to the UE by the
provisioning systems such as the local emergency dialing strings (for example, 9-1-1).
2. The user indicates the local dialing string for emergency calling (for this example, it is assumed 9-1-1 is
indicated or dialed on the phone).
PacketCable uses "the user indicates" as opposed to the user dials the local dialing string to be more generic. It
is defined to follow whatever the user picks as the specific dial string to be used for emergencies, whether the
dialing string is selected by pressing numeric keypad buttons to push in a certain sequence, by picking the 911
sequence from a menu on a display of the phone, or by merely selecting an "emergency" button — which could
be hardware or software-based — as the number selected for this call. The UE performs digit analysis and
determines that this is an emergency call based on configuration data.
3. The UE initiates a SIP INVITE transaction with the universal emergency service URN "URN:service:sos"
defined in [RFC 5031] as the Request-URI. The To: header value of the SIP INVITE request is also the
"URN:service:sos."
In some countries outside North America, the UE may be configured to support multiple local emergency dial
strings. The dial plan configuration mechanism defined in PacketCable provides the means to translate specific
dial strings into specific URIs or service URN (for example, the 112 dial string may translate into
URN:service:sos and 18 may translate into URN:service:sos.fire).

4. The INVITE request also includes the location obtained from DHCP in its message body in the form of a
Presence Information Data Format Location Object (PIDF-LO) [RFC 4119] as defined in the SIP Location
Conveyance specification [ID SIP-CONVEY].
The UE does not include the route received in the route header received at registration.
5. The P-CSCF detects the emergency call based on the presence of the "URN:service:sos" URN and forwards the
call to an Emergency-CSCF (E-CSCF).
The E-CSCF and P-CSCF are described as logical functions; the E-CSCF functions such as those described in
steps 6-9 may be implemented in the same physical network element as a P-CSCF, a S-CSCF, or in a separate
device.
6. The E-CSCF then follows the procedures outlined below, depending on the supported interim NENA
architecture, which is NENA i1, pre-i2, i2 [NENA i2], or i3 [NENA i3] compliant.
NENA i1 Architecture
The E-CSCF must convert the SIP Request URI into a 10-digit emergency services number. How this conversion is
done is beyond the scope of this specification.
The call is routed to the PSTN via the MGC. In this scenario, the call does not have location provided to the PSAP
through mechanisms defined in this specification.
NENA pre-i2 Architecture
The call is routed to the PSTN via an MGC connected to the E911 selective router. In this scenario, the caller's
telephone number is used to look up the UE location in the selective router for routing to the proper PSAP.
The E-CSCF may act as an emergency services routing proxy, as defined in [NENA i2]; in this case it relies on
PSTN interfaces for terminating the call to the PSAP using the PSTN. When the E-CSCF acts as a routing proxy
following the [NENA i2] requirements, the following applies:
• The E-CSCF extracts the location of the caller from the INVITE message body.
• The E-CSCF queries a VoIP Positioning Center (VPC) providing the location of the caller.
• The VPC returns a routing code or Emergency Service Routing Number (ESRN) and an Emergency Services
Querying Key (ESQK) that can be used for routing the call.
• The E-CSCF forwards the call by initiating an INVITE transaction with the ESQK in the appropriate header
(either the P-Asserted-Identity [RFC 3325], the P-Preferred-Identity, or the From) and the ESRN in the
Request-URI as defined by NENA.
• The call is routed to an Emergency Services Gateway (ESGW). The ESGW is the NENA functional element
that maps the given ESQK and ESRN to the PacketCable Signaling Gateway (SG), Media Gateway Controller
(MGC), and Media Gateway (see Section 8.8.2).
• The ESGW (as implemented by the SG, MGC, and MG) places the call on the appropriate Selective Router and
provides the ESQK as the calling party's telephone number.
• The Selective Router routes the call to the correct PSAP based on the calling party's telephone number (ESQK).
• The PSAP answers the call. It queries the Automatic Location Indication (ALI) database with the ESQK it
receives as the calling party's telephone number.
• The ALI database steers the query to the VPC that provided the ESQK.
• The VPC returns the location of the caller and its callback number.
• The data is returned from the ALI database and is presented to the PSAP.

• The E-CSCF extracts the location of the caller from the INVITE message body.
• The E-CSCF uses a static mapping or a mapping protocol to obtain the URI of the PSAP servicing the location
of the caller.
• If a valid PSAP URI is obtained from the mapping query, the call is forwarded by the E-CSCF to the PSAP SIP
server. The IP-enabled PSAP (NG9-1-1 PSAP) accepts the incoming call directly as a SIP session.
• If a PSAP URI is not returned from the mapping protocol because the PSAP does not accept SIP calls, or if the
mapping fails, the E-CSCF may proceed with NENA i1, pre-i2, or i2 [NENA i2] as indicated in step 6.
8.5 UE Requirements for Emergency Services Support

This section defines the minimum set of requirements for a UE to be capable of supporting emergency services in
PacketCable networks.
8.5.1 Minimum UE State to Place Emergency Calls

A UE MUST, at minimum, meet all the following conditions in order to be able to successfully make an emergency
call:
• The UE is capable of attempting an emergency call.
• The UE is participating in a keep-alive message exchange with the PacketCable network after obtaining the
emergency call configuration.
• The UE is registered and authenticated before an emergency call is placed.
A UE in the minimum state defined above should be returning a dial tone for a telephone to which it is connected. If
the UE is presenting the dial tone, emergency calls can be placed.
8.5.2 Emergency Calling Configuration

The following configuration parameters MUST be provided to a UE in support of emergency calling:
• A digit map identifying the sub-set of dialed numbers that must be recognized as emergency numbers.
• The UE's location information: a set of location parameters obtained via DHCP.
• The Request-URI to be used for emergency services, the default value being "urn:service:sos."
• The preference for the type of location format (Presence Information Data Format - Location Object, or PIDF-
LO) the UE should include if it gets both civic and geographic location information via DHCP.
• Other configuration parameters for special prioritization of media and signaling traffic of emergency calls as
defined in Sections 8.5.9 and 8.5.10.
The UE MUST be capable of handling emergency calls if dial-tone is provided, even when one or more of the
configuration parameters above are not provided, with the exception of the digit map. For example, the UE may
handle the call without prioritization or media QoS if the associated configuration parameters are not provided, but it
MUST attempt to place the emergency call.
8.5.3 Obtain Location

The UE is responsible for obtaining its location. A UE MUST be capable of receiving its location via DHCP by
processing the DHCP options that provide the civic address or coordinate-based (geographic) location configuration
information.
A UE MUST support the GEOCONF CIVIC DHCP option defined in the [RFC 4676], and the UE SHOULD also
support GeoConf DHCP option 123 defined in [RFC 3825]. A UE MUST request the GEOCONF CIVIC DHCP
option in DHCP option 55 in IPv4, and in the Option Request Option in DHCPv6. If both the DHCP GeoConf and
GEOCONF CIVIC options are supported, the UE MUST indicate or request both options in DHCP.

The resulting location information is then used by the UE to create a PIDF-LO using the mechanism described in
[RFC 4119] and illustrated in [RFC 4119]. The UE MUST use the value of the GEOCONF CIVIC DHCP option to
generate a PIDF-LO if both DHCP options 123 and 99 are returned by the DHCP server.
The UE MUST store the location information, along with the timestamp of when it receives its location information,
via DHCP. The PIDF-LO generated by the UE from the DHCP location information object MUST contain a
timestamp element. The value of the timestamp MUST be the time when the UE receives its location information.
When the UE registers, it SHOULD indicate support for the location, as defined in the SIP Location Conveyance
specification [ID SIP-CONVEY]. In particular, the UE MUST support SIP multipart MIME, as specified in
[RFC 3261], to convey location information in SIP message bodies.
8.5.4 Recognition of an UE-Originated Emergency Call

The recognition of an emergency call is a critical step in assuring its proper handling and call routing. Technical
requirements are, therefore, placed on both the UE and the P-CSCF to perform such recognition.
The UE-based digit map action MUST be provisioned with an indication to invoke the EMERGENCY-CALL digit
map action upon successful entry of a dial string configured as an emergency number as defined in Section 7.1.
Upon invoking EMERGENCY-CALL digit map action, the UE MUST proceed with the UE requirements identified
in the remainder of this Section 8.5.4, and continue with the other UE requirement in Sections 8.5.5 through 8.5.11.
The UE recognizes the local dialing string for emergency calling, through analysis of the digit map, that the user has
dialed (for example, 9-1-1 in the United States) based on the digit map configuration. Special processing of the call
should immediately take place.
The UE must be able to map several dialed strings or digit maps to the emergency service feature and its associated
service URN.
8.5.5 Basic Call Modifications while on an Emergency Call

Upon determining that an emergency call has been initiated (see Section 8.5.4), the UE and the associated network
elements involved in the emergency call MUST observe a number of specific call interaction requirements, as
defined in Section 8.5.5.

The following section illustrates a scenario in which a UE is controlling an analog phone. A sample of an
informative basic call is shown in Figure 71:
Phone UE PSAP
Network and PSTN
“A” “A”
Off-hook
Dial Tone
911
INVITE
Priority:emergency
INVITE
Priority:emergency
Alerting
183 with SDP
183 with SDP
PRACK
PRACK
200 OK PRACK
200 OK PRACK
Ringback Tone
Answer
200 OK
200 OK
ACK
ACK
Figure 71 - Emergency Call
8.5.5.1 Basic Call – SIP INVITE to initiate an Emergency Call

The UE generates a SIP request to initiate a call and sends it to the P-CSCF. In addition to following the UE
emergency procedures specified in [PKT 24.229] section "Emergency session setup within a non-emergency
registration," the SIP INVITE request initiating an emergency call MUST have:
• A multi-part MIME message body including:
- The UE location as specified in [PKT 24.229].
- The SDP message body part. The ITU-T G.711 codec MUST be offered in the media line attribute. If a
wideband codec is supported by the UE, it MAY be offered as an additional choice. The UE MUST NOT
offer any other codecs. Voice Activity Detection SHOULD be disabled.
• Any other mandatory SIP headers as defined in [PKT 24.229].
• SIP signaling identification of an emergency call as described in Section 8.5.9.
The UE SHOULD include a language preference whenever possible, according to the procedures in Section 7.1.6.9.
Other optional SIP headers MAY be provided.
If a call is returned to the UE with a 424 (Bad Location Information) response code (see [ID SIP-CONVEY]), the
call should be reattempted as an emergency call per Section 8.5.1. Upon receipt of a 424 (Bad Location Information)
response code, the UE SHOULD retry to determine its location using the method previously used (DHCP, for

example) and it SHOULD make a new attempt to initiate the emergency call. After the third unsuccessful attempt
(with the same location information in the SIP message body), the UE MUST stop retrying.
8.5.5.2 Basic Call – Early Media

No special interactions are noted between early media and emergency calling. The UE does not behave any
differently for early media (see Section 7.1.9) if the call is an emergency call.
8.5.5.3 Basic Call – Terminating Call

The requirements specified in [PKT 24.229] "Emergency session release" are superseded by the procedures in this
section and those specified in Section 8.5.5.8 and Section 8.5.6.
When the UE is in an emergency call, the UE MUST reject all incoming calls that are not emergency calls with a
486 – Busy here response.
The UE MUST accept a ringback request from the PSAP, which is signaled using a RE-INVITE with a special
ringback Alert-Info header. When the UE receives the RE-INVITE with the special ringback Alert-Info header, it
MUST generate ringing (if the UE is on-hook) or a configured duration howler tone (if the UE is off-hook).
Note: If the UE hangs up while receiving a howler tone due to ringback, the howler tone stops, the operator
position is notified through a reinvite with hold SDP, and the operator is notified that the phone is on-hook
by receiving low tone at his or her position, and may then choose to cause ringback again.
The UE MUST accept a callback request from the PSAP.
8.5.5.4 Basic Call - Hold

The UE MUST NOT initiate a HOLD (see Section 7.1.5) while active on an emergency call.
While active on an emergency call, the UE MUST be capable of receiving a hold request (see Section 7.1.5).
8.5.5.5 Basic Call – No Answer Timeout

No special interactions are noted here.
8.5.5.6 Basic Call – Response Codes and RE-INVITE

The UE MUST NOT initiate a REFER while active on an emergency call. Additionally, the UE SHOULD NOT
send a 300 Multiple Choices, 301 Moved Permanently, or 302 Moved Temporarily response to an emergency call
ringback or callback.
While active on an emergency call, the UE MUST be capable of receiving a REFER, since this is often done to
transfer the emergency call to the proper agency to provide assistance. The UE MUST set the Priority header in the
resulting INVITE to "emergency".
8.5.5.7 Basic Call – Forced Disconnect

The UE MUST honor a BYE request from PSAP on an emergency call (PSAP forced disconnect); this ensures that
the resources used for the emergency call are released for the next emergency call. Although this is normal UE
behavior, no feature or service should allow this behavior to be modified while on an emergency call.
8.5.5.8 Basic Call – Network Hold Support

Network Hold is an optional feature that provides the ability to hold the network connections for the emergency call
in the event that the caller tries to release the session prior to disconnecting from the PSAP operator. If Network
Hold is supported in the network in the PSTN, the PSAP operator hears a tone to indicate that a caller has gone on-
hook and the hold has been activated.
The session and the call resources are held in the network until either:
• The PSAP operator releases the call (forced disconnect).

• The UE reconnects to the original emergency call session.

• The UE network hold timer expires.
Because only the PSAP knows if the network hold feature is in effect, the UE must assume that network hold could
be applied. This means that the UE processing of a disconnect request from the user differs from standard basic call
processing of a user disconnect after the PSAP answers.
If the UE disconnects before receiving a 200 OK (answer) on the emergency call, the UE MUST process that
disconnect as if this is not an emergency call, and send according to [RFC 3261].
Upon receiving a disconnect from the user while on an emergency call, and after receiving the first 200 OK from the
PSAP, the UE MUST send a hold event to the network (see Section 7.1.5) and start a Network Hold timer. The
network hold event sent to the network MUST contain the emergency call indicator headers so that the network can
differentiate that hold from a user initiated hold, per Section 8.5.5.4, which should be denied. This is shown in
Figure 72.
Phone UE PSAP
Network and PSTN
“A” “A”
On-hook
Network hold
timer started
INVITE
Priority:emergency
SDP:a=inactive INVITE
Priority:emergency
SDP:a=inactive
Disconnect
200 OK
200 OK
ACK
ACK
Held Media
Figure 72 - Emergency Call - User disconnect handling

If the user attempts to reconnect to the call, then the UE MUST return from hold (see Section 7.1.5), reconnect with
the PSAP, and cancel the network hold timer at that time. This process is shown in Figure 73.
Phone UE PSAP
Network and PSTN
“A” “A”
Held Media
Off-hook INVITE
Priority:
emergency INVITE
SDP:a=sendrecv Priority:
emergency
SDP:a=sendrecv
200 OK
200 OK
ACK
ACK
Figure 73 - Emergency Call - Reconnecting after hold
When the UE network hold timer expires, the UE MUST send a BYE towards the network to release the network
resources.
The value of the network hold timer should be provisioned on the UE (see Table 54). A value of '0' means that the
network does not support network hold, although this is not recommended unless it is known that all PSAPs
reachable from this UE do not support network hold.
8.5.6 PSAP Operator RingBack

Operator Ringback is a feature that allows the PSAP to alert the caller. The type of alert depends on whether there is
an established bearer path to the caller or not. If there is an established bearer path (the caller is offhook), the caller
can be alerted with a special in-band audible alerting (usually a ROH tone). If the caller is on Network Hold
(onhook), then the caller is alerted with standard power ringing alerting. While the caller is receiving the ringback,
the PSAP should be receiving audible alerting.
8.5.6.1 PSAP Ringback with an established bearer path (Offhook Caller)

When the PSAP indicates that the caller should be alerted and the caller has an established bearer path, the network
sends the caller a special in-band audible alerting in the standard bearer path. This behavior is not specific to the fact
that this is an emergency call. No unique behavior is required by the UE for emergency calls.
The network sends ROH through a REINVITE of the bearer path to a server that can provide the special in-band
alerting. The UE MUST accept REINVITEs per Section 8.5.5.6. The length of tone is decided by the network and
the network provides the audible ringing towards the PSAP.
Alternatively, the UE MAY receive a request to play a tone (per [RFC 2833], usually ROH). In this circumstance,
the UE MUST play back that tone for the length of time specified in the request. UEs must support reception of the
ROH tone, per [RFC 2833]. The network is responsible for providing audible ringing towards the PSAP.
If the UE receives an onhook indication while playing ringback, the UE MUST behave as if ROH is not playing and
send a hold event according to Section 8.5.5.8.
8.5.6.2 PSAP Operator Ringback while on Network Hold (Onhook Caller)

When the PSAP indicates that the caller should be alerted while the caller is on network hold, the UE should
continue to run the Network Hold timer and provide the physical ringing indicated. This is shown in Figure 74.

To accomplish the ringing, the network sends a REINVITE with an Alert-Info header that indicates the type of
physical alerting that should be provided. The UE MUST provide the physical alerting specified. If the UE does not
support the alert pattern specified in the Alert-Info header, or if it cannot retrieve the alert pattern, then the UE
MUST substitute standard ringing. The UE processes this REINVITE according to basic call procedures, including
sending of 180 ringing and responding as appropriate for a standard terminating call. If the operator ringback call is
not answered and the No Answer Timeout expires, the UE MUST terminate the REINVITE transaction and stop
ringing the phone. In this case, the UE MUST NOT send a BYE to terminate the emergency call dialog. In other
words, the ongoing Network Hold procedure is not interrupted when the No Answer Timeout expires.
Phone UE PSAP
Network and PSTN
“A” “A”
Held Media
INVITE Initiate Ringback
Priority:
INVITE emergency
Priority: SDP:a=sendrecv
emergency
Power SDP:a=sendrecv
Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
ACK
ACK
Figure 74 - Emergency Call - PSAP operator ringback while on hold
The network provides audible ringing back to the PSAP until it receives a 200 OK from the UE.
If the Network Hold timer expires during the Operator Ringback procedure, the UE MUST send a BYE towards the
network.
If the caller answers, the UE MUST send a 200 OK according to basic call procedures and cancel the Network Hold
timer.
8.5.7 PSAP CallBack (PSAP Originated Emergency Call)

After an emergency call is ended (due to a caller-initiated disconnect before 200 OK or a PSAP forced disconnect),
the PSAP operator may still wish to re-establish the connection with the caller. In this case, the PSAP initiates a new
call towards the UE, which can be identified as an operator-initiated emergency callback by the UE, based on the
presence of the well-known network asserted identity that matches the sub-service 'sos' as defined in [RFC 5031].

Phone UE PSAP
Network and PSTN
“A” “A”
Callback
INVITE
Priority:
INVITE
emergency
Priority:
Power emergency
Ringing
180 Ringing
Ringback
200 OK
Tone
200 OK
ACK
ACK
Figure 75 - Emergency Call - PSAP operator callback
In this case, the UE MUST consider the incoming request as an emergency call initiation and behave as if the UE
initiated the emergency call. That is, the basic call procedures in Section 8.5.5, the Network Hold Procedures in
Section 8.5.5.8, the PSAP Ringback procedures defined in Section 8.5.6, and the feature interaction procedures
defined in Section 8.5.8 MUST all still apply. This is shown in Figure 75.
8.5.8 Feature Interactions

Upon determining that an emergency call has been placed (see Section 8.5.4), the UE involved in the emergency call
conforms to a number of specific feature interaction requirements, as defined in this section.
Caller ID Display
No interactions. Feature should work as specified.
The UE MUST NOT block Caller ID when an emergency call is made. Although the Caller ID is not currently used
by the PSAP, it may be used in the future.
The UE MUST NOT block Caller ID when an emergency call is made. Although the Caller ID is not currently used
by the PSAP, it may be used in the future.
Caller ID Per-Call Delivery
No interactions. Feature should work as specified. PSAP ringbacks and callbacks are not anonymous.
The UE that provides an analog telephone interface MUST implement the feature interactions between Call
Forwarding Variable and emergency services as specified in Telcordia [GR 529] and [GR 580].
The UE MUST NOT forward an emergency ringback and emergency callback call.

Call Forwarding Do Not Answer

Forwarding Do Not Answer and emergency services as specified in Telcordia [GR 529] and [GR 586].
Call Forwarding on Busy
Forwarding on Busy and emergency services as specified in [GR 529] and [GR 586].
The UE that provides an analog telephone interface MUST implement the feature interactions between Selective
Call Forwarding and emergency services, as specified in [GR 529] and [GR 217].
Remote Activation of Call Forwarding
No Interactions.
Call blocking service to emergency services should not be allowed when the service allows the dial-tone to be
provided.
Collect Call Blocking
Collect calls to emergency services should not be blocked.
900/976 Call Blocking
Call Waiting
The UE that provides an analog telephone interface MUST implement the emergency call interactions according to
[GR 529] and [GR 571].
Additionally, all incoming calls should be blocked unless they include the emergency call indicators. If, while the
UE is in an emergency session, the UE receives a call without the emergency services indicator, it MUST respond
with a 486 – Busy Here.
Hold
[GR 529], [GR 577] and [GR 579].
The UE MUST NOT put an emergency call on hold.
Call Transfer
Telcordia [GR 529] and [GR 577].
The UE MUST NOT transfer an emergency call.
Three Way Calling
The UE MUST NOT invoke a three-way calling feature in an emergency call.
Do Not Disturb
Telcordia [GR 529].
The UE SHOULD NOT reject an emergency ringback (RE-INVITE) and an emergency callback call.

Subscriber Programmable PIN

Message Waiting Indicators
The UE that provides an analog telephone interface interrupts an MWI transmission for an incoming call. Therefore,
the PSAP ringback and callback take precedence over MWI. The MWI is applied after the current call is completed
per Section 7.6.4.
Speed Dialing
The Speed Dial AS MUST implement the emergency call interactions according to Telcordia [GR 570].
Customer-Originated Call Trace
Additionally, the UE and the COT AS MUST NOT allow an emergency ringback or callback to be traced.
Screen List Editing (SLE)
There is no UE requirement regarding feature interaction between Emergency Call and SLE.
Auto Recall
Telcordia [GR 227].
The UE and the Auto Recall AS MUST NOT allow the Auto Recall feature to be used to target an emergency phone
number or address. The UE and Auto Recall AS MUST block Auto Recall of an emergency call with long term
denial treatment.
Auto Callback
The UE and the Auto Callback AS MUST NOT allow the Auto Callback feature to be used to target an emergency
phone number or address. The UE and Auto Callback AS MUST block Auto Callback of an emergency call with
long term denial treatment.
Busy Line Verification
No interactions. Feature should work as specified. BLV of an emergency services call is allowed.
Emergency Interrupt
No interactions. Feature should work as specified. Emergency Interrupt of an emergency services call is allowed.
Call Completion
No interactions. Feature should work as specified. Call Completion of an emergency services call is allowed.
8.5.9 Signaling Identification of an Emergency Call

Once a call has been determined to be an emergency call (see Sections 8.5.4 and 8.6.1), additional requirements are
applied to the signaling to ensure proper priority of the call and the signaling through the use of additional SIP
headers.

8.5.9.1 SIP Priority Header Marking of an Emergency Call

The SIP Priority header is defined in [RFC 3261] and provides a user indication of the importance that the SIP
request should have for the receiving human or user agent. The 'Priority' header field does not affect the usage of
PSTN gateway or proxy resources. The UE MUST set the SIP Priority header for emergency session establishment.
Example:
Priority: emergency
8.5.10 QoS for an Emergency Call

The UE MUST set the DSCP value for the media IP packets of emergency calls, with the provisioned value
"Emergency Media DSCP Value" as indicated in Table 54.
The UE MUST set the DSCP value for the signaling IP packets of emergency calls with the provisioned value
"Emergency Signaling DSCP Value" as indicated in Table 54.
8.5.11 Other UE Requirements

In the INVITE sent by the UE to the P-CSCF for emergency call, the UE MUST NOT include the route received in
the Service-Route header that was received in the registration response.
8.5.12 Emergency Services Feature Data

Table 54 summarizes the feature data elements defined to support the implementation of the Emergency Services
feature.
Table 54 - Emergency Services Feature Data

Requirement
Network Hold Timer Integer (minutes) Per network Config.Server Config.Server UE Mandatory
(default: 45; see Note 1)
Emergency Howler Integer (seconds) Per Network Config.Server Config.Server UE Mandatory
Duration (default: 3)
Emergency Media DSCP Integer (range of 0..63) Per Network Config.Server Config.Server UE Mandatory
Value
Emergency Signaling Integer (range of 0..63) Per Network Config.Server Config.Server UE Mandatory
DSCP Value
Note 1: Default is set according to [GR 529].
8.6 P-CSCF Requirements

8.6.1 Recognition of UE-Originated Emergency Call
The requirements specified in [PKT 24.229] P-CSCF normal procedures "General" and P-CSCF emergency
procedures apply with the following adaptations.
The non-registered UE requirements in [PKT 24.229] P-CSCF emergency procedures "General treatment for all
dialogs and standalone transactions excluding the REGISTER method - from an unregistered user", and the
emergency registration case in [PKT 24.229] P-CSCF emergency procedures "General treatment for all dialogs and
standalone transactions excluding the REGISTER method after emergency registration" are not applicable.
For [PKT 24.229] P-CSCF emergency procedures "General treatment for all dialogs and standalone transactions
excluding the REGISTER method - non-emergency registration", the P-CSCF behavior when it recognizes that the
request is for emergency calls, and for some reasons the UE did not recognize the call as an emergency call, is
different for PacketCable, and is described in the remainder of this section and Section 8.6.2.
In the event that, for some reason, the UE does not recognize that the local dialing string for emergency calling has
been dialed (for example, 9-1-1), the P-CSCF MUST recognize that the emergency dialed number and the P-CSCF

SHOULD immediately reject the call with a 424 (Bad Location Information) response code as defined in the SIP
Location Conveyance specification, [ID SIP-CONVEY]. In order to support non-UEs, upon receipt of a second SIP
request for an emergency dialed number from the same UE, the P-CSCF may accept the call and process the request
accordingly.
8.6.2 Forwarding the call to an E-CSCF

Upon determination that the call attempt is an emergency call, the P-CSCF MUST forward the call to an E-CSCF on
the same network as the P-CSCF.
Note: In case the P-CSCF decides to proceed with an emergency call that is not recognized as an emergency call
by the UE as specified in the previous section, the P-CSCF MUST ignore the received Route header and
use its provisioned E-CSCF route.
8.6.3 Handling of Network-Initiated De-Registration during Emergency Calls

As defined in [PKT 24.229], network-initiated de-registration may occur; it should, however, be handled carefully
when an emergency call is attempted or in progress.
The P-CSCF MUST defer the processing of a network-initiated de-registration request for a Public Identity if it
determines that an emergency call has been initiated or is currently in progress for the given Public Identity.
8.7 E-CSCF Requirements

8.7.1 Emergency Call Routing in the NENA i3 Architecture
8.7.1.1 Determining the Request-URI to forward the SIP request to

The E-CSCF uses the location reported inside the SIP message body to determine the correct PSAP to which to
route the call, either through a static mapping as specified in [PKT 24.229] E-CSCF procedures for "UE originating
case," or through the use of a mapping protocol.
Note: A candidate mapping protocol is the Location-to-Service Translation Protocol [RFC 5222], which is being
defined by the IETF ECRIT working group.
If the mapping returns a response indicating that no information is available (the mapping function is operable, but
does not have data to determine the correct URI), the E-CSCF MUST follow the procedure in Section 8.7.2.
8.7.1.2 Processing the INVITE request after successful ECRIT mapping resolution
The E-CSCF procedures in [PKT 24.229] "UE originating case" apply.
8.7.2.1 Emergency Call Routing in NENA i2: determining ESRN and ESQK
The E-CSCF receives an INVITE request from the P-CSCF, which contains location as a PIDF-LO in the body of
the INVITE, and the TN of the caller in the P-Asserted-Identity header.
The E-CSCF SHOULD query a [NENA i2] compliant VoIP Positioning Center using the "V5" interface, sending the
location and TN of the caller as described in [NENA i2]. The VPC returns an ESRN, ESQK and Last Resort
Option.
8.7.2.2 Processing the INVITE request in NENA i2

The E-CSCF follows the procedures in [PKT 24.229] "UE originating case", with the following adaptations.

The E-CSCF MUST insert the ESQK as the TN in the INVITE as follows. The E-CSCF MUST delete the received
P-Asserted-Identity header value, and replace it with a P-Asserted-Identity header value containing the ESQK as the
TN.
The E-CSCF MUST then set the Request URI to the ESRN.
The E-CSCF MUST then route the INVITE to the SG or MGC.
8.7.2.3 Dealing with errors

If a call is returned to the E-CSCF by the ESGW network, the E-CSCF MUST restore the header used to carry the
ESQK to the value it received (that is, the TN of the caller), change the Request-URI to the Last Routing Option
(LRO), and forward the call to a PSTN gateway.
If a call is returned by the PSTN gateway, the E-CSCF MUST return a 600 Busy Everywhere.
8.7.2.4 Processing a BYE

When the E-CSCF receives the BYE transaction, it MUST notify the VPC, using the V5 interface, to release the
ESQK.
The E-CSCF MUST then forward the BYE towards the P-CSCF.
8.7.3 Emergency Call Routing in NENA Pre-i2

The call is routed by the dedicated E911 PSTN network selective router based on the telephone number of the caller,
and the location associated with the telephone number in the selective router.
8.7.3.1 INVITE Request Processing

The E-CSCF follows the procedures in [PKT 24.229] "UE originating case", with the following adaptations.
The E-CSCF MUST insert the P-Asserted-Identity received in the INVITE in the outgoing INVITE.
If the P-Asserted-Identity header is not in a telephone number format, the call can still be routed, and is default
routed by the selective router.
No location information is required, but if it is provided, it MUST be passed in the INVITE towards the MGC.
Since the location based routing is done in the selective router, the E-CSCF MUST route the call to the MGC and
the Selective Router.
8.7.3.2 Additional message processing

No additional message processing is required.

The call is routed to the PSTN number associated with the PSAP. This solution does not make use of the dedicated
TDM selective router.
8.7.4.1 Processing Invite Request

In these scenarios, no location information is required, but if the location is received in the INVITE, the E-CSCF
MUST insert it in the INVITE to be sent towards the MGC, SG, and MG.
The E-CSCF MUST convert the SIP-Request-URI to the E.164 PSTN number of the PSAP. The method by which
this is done is beyond the scope of this specification.
The E-CSCF MUST then route the INVITE to the SG/MGC/MG.
8.7.4.2 Processing additional messages

No additional message processing is required.

8.8 MGC, SG and MG Requirements

This section identifies requirements on the MGC, SG, and MG for emergency calls. These components interface
with the PSTN and the selective router in the PacketCable architecture. In order to facilitate the PSTN connections,
compliance with Telcordia PSTN and selective router interface documents is required.
8.8.1 Emergency Call Routing in NENA i3

The MGC, SG, and MG are not used in [NENA i3] because the PSAP is directly connected to the PacketCable
network via SIP.
8.8.2 Emergency Call Routing in NENA i2

The MGC requirements for emergency call routing in NENA i2 are specified in [CMSS1.5]. The MG requirements
for emergency call signaling in NENA i2 are specified in [TGCP1.5].
8.8.3 Emergency Call Routing in NENA Pre-i2

The MGC requirements for emergency call routing in NENA Pre-i2 are specified in [CMSS1.5]. The MG
requirements for emergency call signaling in NENA Pre-i2 are specified in [TGCP1.5].

The call is treated as a normal PSTN call. No special requirements are needed on the MGC, SG, and MG. Network
Hold and Network Ringback are not supported.

Annex A Digit Map Syntax (Normative)

The following Augmented Backus-Naur Form describes the digit map syntax for UEs:
; First, some preliminaries
Alphanum = ALPHA / DIGIT

Identifier = ALPHA *( [ "_" / "-" ] 1*Alphanum )
Number = 1*DIGIT
Fraction = ( Number ["." [Number]] / "." Number )
CommentText = VCHAR / WSP

Comment = "//" *CommentText CRLF ; end-of-line comments like C++
LineBreak = 1*(*WSP (CRLF / Comment))
LWSC = *LineBreak 1*WSP ; Linear WhiteSpace w/ optional Comment

SWSC = [LWSC] ; Separating Whitespace
; w/ optional Comment
COMMA = SWSC "," SWSC

SEMI = SWSC ";" SWSC
COLON = SWSC ":" SWSC
EQUAL = SWSC "=" SWSC
LPAREN = SWSC "(" SWSC
RPAREN = SWSC ")" SWSC
SQUOTE = "'" ; Single Quote
NonDQuote = %x21 / %x23-7E ; VCHAR less DQUOTE

NonSQuote = %x21-%x26 / %x28-7E ; VCHAR less SQUOTE
MapNameDef = Identifier ; distinguished semantically

MapNameRef = Identifier ; distinguished semantically
SymbolNameDef = Identifier ; distinguished semantically
SymbolNameRef = Identifier ; distinguished semantically
; The major substance follows
DigitMapPackage = *(TimerDef / SymbolDef / MapDef / LineBreak)
TimerDef = "Timer" 1*WSP Timer EQUAL Fraction LineBreak

Timer = StandaloneTimer / PrefixTimer
StandaloneTimer = "T" / "S"
PrefixTimer = "Z" ; modifies the following key
NonAmpersand = %x21-%x25 / %x27-7E ; VCHAR less AMPERSAND
SymbolDef = SymbolNameDef EQUAL SymbolVal LineBreak

SymbolVal = Constant *( SWSC Constant )
/ "&" 1*NonAmpersand
Constant = DQUOTE 1*NonDQuote DQUOTE
/ SQUOTE 1*NonSQuote SQUOTE
MapDef = "Map" 1*WSP MapNameDef EQUAL 1*( LWSC Rule LineBreak)
Rule = Pattern COLON Action *(SEMI Action)
Pattern = DQUOTE PatternBody DQUOTE

PatternBody = 1*( Target [Count])
Target = [ PrefixTImer ] Key ; Keypress with optional

; long duration

/ StandaloneTimer ; Delay triggering match

/ SubPattern
/ Noise ; ignored, just for readability
SubPattern = "(" PatternBody ")" ; nested patterns for repetition

; and referencing
/ "(" "=" Reference ")" ; ref to map or symbol
Key = KeySingleton ; an individual dialed key

/ KeyChoice ; a member in a set of dialed keys
KeyChoice = "[" ["^"] 1*( KeySingleton / (DIGIT "-" DIGIT) ) "]"

; any key in a set of individual keys and
; ranged DIGITs, or any key not in the set
KeySingleton = DIGIT ; dialed digit

/ "X" ; any numeric dialed digit
/ "*" / "#" ; special dialed symbols
/ "A" / "B" / "C" / "D" ; extra number pad keys
Count = "{" [Number "-"] Number "}"

; repeat no fewer than 1st #,
; no more than last #
Noise = "-" / "." / WSP
Reference = MapNameRef / SymbolNameRef
Action = Verb [LPAREN Parameter *( COMMA Parameter ) RPAREN]

Verb = "RETURN" / "USEMAP" / "ACR-ACTIVATE" / "ACR-DEACTIVATE" /
"AC-ACTIVATE" / "AC-DEACTIVATE" / "MAKE-CALL" / "AR-ACTIVATE" / "AR-DEACTIVATE" /
"CID-SUPPRESS" / "CID-DELIVER" /
"COT-ACTIVATE" / "CW-TOGGLE" / "HOLD-ACTIVATE" / "EMERGENCY-CALL" / "REORDER" /
"RECALL" / "FEATURE-CHECK" / "ACTIVATED-CHECK" / "DEACTIVATED-CHECK" / "CNDB-TOGGLE" /
Identifier
Parameter = StringParam / MapParam
StringParam = ParamPiece *( [SWSC] ParamPiece )
ParamPiece = Constant
/ "=" SymbolNameRef
/ "#" Number [ "v" ]
MapParam = "=" MapNameRef

Appendix I Acknowledgements
PacketCable wishes to recognize the following individuals for their significant involvement and contributions to this
specification (ordered alphabetically by company name and individual's first names in each company):
Steve Hughey (Arris)
Gordon Li (Broadcom)
Brent Agnew (Broadsoft)
Bernard McKibben, Jean-Francois Mule (CableLabs)
Geoff Devine (CedarPoint)
Flemming Andreasen, Paul Kyzivat (Cisco)
Eric Turcotte, Sean Schneyer (Ericsson)
Moh Torabi (Lucent)
Bob Stein, Phil Freyman (Motorola)
John Gilmore, Kevin Boyle, Ricky Kaura (Nortel)
Mark Trayer (Samsung)
Tom Miller (Siemens)
Kerbey Altmann (Sigma Systems)
John Bartusek, Satish Kumar, Sophia Scoggins (Texas Instruments)
David Hancock (CableLabs)

Appendix II Revision History

The following Engineering Change Notices were incorporated into PKT-SP-RSTF-I02-070925.
ECN Date Accepted Summary

RSTF-N-07.0434-2 6/11/07 Clarification of Call Hold
RSTF-N-07.0435-2 6/11/07 Clarification of Ringback Requirements in 2-way calls and multi-party
calls
RSTF-N-07.0436-2 6/11/07 Clarification of RSTF document scope to indicate that it specifies
signaling requirements
RSTF-N-07.0437-2 6/11/07 IPv4 IP Address use clarification
RSTF-N-07.0438-3 6/11/07 Editorial cleanup of RST Feature specification
RSTF-N-07.0439-2 6/11/07 Extend the formal definition of "Key" for digit map
RSTF-N-07.0448-2 6/18/07 Application of Preconditions to Call Waiting
RSTF-N-07.0449-2 6/18/07 Caller ID Display Clarification
RSTF-N-07.0450-1 6/18/07 Caller-ID Service Clarification
RSTF-N-07.0451-1 6/18/07 Application of Preconditions to CFDA
RSTF-N-07.0452-2 6/18/07 Emergency Services requirements issues and clarifications
RSTF-N-07.0453-3 6/18/07 Multi-party Feature Correction
RSTF-N-07.0454-2 6/18/07 Addition of 'Resource Reservation' considerations to the application of
ringback & early media
RSTF-N-07.0457-4 6/25/07 AR and AC Deactivation Feature
RSTF-N-07.0459-1 6/25/07 Call Transfer call flow and CT AS procedure corrections
RSTF-N-07.0460-2 6/25/07 Call Transfer Interaction with Emergency Calls and other Call Transfer
clarifications
RSTF-N-07.0461-3 6/25/07 Specification of dynamic feature data for CFV, SCF and DND
RSTF-N-07.0462-2 6/25/07 Clarification of IPv6 requirements for RST UE
RSTF-N-07.0463-3 6/25/07 Make MWI feature availability a UE configuration data item
RSTF-N-07.0464-3 6/25/07 Trace Header Change for COT feature
RSTF-N-07.0465-3 6/25/07 Clarifications and corrections to Announcements and Distinctive Alerting
RSTF-N-07.0470-2 7/16/07 Alignment with 3GPP IMS Release 7 and other reference updates
RSTF-N-07.0478-3 8/13/07 Emergency Services alignment with 3GPP R7
RSTF-N-07.0479-1 8/13/07 Equal Access and digit map clarifications

RSTF-N-07.0495-4 11/5/07 PACM Spec Withdrawal RSTF Impacts
RSTF-N-08.0509-2 3/24/2008 Updates for 3GPP Dec 07 R7 alignment, IETF updates and withdrawal of
33.210 delta spec


RSTF-N-08.0521-4 5/27/2008 Address misalignment with PacketCable 1.5 E-MTA, and other
inconsistencies

RSTF-N-08.0533-2 12/1/08 SIP Response handling corrections for 487 and others
RSTF-N-08.0534-3 12/8/08 Call Waiting Correction
RSTF-N-08.0535-4 12/1/08 Digit Map Enhancements
RSTF-N-08.0536-4 12/8/08 Correction of miscellaneous issues
RSTF-N-08.0537-4 12/8/08 Correction of errors related to provisioning feature data items
RSTF-N-09.0544-3 4/13/09 Clarify that BYE Delay Timer is applicable to the called party only and not
to the calling party
RSTF-N-09.0545-3 4/27/09 Alignment of Call waiting toggle behavior with GR 572
RSTF-N-09.0546-3 4/13/09 Add support for automatic Daylight Saving Time Adjustment for caller id
time display
RSTF-N-09.0547-3 4/13/09 Configurable Local Media Hold
RSTF-N-09.0548-5 4/27/09 Caller-ID Toggle alignment with Telcordia GR-391 CNDB feature
RSTF-N-09.0549-5 4/27/09 Corrections, simplifications and clarifications to sample digit map
RSTF-N-09.0550-1 4/27/09 Update IETF references
RSTF-N-09.0551-1 4/27/09 Remove "Persistence" attribute from data tables, since it is redundant
RSTF-N-09.0559-2 4/27/09 Operator ringback NATO timer clarification
RSTF-N-09.0560-3 4/27/09 Remove stray PACM reference from XML body namespace

RSTF-N-09.0571-9 9/8/2009 Add support for Network Based Call Screening (NBCS) feature
RSTF-N-09.0585-3 11/23/2009 REG Event rejected event attribute
RSTF-N-09.0586-6 11/23/2009 Digit map external variables
RSTF-N-09.0587-5 11/23/2009 Enhanced Speed Dialing
RSTF-N-09.0588-3 12/7/2009 Add Support for Hotline Feature
RSTF-N-09.0589-2 12/7/2009 Operator specific features identification and usage with digit map.
RSTF-N-09.0596-4 11/23/2009 Clarifications on requirements that are optional to implement on RST UE
RSTF-N-09.0597-5 12/14/2009 Update IETF I-D references
RSTF-N-09.0609-3 12/7/2009 Align COT procedure with RFC 5503 that obsoletes RFC 3603
RSTF-N-09.0615-4 12/14/2009 Free phone services identification


RSTF-N-10.0624-1 4/12/2010 Correct CHD VSC in sample digit map to align with table (*92 to *52)
RSTF-N-10.0625-1 4/12/2010 Clarification of PSAP operator ringback while on network hold
RSTF-N-10.0626-1 4/12/2010 Switch precedence of CFV and SB features (CFV should be before SB)
RSTF-N-10.0629-2 4/26/2010 Updates to Speed Dial Local Map Feature
RSTF-N-10.0635-3 5/3/2010 Clarify the UE behavior of hook-flash handling, incorrect tone in call
waiting error scenario
ECN ECN Date Summary

RSTF-N-10.0656-2 1/4/11 Clarify UE requirements to map alert-info values for call waiting scenario
RSTF-N-10.0655-3 1/4/11 Clarify that hook flash must be ignored if an active call does not already
exist
RSTF-N-10.0654-1 1/4/11 Clarify that non-emergency signaling DSCP value applies to all TCP
packets
RSTF-N-10.0652-2 12/20/10 Update in-service/out-service procedures to handle variations in
registration responses
RSTF-N-10.0651-3 12/20/10 Support in-dialog REFER for call transfer feature
RSTF-N-10.0650-2 12/20/10 Three way calling disconnect handling
RSTF-N-10.0649-2 12/20/10 Clearly specify RST UE expected behavior in case of call waiting third
party hangup
ECN ECN Date Summary

RSTF-N-12.0673-2 3/5/12 Clarify the Transfer of Incoming Calls
RSTF-N-12.0672-3 2/27/12 Clarify UE requirements to play dial tone after CFV activation or
deactivation
RSTF-N-12.0671-2 2/27/12 Remove active status check from cfv digit map action
The following Engineering Change Notice was incorporated into PKT-SP-RSTF-I10-130411.
ECN ECN Date Summary Author

RSTF-N-12.0695-3 1/29/2013 Hotline Feature Interactions Klatsky


PKT SP RSTF C01 140314

Uploaded by

Copyright:

Available Formats

PKT SP RSTF C01 140314

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PKT SP RSTF C01 140314

Uploaded by

Copyright:

Available Formats

PacketCable™

Residential SIP Telephony Feature Specification

Document Status Sheet

Document Control Number: PKT-SP-RSTF-C01-140314

Document Title: Residential SIP Telephony Feature Specification

Revision History: I01 - Released 9/27/06

Date: March 14, 2014

Status: Work in Draft Issued Closed

Distribution Restrictions: Author Only CL/Member CL/ Member/ Public

Key to Document Status Codes

Draft A document in specification format considered largely complete, but lacking

7.3.2 Call Forwarding Variable ................................................................................................................... 83

8.7 E-CSCF Requirements ............................................................................................................................... 203

FIGURE 37 - OCB - OVERRIDE PIN SERVICE NOT ENABLED ...................................................................................... 110

TABLE 11 - UE ANNOUNCEMENT LANGUAGE PREFERENCE FEATURE DATA ............................................................... 45

2.2 Informative References

2.3 Reference Acquisition

• National Emergency Number Association (NENA), http://www.nena.org/9-1-

3 TERMS AND DEFINITIONS

CNAM Calling Name.

Integrated Services User Part (part of the SS7 signaling stack).

4 ABBREVIATIONS AND ACRONYMS

ISUP Integrated Services Digital Network (ISDN) User Part

5.1 PacketCable Design Considerations for Residential SIP Telephony

5.2 Residential SIP Telephony Specific Applications

5.3 Functional Components for Residential SIP Telephony

5.4 Protocol Interfaces for Residential SIP Telephony

6 NORMATIVE REFERENCE APPLICATION

6.1 Adaptations of [PKT 24.229]

7 RESIDENTIAL SIP TELEPHONY FEATURE REQUIREMENTS

7.1.1 Digit Maps

7.1.1.1 Digit Map Syntax Introduction

7.1.1.2 Digit Map Semantics

7.1.1.3 Sample Digit Map

areaCode = &varAreaCode // varAreaCode is defined via configuration (see Basic Call

MAP Emergency = // Matches emergency dialstrings

MAP PhoneNumbers = // Matches phone# and returns the canonicalized

MAP CollectNumbers = // 800 and friends

MAP SurchargedNumbers = // 900, etc.

MAP DialAround = // Matches dial around phone# and returns canonicalized

MAP ImmediateVSCs = // Matches and executes immediate VSCs. Returns nothing

: MAKE-CALL ( "sip:" #0 =domain =dialstring)

MAP SD8 = // Program one-digit speed dial number

MAP SD30 = // Program two-digit speed dial number

MAP ForwardingNumber = // Just for programming CFV

MAP Star = // Matches star & 11

MAP End = // Matches End of Dial Indicators # or S

7.1.2 Vertical Service Codes

UE Action ID and Input Parameter(s) Description

UE Action ID and Input Parameter(s) Description

Table 2 - Features that are Configurable Through the Digit Map

Service Action Suggested VSC

Service Action Suggested VSC

7.1.3 Addressing and Dial String Entry

7.1.4 Basic Call Signaling

7.1.4.1 Originating a Call

• Initiate a SIP session, as specified in [PKT 24.229].

Alert-Info Header Present? SDP Received? RTP Packets Received? Action

7.1.4.2 Receiving a Call