Как настроить переадресацию на телефоне cisco

You can apply call
forward to a busy or no-answer directory number based on the number that is
dialed to reach the directory number: the primary number, the secondary number,
or either of those numbers expanded by a dial-plan pattern.

Cisco Unified CME
automatically creates one POTS dial peer for each ephone-dn when it is assigned
a primary number. If the ephone-dn is assigned a secondary number, it creates a
second POTS dial peer. If the
dialplan-pattern command is used to expand the
primary and secondary numbers for ephone-dns, it creates two more dial peers,
resulting in the creation of the following four dial peers for the ephone-dn:

• A POTS dial peer
  for the primary number

• A POTS dial peer
  for the secondary number

• A POTS dial peer
  for the primary number as expanded by the
  dialplan-pattern command

• A POTS dial peer
  for the secondary number as expanded by the
  dialplan-pattern command

Call forwarding is
normally applied to all dial peers created for an ephone-dn. Selective call
forwarding allows you to apply call forwarding for busy or no-answer calls only
for the dial peers you have specified, based on the called number that was used
to route the call to the ephone-dn.

For example, the following commands set up a single ephone-dn (ephone-dn 5) with four dial peers:

telephony-service

 dialplan-pattern 1 40855501.. extension-length 4 extension-pattern 50..

ephone-dn 5

 number 5066 secondary 5067

In this example,
selective call forwarding can be applied so that calls are forwarded when:

• callers dial the
  primary number 5066.

• when callers
  dial the secondary number 5067.

• when callers
  dial the expanded numbers 4085550166 or 4085550167.

For configuration
information, see
Enable Call Forwarding for a Directory Number.

Transfers to all
numbers except those on local phones are automatically blocked by default.
During configuration, you can allow transfers to nonlocal numbers. In
Cisco Unified CME 4.0 and later versions, you can prevent individual phones
from transferring calls to numbers that are globally enabled for transfer. This
ensures that individual phones do not incur toll charges by transferring calls
outside the Cisco Unified CME system. Call transfer blocking can be configured
for individual phones or configured as part of a template that is applied to a
set of phones.

Another way to
eliminate toll charges on call transfers is to limit the number of digits that
phone users can dial when transferring calls. For example, if you specify a
maximum of eight digits in the configuration, users who are transferring calls
can dial one digit for external access and seven digits more, which is
generally enough for a local number but not a long-distance number. In most
locations, this plan will limit transfers to nontoll destinations.
Long-distance calls, which typically require ten digits or more, will not be
allowed. This configuration is only necessary when global transfer to numbers
outside the Cisco Unified CME system has been enabled using the
transfer-pattern (telephony-service) command.
Transfers to numbers outside the Cisco Unified CME system are not permitted by
default.

For configuration
information, see
Configure Call Transfer Options for SCCP Phones.

The
transfer-pattern command for Cisco Unified SCCP IP
phones is extended to Cisco Unified SIP IP phones.

transfer-pattern transfer-pattern [ blind]  

Note	The blind keyword in the transfer-pattern command applies to Cisco Unified SCCP IP phones only and does not apply to Cisco Unified SIP IP phones.

With the
transfer-pattern command configured, only call
transfers to numbers that match the configured transfer pattern are allowed to
take place. With the transfer pattern configured, all or a subset of transfer
numbers can be dialed and the transfer to a remote party can be initiated.

Note	In Cisco Unified CME 9.5 and later versions, Cisco Unified SIP IP phones and Cisco Unified SCCP IP phones registered to the same Cisco Unified CME are considered local and do not require transfer-pattern configuration.

The following are
examples of configurable transfer patterns:

• .T—This
  configuration allows call transfers to any destinations with one or more
  digits, like 123, 877656, or 76548765.

• 919……..—This
  configuration only allows call transfers to remote numbers beginning with “919”
  and followed by eight digits, like 91912345678. However, call transfers to
  9191234 or 919123456789 are not allowed.

The
transfer max-length command is used to indicate
the maximum length of the number being dialed for a call transfer. When only a
specific number of digits are to be allowed during a call transfer, a value
between 3 and 16 is configured. When the number dialed exceeds the maximum
length configured, then the call transfer is blocked.

