DTMF-Relay
Dual-Tone Multifrequency (DTMF) is the tone generated on a touch-tone phone when you press keypad digits. During a call you might enter DTMF to access Interactive Voice Response (IVR) systems such as voicemail, automated banking services and so on.
In previous releases of Cisco IOS, DTMF is transported in the same way as voice.
This approach can result in problems accessing IVR systems. While DTMF is usually transported accurately when using high-bitrate voice CODECs such as G.711, low-bitrate CODECs such as G.729 and G.723.1 are highly optimized for voice patterns, and tend to distort DTMF tones. As a result, IVR systems may not correctly recognize the tones.
DTMF relay solves the problem of DTMF distortion by transporting DTMF tones "out of band", or separate from the encoded voice stream.
Cisco H.323 Version 2 support introduces three options for sending DTMF tones out of band. These are:
•A Cisco proprietary RTP-based method ("dtmf-relay cisco-rtp").
•H.245 signal ("dtmf-relay h245-signal").
•H.245 alphanumeric ("dtmf-relay h245-alphanumeric").
If none of these options is selected, DTMF tones are transported inband, and encoded in the same way as voice traffic.
The "cisco-rtp" option sends DTMF tones in the same RTP channel as voice. However, the DTMF tones are encoded differently from the voice samples and are identified by a different RTP payload type code. Use of this method accurately transports DTMF tones, but since it is proprietary it requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.
- The "h245-signal" and "h245-alphanumeric" options are modes of DTMF transport defined by the ITU H.245 standard.
- These methods separate DTMF digits from the voice stream and send them through the H.245 signalling channel instead of the RTP channel.
- The tones are transported in H.245 User Input Indication messages.
- The H.245 signalling channel is a reliable channel, so the packets transporting the DTMF tones are guaranteed to be delivered. However, because of the overhead of using a reliable protocol, and depending on network congestion conditions, the DTMF tones may be slightly delayed. This delay is not known to cause problems with existing applications.
The "h245-signal" option relays a more accurate representation of a DTMF digit than the "h245-alphanumeric" option, in that tone duration information is included along with the digit value.
This information is important for applications that require you to press a key for a particular length of time. For example, one popular calling card feature allows you to break out of an existing call by pressing the (#) key for more than two seconds and then make a second call without having to hang up in between. This feature is beneficial because it allows you to avoid having to dial your access number and PIN code again, and it allows you to avoid access charges if you are charged for accessing an outside line as is common at hotels.
The "h245-alphanumeric" option simply relays DTMF tones as ASCII characters. For instance, the DTMF digit 1 is transported as the ASCII character "1". There is no duration information associated with tones in this mode.
When the Cisco H.323 gateway receives a DTMF tone using this method, it will generate the tone on the PSTN interface of the call using a fixed duration of 500 ms. All H.323 version 2 compliant systems are required to support the "h245-alphanumeric" method, while support of the "h245-signal" method is optional.
The ability of a gateway to receive DTMF digits in a particular format and the ability to send digits in that format are independent functions. To receive DTMF digits from another H.323 endpoint using any of the methods described above, no configuration is necessary. The Cisco H.323 version 2 gateway is capable of receiving DTMF tones transported by any of these methods at all times.
However, to send digits out of band using one of these methods, two conditions must be met:
1. You must enable the chosen method of DTMF relay under "dial-peer" configuration using the "dtmf-relay" command.
2. The peer (the other endpoint of the call) must indicate during call establishment that it is capable of receiving DTMF in that format.
You may enable more than one DTMF relay option for a particular dial peer. If you enable more than one option, and if the peer indicates that it is capable of receiving DTMF in more than one of these formats then the gateway will send DTMF using the method among the supported formats that it considers to be the most preferred. The preferences are defined as follows:
1. cisco-rtp (highest preference)
If the peer is not capable of receiving DTMF in any of the modes that you have enabled, DTMF tones will be sent inband.
When the Cisco H.323 version 2 gateway is involved in a call to a Cisco gateway running a version of IOS prior to 12.0(5)T, DTMF tones will be sent inband since those systems do not support DTMF relay.
Hookflash Relay (hookflash as a means of switching between calls if you subscribe to a call waiting service.)
A "hookflash" indication is a brief on-hook condition that occurs during a call. It is not long enough in duration to be interpreted as a signal to disconnect the call. You can create a hookflash indication by quickly depressing and then releasing the hook on your telephone.
PBXs and telephone switches are frequently programmed to intercept hookflash indications and use them as a way to allow a user to invoke supplemental services. For example, your local service provider may allow you to enter a hookflash as a means of switching between calls if you subscribe to a call waiting service.
In the traditional telephone network a hookflash results in a voltage change on the telephone line. Since there is no equivalent of this voltage change in an IP network, the ITU H.245 standard defines a message representing a hookflash. To send a hookflash indication using this message, an H.323 endpoint sends an H.245 User Input Indication message containing a "signal" structure with a value of "!". This value represents a hookflash indication.
Cisco H.323 Version 2 support includes limited support for relaying hookflash indications via H.245. H.245 User Input Indication messages containing hookflash indications that are received on the IP call leg are forwarded to the POTS call leg if the POTS interface is FXO. If the interface is not FXO, any H.245 hookflash indication that is received is ignored. This support allows IP telephony applications to send hookflash indications to a PBX through the Cisco gateway, and thereby invoke the PBX's supplementary services if the PBX supports access to those features via hookflash.
The gateway does not originate H.245 hookflash indications in this release. For example it does not forward hookflash indications from FXS interfaces to the IP network over H.245.
The acceptable duration of a hookflash indication varies by equipment vendor and by country. While one PBX may consider a 250 ms on-hook condition to be a hookflash, another PBX may consider this condition to be a disconnect. Therefore this release of IOS adds the "timing hookflash-out" command to allow the administrator to define the duration of a hookflash signal generated on an FXO interface.
CODEC Negotiation
CODEC negotiation allows the Gateway to offer several CODECs during the H.245 capability exchange phase and ultimately settle upon a single common CODEC during the call-establishment phase. This increases the probability of establishing a connection since there will be a greater chance of over-lapping audio capabilities between endpoints. Normally, only one CODEC can be specified when configuring a Dial-Peer, but CODEC negotiation allows you to specify a prioritized list of CODECs associated with a Dial-Peer. During the call-establishment phase the router will use the highest priority CODEC from the list which it has in common with the remote endpoint. It will also adjust to the CODEC selected by the remote endpoint so that a common CODEC is established for both the receive and transmit audio directions.
When a call is originated, all of the CODECs associated with the Dial-Peer are sent to the terminating endpoint in the H.245 Terminal Capability Set message. At the terminating endpoint, the gateway will advertise all of the CODECs that are available in firmware in its Terminal Capability Set. If there is a need to limit the CODECs advertised to a subset of the available CODECs, a terminating Dial-Peer must be matched which includes this subset. The "incoming called-number" command under the Dial-Peer can be used to force this match.
No comments:
Post a Comment