For example, the maximum length is configured as 5, then only call
transfers from Cisco Unified SIP IP phones up to a five-digit directory number
are allowed. All call transfers to directory numbers with more than five digits
are blocked.

Note	If only transfer max length is configured and conference max-length is not configured, then transfer max-length takes effect for transfers and conferences.

Conference calls are allowed when:

• both
  conference transfer-pattern and
  transfer-pattern commands are configured

• dialed digits match the configured transfer pattern

When conference
max-length command is configured, the Cisco Unified CME will allow the
conferences only if the dialed digits are within the max-length limit.

If configured, the
conference max-length command does not impact call transfers.

Note	If both conference max-length and transfer max-length commands are configured, the conference max-length command takes precedence for conferences.

The
conference-pattern blocked command is used to prevent extensions on an ephone
or a voice register pool from initiating conferences.

SUMMARY STEPS

1. enable
2. configure
   terminal

3. Enter one of the following commands:
• voice register pool pool-tag
• voice register template template-tag
• ephone phone-tag
• ephone template template-tag
4. conference
   max-length value

5. exit

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# voice register pool 25

Router(config-register-pool)# conference max-length 6

Router(config-register-pool)# exit

SUMMARY STEPS

1. enable
2. configure
   terminal

3. Enter one of the following commands:
• voice register pool pool-tag or
• voice register template
  template-tag
• ephone
  phone-tag
• ephone template
  template-tag
4. conference-pattern blocked
5. exit

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# voice register pool 25

Router(config-register-pool)# 

Router(config-register-pool)# exit

When the
transfer-pattern
blocked command is configured for a specific phone, no call
transfers are allowed from that phone over the trunk.

This feature forces
unconditional blocking of all call transfers from the specific phone to any
other non-local numbers (external calls from one trunk to another trunk). No
call transfers from this specific phone are possible even when a transfer
pattern matches the dialed digits for transfer.

Table 1
compares the behaviors of Cisco Unified SCCP and SIP IP phones for specific
configurations.

When both the
transfer-pattern and
conference
transfer-pattern commands are configured and the dialed digits match the
configured transfer pattern, conference calls are allowed. However, when the
dialed digits do not match any of the configured transfer pattern, the
conference call is blocked.

For configuration
information, see
Specify Transfer Patterns for Trunk-to-Trunk Calls and Conferences for SIP
and
Conference-Pattern Blocked
and
Conference Max-Length.

For configuration
examples, see
Example for Configuring Conference Transfer Patterns,

Example for Configuring Maximum Length of Transfer Number,

Example for Configuring Transfer Patterns,
and
Example for Blocking All Call Transfers.

The Call Transfer
Recall feature in Cisco Unified CME 4.3 and later versions returns a
transferred call to the phone that initiated the transfer if the destination is
busy or does not answer. After a phone user completes a transfer to a directory
number on a local phone, if the transfer-to party does not answer before the
configured recall timer expires, the call is directed back to the transferor
phone. The message “Transfer Recall From
xxxx” displays
on the transferor phone.

The transfer-to
directory number cannot have Call Forward Busy enabled, or it cannot be a hunt
group pilot number. If the transfer-to directory number has Call Forward No
Answer (CFNA) enabled, Cisco Unified CME recalls the call only if the
transfer-recall timeout is set to less than the CFNA timeout. If the
transfer-recall timeout is set to more than the CFNA timeout, the call is
forwarded to the CFNA target number after the transfer-to party does not
answer.

If the transferor
phone is busy, Cisco Unified CME attempts the recall again after the
transfer-recall timeout value expires. Cisco Unified CME attempts a recall up
to three times. If the transferor phone remains busy, the call is disconnected
after the third recall attempt.

The transferor phone
and transfer-to phone must be registered to the same Cisco Unified CME, however
the transferee phone can be remote.

For configuration
information, see
Enable Call Transfer and Forwarding on SCCP Phones at System-Level.

From Unified CME
11.6 onwards, Call Transfer Recall feature is supported on SIP phones. This
feature returns a transferred call to the phone that initiated the transfer if
the destination is busy or does not answer. After a phone user completes a
transfer to a directory number on a local SIP phone, and if the transfer-to
party does not answer before the configured recall timer expires, the call is
directed back to the transferor phone. The message «Transfer Recall From xxxx » displays on the
transferor phone.

The Call Transfer
Recall in SIP phones is achieved using the CLI
timeouts
transfer-recall command in voice register dn or voice register global
configuration modes.

The transfer-to
directory number cannot have Call Forward Busy enabled, or it cannot be a hunt
group pilot number. The transferor phone and transfer-to phone must be
registered to the same Cisco Unified CME, however the transferee phone can be
remote. If the transfer-to directory number has Call Forward No Answer (CFNA)
enabled, Cisco Unified CME recalls the call only if the transfer-recall timeout
is set to less than the CFNA timeout. If the transfer-recall timeout is set to
more than the CFNA timeout, the call is forwarded to the CFNA target number
after the transfer-to party does not answer. If the transfer-recall timeout is
equal to the CFNA timeout, the call is forwarded to the CFNA target number as
the CFNA timeout expires before the transfer-recall timeout.

When Call Forward
All is configured in Cisco Unified CME, the call is forwarded directly to call
forward target number irrespective of whether the phone is busy or idle. In
this scenario, transfer recall is not applicable after the call is forwarded.

If the transferor
phone is busy, Cisco Unified CME attempts the recall again after the
transfer-recall timeout value expires. Cisco Unified CME attempts a recall up
to three times. If the transferor phone remains busy, the call is disconnected
after the third recall attempt. Also, if the transferor phone is a shared line,
and if one of the phones is idle, the transfer recall is directed to the
transferor phone that is idle.

When Single Number
Reach (SNR) is configured in Cisco Unified CME, the desk IP Phone rings first.
If the desk IP Phone does not answer within the configured SNR timer expiry
value, the configured remote number (mobile) starts ringing while continuing to
ring the desk IP Phone. If both the extensions does not answer the call,
transfer recall is directed back to the transferor phone. Transfer recall does
not happen if the desk IP Phone or remote phone (mobile) is busy. Also,
transfer recall does not happen if one of the SNR extensions answers the call.

For configuration
information, see
Enable Call-Transfer Recall on SIP Phones at System-Level.

From Cisco Unified
CME release 11.6 onwards, call transfer recall feature supports mixed
deployment of SCCP and SIP phones. In a mixed deployment scenario, you can have
a SIP phone as transferor and with an SCCP phone being transfer-to or vice
versa.

In mixed mode, if
the transfer recall is performed with multiple SIP or SCCP transferors and a
single transfer-to SCCP phone, transfer recall display messages are displayed
on both the transferors. Here, transfer recall happens for all the calls when
the destination is busy or does not answer the call. In the case of single
transfer-to SIP phones, only the first phone call is recalled even if dual-line
is configured.

Cisco Unified CME
4.3 modifies the digit-collection process for consultative call transfers.
After a phone user presses the Transfer soft key to make a consultative
transfer, a new consultative call leg is created and the Transfer soft key is
not displayed again until the dialed digits of the transfer-to number are
matched to a transfer pattern and the consultative call leg is in the alerting
state.

Transfer-to digits
dialed by the phone user are no longer buffered. The dialed digits, except the
call park FAC code, are collected on the seized consultative call-leg until the
digits match a pattern for consultative transfer, blind transfer, park-slot
transfer, park-slot transfer blocking, or PSTN transfer blocking. The existing
pattern matching process is unchanged, and you have the option of using this
new transfer digit-collection method or reverting to the former method.

Before Cisco Unified
CME 4.3, the consultative transfer feature collects dialed digits on the
original call leg until the digits either match a transfer pattern or blocking
pattern. When the transfer-to number is matched, and PSTN blocking is not
enabled, the original call is put on hold and an idle line or channel is seized
to send the dialed digits from the buffer.

The method of
matching a pattern for consultative transfer, blind transfer, park-slot
transfer, park-slot transfer blocking, PSTN transfer blocking, and after-hours
blocking remain the same. When the transfer-to number matches the pattern for a
blind transfer or park-slot transfer, Cisco Unified CME terminates the
consultative call leg and transfers the call.

After the
transfer-to digits are collected, if the transfer is not committed before the
transfer-timeout expires in 30 seconds, the consultation call leg is
disconnected.

These enhancements
are supported only if:

• The
  transfer-system
  full-consult command (default) is set in telephony-service
  configuration mode.

• The
  transfer-mode
  consult command (default) is set for the transferor’s directory
  number (ephone-dn).

• An idle line or channel is
  available for seizing, digit collection, and dialing.

Cisco Unified CME 4.3 and later versions enable these transfer
enhancements by default.

To revert to the
digit-collection method used in previous versions of Cisco Unified CME, see
Enable Call Transfer and Forwarding on SCCP Phones at System-Level.

Direct Station
Select (DSS) is a feature that allows a multi-button phone user to transfer
calls to an idle monitored line by pressing the Transfer key and the
appropriate monitored line button. A monitored line is one that appears on two
phones; one phone can use the line to make and receive calls and the other
phone simply monitors whether the line is in use. For Cisco CME 3.2 and later
versions, consultative transfers can occur during Direct Station Select
(transferring calls to idle monitored lines).

If the person
sharing the monitored line does not want to accept the call, the person
announcing the call can reconnect to the incoming call by pressing the EndCall
soft key to terminate the announcement call and pressing the Resume soft key to
reconnect to the original caller.

Direct Station Select consultative transfer is enabled with the transfer-system full-consult dss command, which defines the call transfer method for all lines served by the router. The transfer-system full-consult dss command supports the keep-conference command. See Configure Hardware Conferencing.

Use H.450 standards
when a network meets the following conditions:

• The router that
  you are configuring uses Cisco CME 3.0 or a later version, or Cisco ITS V2.1.

• For Cisco CME
  3.0 or Cisco ITS V2.1 systems, all endpoints in the network must support
  H.450.2 and H.450.3 standards. For Cisco CME 3.1 or later systems, if some of
  the endpoints do not support H.450 standards (for example,
  Cisco Unified Communications Manager, Cisco BTS, or Cisco PGW), you can use
  hairpin call routing or an H.450 tandem gateway to handle transfers and
  forwards with those endpoints. Also, either you must explicitly disable H.450.2
  and H.450.3 on the dial peers that handle those calls or you must enable
  H.450.12 capability to automatically detect the calls that support H.450.2 and
  H.450.3 and those calls that do not.

Support for the
H.450.2 standard and the H.450.3 standard is enabled by default and can be
disabled globally or for individual dial peers. For configuration information,
see
Enable Call Transfer and Forwarding on SCCP Phones at System-Level.

You must specify the
method to use for call transfers: H.450.2 standard signaling or Cisco
proprietary signaling, and whether transfers should be blind or allow
consultation.
Table 1
summarizes transfer method recommendations for all Cisco Unified CME versions.

Cisco CME 3.1 and
later versions support the H.450.12 call capabilities standard, which provides
a means to advertise and dynamically discover H.450.2 and H.450.3 capabilities
in voice gateway endpoints on a call-by-call basis. When discovered, the calls
associated with non-H.450 endpoints can be directed to use non-H.450 methods
for transfer and forwarding, such as hairpin call routing or H.450 tandem
gateway.

When H.450.12 is
enabled, H.450.2 and H.450.3 services are disabled for call transfers and call
forwards unless a positive H.450.12 indication is received from all other VoIP
endpoints involved in the call. If a positive H.450.12 indication is received,
the router uses the H.450.2 standard for call transfers and the H.450.3
standard for call forwarding. If a positive H.450.12 indication is not
received, the router uses the alternative method that you have configured for
call transfers and forwards, either hairpin call routing or an H.450 tandem
gateway.

You can have either
of the following situations in your network:

• All gateway endpoints
  support H.450.2 and H.450.3 standards. In this situation, no special
  configuration is required because support for H.450.2 and H.450.3 standards is
  enabled on the Cisco CME 3.1 or later router by default. H.450.12 capability is
  disabled by default, but it is not required because all calls can use H.450.2
  and H.450.3 standards.

• Not all gateway endpoints
  support H.450.2 and H.450.3 standards. Therefore, specify how non-H.450 calls
  are to be handled by choosing one of the following options:
  • Enable the H.450.12 capability in
    Cisco CME 3.1 and later to dynamically determine, on a call-by-call basis,
    whether each call has H.450.2 and H.450.3 support. If H.450.12 is enabled and a
    call is determined to have H.450 support, the call is transferred using H.450.2
    standards or forwarded using H.450.3 standards. See
    Enable H.450.12 Capabilities.

    Support for
    the H.450.12 standard is disabled by default and can be enabled globally or for
    individual dial peers.

    If the call
    does not have H.450 support, it can be handled by a VoIP-to-VoIP connection
    that you configure using dial peers and
    Enable H.323-to-H.323 Connection Capabilities.
    The connection can be used for hairpin call routing or routing to an H.450
    tandem gateway.

  • Explicitly disable H.450.2 and H.450.3
    capability on a global basis or by individual dial peer, which forces all calls
    to be handled by a VoIP-to-VoIP connection that you configure using dial peers
    and the
    Enable H.323-to-H.323 Connection Capabilities.
    This connection can be used for hairpin call routing or routing to an H.450
    tandem gateway.

Cisco CME 3.1 and
later supports hairpin call routing using a VoIP-to-VoIP connection to transfer
and forward calls that cannot use H.450 standards. When a call that originally
terminated on a voice gateway is transferred or forwarded by a phone or other
application attached to the gateway, the gateway reoriginates the call and
routes the call as appropriate, making a VoIP-to-VoIP, or hairpin, connection.
This approach avoids any protocol dependency on the far-end transferred-party
endpoint or transfer-destination endpoint. Hairpin routing of transferred and
forwarded calls also causes the generation of separate billing records for each
call leg, so that the transferred or forwarded call leg is typically billed to
the user who initiates the transfer or forward.

In Cisco CME 3.2 and
later versions, transcoding between G.711 and G.729 is supported when one leg
of a VoIP-to-VoIP hairpin call uses G.711 and the other leg uses G.729.

Hairpin call routing
provides the following benefits:

• Call transfer and
  forwarding is provided to non-H.450 endpoints, such as
  Cisco Unified Communications Manager, Cisco BTS, or Cisco PGW.

• The network can also
  contain Cisco CME 3.0 or Cisco ITS 2.1 systems.

Hairpin call routing
has the following disadvantages:

• End-to-end signaling and
  media delay are increased significantly.

• A single hairpinned call
  uses as much WAN bandwidth as two directly connected calls.

VoIP-to-VoIP hairpin
connections can be made using dial peers if the
allow-connections
h323 to h323 command is enabled and at least one of the following is true:

• H.450.12 is used to detect
  calls on which H.450.2 or H.450.3 is not supported by the remote system.

• H.450.2 or H.450.3 is
  explicitly disabled.

• Cisco Unified CME automatically
  detects that the remote system is a Cisco Unified Communications Manager.

Hairpin with
H.323: A Calls B
shows a call that is made from A to B.
Hairpin with
H.323: Call is Forwarded to C
shows that B has forwarded all calls to C.
Hairpin with
H.323: A is Connected to C via B
shows that A and C are connected by an H.323 hairpin.

H.450 tandem
gateways address the limitations of hairpin call routing using a manner similar
to hairpin call routing but without the double WAN link traversal created by
hairpin connections. An H.450 tandem gateway is an additional voice gateway
that serves as a “front-end” for a call processor that does not support the
H.450 standards, such as Cisco Unified Communications Manager, Cisco BTS
Softswitch (Cisco BTS), or Cisco PSTN Gateway (Cisco PGW). Transferred and
forwarded calls that are intended for non-H.450 endpoints are terminated
instead on the H.450 tandem gateway and reoriginated there for delivery to the
non-H.450 endpoints. The H.450 tandem gateway can also serve as a PSTN gateway.

An H.450 tandem
gateway is configured with a dial peer that points to the
Cisco Unified Communications Manager or other system for which the H.450 tandem
gateway is serving as a front end. The H.450 tandem voice gateway is also
configured with dial peers that point to all the Cisco Unified CME systems in
the private H.450 network. In this way, Cisco Unified CME and the
Cisco Unified Communications Manager are not directly linked to each other, but
are instead both linked to an H.450 tandem gateway that provides H.450 services
to the non-H.450 platform.

An H.450 tandem
gateway can also work as a PSTN gateway for remote Cisco Unified CME systems
and for Cisco Unified Communications Manager (or other non-H.450 system). Use
different inbound dial peers to separate
Cisco Unified Communications Manager-to-PSTN G.711 calls from tandem
gateway-to-Cisco Unified CME G.729 calls.

Note

An H.450 tandem gateway that is used in a network to support non-H.450-capable call processing systems requires the Integrated Voice and Video Services feature license. This feature license, which was introduced in March 2004, includes functionality for H.323 gatekeeper, IP-to-IP Gateway, and H.450 tandem gateway. With Cisco IOS Release 12.3(7)T, an H.323 gatekeeper feature license is required with a JSX Cisco IOS image on the selected router. Consult your Cisco Unified CME SE regarding the required feature license. With Cisco IOS Release 12.3(7)T, you cannot use Cisco Unified CME and H.450 tandem gateway functionality on the same router.

VoIP-to-VoIP
connections can be made for an H.450 tandem gateway if the
allow-connections
h323 to h323 command is enabled and one or more of the following is true:

• H.450.12 is used
  to dynamically detect calls on which H.450.2 or H.450.3 is not supported by the
  remote VoIP system.

• H.450.2 or
  H.450.3 is explicitly disabled.

• Cisco CME 3.1 or
  later automatically detects that the remote system is a
  Cisco Unified Communications Manager.

For Cisco CME 3.1
and earlier, the only type of VoIP-to-VoIP connection supported by
Cisco Unified CME is H.323-to-H.323. For Cisco CME 3.2 and later versions,
H.323-to-SIP connections are allowed only for Cisco Unified CME systems running
Cisco Unity Express.

H.450 Tandem
Gateway
shows a tandem voice gateway that is located between the central hub of the
network of a CPE-based Cisco CME 3.1 or later network and a
Cisco Unified Communications Manager network. This topology would work equally
well with a Cisco BTS or Cisco PGW in place of the
Cisco Unified Communications Manager.

In the network
topology in
H.450 Tandem
Gateway,
the following events occur (refer to the event numbers on the illustration):

1. A call is
   generated from extension 4002 on phone 2, which is connected to a
   Cisco Unified Communications Manager. The H.450 tandem gateway receives the
   H.323 call and, acting as the H.323 endpoint, the H.450 tandem gateway handles
   the call connection to a Cisco Unified IP phone in a CPE-based Cisco CME 3.1 or
   later network.

2. The call is
   received by extension 1001 on phone 3, which is connected to Cisco Unified CME
   1. Extension 1001 performs a consultation transfer to extension 2001 on phone
   5, which is connected to Cisco Unified CME 2.

3. When extension
   1001 transfers the call, the H.450 tandem gateway receives an H.450.2 message
   from extension 1001.

4. The H.450 tandem
   gateway terminates the call leg from extension 1001 and reoriginates a call leg
   to extension 2001, which is connected to Cisco Unified CME 2.

5. Extension 4002
   is connected with extension 2001.

Dial peers describe
the virtual interfaces to or from which a call is established. All voice
technologies use dial peers to define the characteristics associated with a
call leg. Attributes applied to a call leg include specific quality of service
(QoS) features, compression/decompression (codec), voice activity detection
(VAD), and fax rate. Dial peers are also used to establish the routing paths in
your network, including special routing paths such as hairpins and H.450 tandem
gateways. Dial peer settings override the global settings for call forward and
call transfer.

Q Signaling (QSIG)
is an intelligent inter-PBX signaling system widely adopted by PBX vendors. It
supports a range of basic services, generic functional procedures, and
supplementary services. Cisco Unified CME 4.0 introduces supplementary services
features that allow Cisco Unified CME phones to seamlessly interwork using QSIG
with phones connected to a PBX. One benefit is that IP phones can use a PBX
message center with proper MWI notifications.
Cisco Unified CME System with PBX
illustrates a topology for a Cisco Unified CME system with some phones under
the control of a PBX.

The following QSIG
supplementary service features are supported in Cisco Unified CME systems. They
follow the standards from the European Computer Manufacturers Association
(ECMA) and the International Organization for Standardization (ISO) on PRI and
BRI interfaces.

• Basic calls between IP
  phones and PBX phones.

• Calling Line/Name
  identification (CLIP/CNIP) presented on an IP phone when called by a PBX phone;
  in the reverse direction, such information is provided to the called endpoint.

• Connected Line/Name identification
  (COLP/CONP) information provided when a PBX phone calls an IP phone and is
  connected; in the reverse direction, such information presented on an IP phone.

• Call Forward using QSIG and H.450.3 to
  support any combination of IP phone and PBX phone, including an IP phone in the
  Cisco Unified CME system that is connected to a PBX or an IP phone in another
  Cisco Unified CME system across an H.323 network.

• Call forward to the PBX message center
  according to the configured policy. The other two endpoints can be a mixture of
  IP phone and PBX phones.

• Hairpin call transfer, which
  interworks with a PBX in transfer-by-join mode. Note that Cisco Unified CME
  does not support the actual signaling specified for this transfer mode
  (including the involved FACILITY message service APDUs) which are intended for
  an informative purpose only and not for the transfer functionality itself. As a
  transferrer (XOR) host, Cisco Unified CME simply hairpins two call legs to
  create a connection; as a transferee (XEE) or transfer-to (XTO) host, it will
  not be aware of a transfer that is taking place on an existing leg. As a
  result, the final endpoint may not be updated with the accurate identity of its
  peer. Both blind transfer and consult transfer are supported.

• Message-waiting indicator (MWI)
  activation or deactivation requests are processed from the PBX message center.

• The PBX message center can be
  interrogated for the MWI status of a particular ephone-dn.

• A user can
  retrieve voice messages from a PBX message center by making a normal call to
  the message center access number.

For information
about enabling QSIG supplementary services, see
Enable H.450.7 and QSIG Supplementary Services at System-Level
and
Enable H.450.7 and QSIG Supplementary Services on a Dial Peer.

If a destination
gateway does not support supplementary services, you can disable REFER messages
for call transfers and the redirect responses for call forwarding from being
sent by Cisco Unified CME.

For configuration
information, see
Disable SIP Supplementary Services for Call Forward and Call Transfer.

In a mixed network that involves two or more types of call agents or
call-control systems, there can be communication protocol discrepancies and
dependencies, and therefore the opportunity for interoperability errors. These
discrepancies show up most often when a call is being transferred or forwarded.
This section provides descriptions of the specific mixed-network scenarios you
might encounter when configuring a router running Cisco CME 3.1 or a later
version. Each of the following sections point to the configuration instructions
necessary to ensure call transfer and forwarding capabilities throughout the
network.

Note

Cisco Communications Manager Express 3.2 (Cisco CME 3.2) and later versions provide full call-transfer and call-forwarding with call processing systems on the network that support H.450.2, H.450.3, and H.450.12 standards. For interoperability with call processing systems that do not support H.450 standards, Cisco CME 3.2 and later versions provide VoIP-to-VoIP hairpin call routing without requiring the special Tool Command Language (Tcl) script that was needed in earlier versions of Cisco Unified CME.

SUMMARY STEPS

1. enable
2. configure
   terminal

3. voice service voip
4. h323
5. telephony-service ccm-compatible
6. h225 h245-address on-connect
7. exit
8. supplementary-service h225-notify cid-update
9. exit
10. voice class h323
    tag

11. telephony-service
    ccm-compatible

12. h225 h245-address
    on-connect

13. exit
14. dial-peer
    voice
    tag
    voip

15. supplementary-service
    h225-notify cid-update

16. voice-class
    h323
    tag

17. end

DETAILED STEPS

Router> enable

Router# configure terminal

Router(config)# voice service voip

Router(conf-voi-serv)# h323

Router(conf-serv-h323)# telephony-service ccm-compatible

Router(conf-serv-h323)# h225 h245-address on-connect

Router(conf-serv-h323)# exit

Router(conf-voi-serv)# supplementary-service h225-notify cid-update

Router(config-voice-service)# exit

Router(config)# voice class h323 48

Router(config-voice-class)# telephony-service ccm-compatible

Router(config-voice-class)# h225 h245-address on-connect

Router(config-voice-class)# exit

Router(config)# dial-peer voice 28 voip

Router(config-dial-peer)# no supplementary-service h225-notify cid-update

Router(config-dial-peer)# voice-class h323 48

Router(config-dial-peer)# end