That's the message I get when trying to conference in any remote site. Let me specify: we have several remote sites which we connect to via frame relay. I can conference the two phones sitting next to me (which are on the same network as the Callmanager) and any other phone on the local network. I can also conference my cell phone with the two phones next to me. Now, as soon as I hit the join button to get my remote site on the first line drops and I get the message "Cannot complete conference" on the phone. We're running CallManager 4.1 and using the G.729 codec for inter-site calls and G.711 for the "Conferencing" Region.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cannot complete conference
- Thread starter dheida
- Start date
- Thread starter
- #3
Unfortunately I don't have detailed knowledge of how this all works. I do know that we have a VG200 that has hardware DSP resources. Here's where I stand now, though. I changed the conferencing codec for one of my test remote location phones to use G.729 and the conference worked. But, here's the thing. We had some similar conferencing problems a while back that we ended with TAC on. TAC said that Conferencing should use G.711 and the others should use G.729. From my understanding this is backwards but it fixed whatever problem we were having at the time.
this should help you
Introducing the WAN into an IP telephony implementation forces the issue of voice compression. After a WAN-enabled network is implemented, voice compression between sites represents the recommended design choice to save WAN bandwidth. This choice presents the question of how WAN users use the conferencing services or IP-enabled applications, which support only G.711 voice connections. Using hardware-based Media Termination Point (MTP)/transcoding services to convert the compressed voice streams into G.711 provides the solution.
The MTP service can act either like the original software MTP resource or as a transcoding MTP resource. An MTP service can provide supplementary services such as hold, transfer, and conferencing when the service is using gateways and clients that do not support the H.323v2 feature of OpenLogicalChannel and CloseLogicalChannel with the EmptyCapabilitiesSet. MTP, which is available as a software feature, can run on Cisco CallManager or a separate Windows NT server. When MTP is running in software on Cisco CallManager, the resource supports 24 MTP sessions. When MTP is running on a separate Windows NT server, the resource supports up to 48 MTP sessions. The Cisco gateway modules can support this same functionality, but they provide the service in the hardware.
Observe the following design capabilities and requirements for MTP transcoding:
•Provision MTP transcoding resources appropriately for the number of IP WAN callers to G.711 endpoints.
•Each transcoder has its own jitter buffer of 20-40 ms.
The following summary gives caveats that apply to MTP transcoding:
•Make sure that each Cisco CallManager has its own MTP transcoding resource configured.
•If transcoding is required between Cisco CallManager clusters, make sure that the intercluster trunk is configured with an MTP resource. All calls between Cisco CallManager clusters will go through the MTPs.
•If all n MTP transcoding sessions are utilized, and an n + 1 connection is attempted, the next call will complete without using the MTP transcoding resource. If this call attempted to use the software MTP function to provide supplementary services, the call would connect, but any attempt to use supplementary services would fail and could result in call disconnection. If the call attempted to use the transcoding features, the call would connect directly, but no audio would be received. If a transcoder is required but not available, the call would not connect.
For specific information on the number of sessions that are supported, see the "Supported Cisco Catalyst Gateways and Cisco Access Routers" section.
IP-to-IP Packet Transcoding and Voice Compression
You can configure voice compression between IP phones through the use of regions and locations in Cisco CallManager. However, the Cisco Catalyst conferencing services and some applications currently support only G.711, or uncompressed, connections. For these situations, MTP transcoding or packet-to-packet gateway functionality provides modules for the Cisco Catalyst 4000 and Cisco Catalyst 6000. A packet-to-packet gateway designates a device with DSPs that has the job of transcoding between voice streams by using different compression algorithms. For example, a user on an IP phone at a remote location calls a user at the central location. Cisco CallManager instructs the remote IP phone to use compressed voice, or G.729a, only for the WAN call. If the called party at the central site is unavailable, the call may roll to an application that supports G.711 only. In this case, a packet-to-packet gateway transcodes the G.729a voice stream to G.711 to leave a message with the voice-messaging server.
Voice Compression, IP-to-IP Packet Transcoding, and Conferencing
Connecting sites across an IP WAN for conference calls presents a complex scenario. In this scenario, the modules must perform the conferencing service as well as the IP-to-IP transcoding service to uncompress the WAN IP voice connection. In Figure 25-1, a remote user joins a conference call at the central location. This three-participant conference call uses seven DSP channels on the Catalyst 4000 module and three DSP channels on the Cisco Catalyst 6000. The following list gives the channel usage:
•Cisco Catalyst 4000
–One DSP channel to convert the IP WAN G.729a voice call into G.711
–Three conferencing DSP channels to convert the G.711 streams into TDM for the summing DSP
–Three channels from the summing DSP to mix the three callers together
•Cisco Catalyst 6000
–Three conferencing DSP channels. On the Cisco Catalyst 6000, all voice streams get sent to single logical conferencing port where all transcoding and summing takes place.
Figure 25-1 Multisite WAN Using Centralized MTP Transcoding and Conferencing Services
IP-to-IP Packet Transcoding Across Intercluster Trunks
Intercluster trunks connect Cisco CallManager clusters. Intercluster trunks allocate a transcoder on a dynamic basis.
The Cisco Catalyst 6000 module uses the MTP service regardless of whether transcoding is needed for a particular intercluster call. Cisco CallManager supports compressed voice call connection through the MTP service if a hardware MTP is used.
The following list gives intercluster MTP/transcoding details:
•Outbound intercluster calls will use an MTP/transcoding resource from the Cisco CallManager from which the call originates.
•Inbound intercluster call will use the MTP/resource from the Cisco CallManager that terminates the inbound intercluster trunk.
•Allocate additional DSP MTP/transcoding resources to Cisco CallManagers terminating intercluster trunks.
•For compressed callers, you can accurately provision the MTP transcoding resources.
Hardware-Based Conferencing Services
Hardware-enabled conferencing designates the ability to support voice conferences by using DSPs to perform the mixing of voice streams to create multiparty conference sessions. The voice streams connect to conferences through packet or time-division-multiplexing (TDM) interfaces.
The network modules, depending on the type, support both uncompressed and compressed VOIP conference calls. The modules use Skinny Client Control Protocol to communicate with Cisco CallManager to provide conferencing services. When the conferencing service registers with Cisco CallManager, it announces that only G.711 calls can connect to the conference. If any compressed calls request to join a conference, Cisco CallManager connects them to a transcoding port first to convert the compressed call to G.711.
Observe the following recommendations when you are configuring conferencing services:
•When you are provisioning an enterprise with conference ports, first determine how many callers will attempt to join the conference calls from a compressed Cisco CallManager region. After you know the number of compressed callers, you can accurately provision the MTP transcoding resources.
•Conference bridges can register with more than one Cisco CallManager at a time, and Cisco CallManagers can share DSP resources through the Media Resource Manager (MRM).
For specific information on the number of sessions that are supported, see the "Supported Cisco Catalyst Gateways and Cisco Access Routers" section.
Introducing the WAN into an IP telephony implementation forces the issue of voice compression. After a WAN-enabled network is implemented, voice compression between sites represents the recommended design choice to save WAN bandwidth. This choice presents the question of how WAN users use the conferencing services or IP-enabled applications, which support only G.711 voice connections. Using hardware-based Media Termination Point (MTP)/transcoding services to convert the compressed voice streams into G.711 provides the solution.
The MTP service can act either like the original software MTP resource or as a transcoding MTP resource. An MTP service can provide supplementary services such as hold, transfer, and conferencing when the service is using gateways and clients that do not support the H.323v2 feature of OpenLogicalChannel and CloseLogicalChannel with the EmptyCapabilitiesSet. MTP, which is available as a software feature, can run on Cisco CallManager or a separate Windows NT server. When MTP is running in software on Cisco CallManager, the resource supports 24 MTP sessions. When MTP is running on a separate Windows NT server, the resource supports up to 48 MTP sessions. The Cisco gateway modules can support this same functionality, but they provide the service in the hardware.
Observe the following design capabilities and requirements for MTP transcoding:
•Provision MTP transcoding resources appropriately for the number of IP WAN callers to G.711 endpoints.
•Each transcoder has its own jitter buffer of 20-40 ms.
The following summary gives caveats that apply to MTP transcoding:
•Make sure that each Cisco CallManager has its own MTP transcoding resource configured.
•If transcoding is required between Cisco CallManager clusters, make sure that the intercluster trunk is configured with an MTP resource. All calls between Cisco CallManager clusters will go through the MTPs.
•If all n MTP transcoding sessions are utilized, and an n + 1 connection is attempted, the next call will complete without using the MTP transcoding resource. If this call attempted to use the software MTP function to provide supplementary services, the call would connect, but any attempt to use supplementary services would fail and could result in call disconnection. If the call attempted to use the transcoding features, the call would connect directly, but no audio would be received. If a transcoder is required but not available, the call would not connect.
For specific information on the number of sessions that are supported, see the "Supported Cisco Catalyst Gateways and Cisco Access Routers" section.
IP-to-IP Packet Transcoding and Voice Compression
You can configure voice compression between IP phones through the use of regions and locations in Cisco CallManager. However, the Cisco Catalyst conferencing services and some applications currently support only G.711, or uncompressed, connections. For these situations, MTP transcoding or packet-to-packet gateway functionality provides modules for the Cisco Catalyst 4000 and Cisco Catalyst 6000. A packet-to-packet gateway designates a device with DSPs that has the job of transcoding between voice streams by using different compression algorithms. For example, a user on an IP phone at a remote location calls a user at the central location. Cisco CallManager instructs the remote IP phone to use compressed voice, or G.729a, only for the WAN call. If the called party at the central site is unavailable, the call may roll to an application that supports G.711 only. In this case, a packet-to-packet gateway transcodes the G.729a voice stream to G.711 to leave a message with the voice-messaging server.
Voice Compression, IP-to-IP Packet Transcoding, and Conferencing
Connecting sites across an IP WAN for conference calls presents a complex scenario. In this scenario, the modules must perform the conferencing service as well as the IP-to-IP transcoding service to uncompress the WAN IP voice connection. In Figure 25-1, a remote user joins a conference call at the central location. This three-participant conference call uses seven DSP channels on the Catalyst 4000 module and three DSP channels on the Cisco Catalyst 6000. The following list gives the channel usage:
•Cisco Catalyst 4000
–One DSP channel to convert the IP WAN G.729a voice call into G.711
–Three conferencing DSP channels to convert the G.711 streams into TDM for the summing DSP
–Three channels from the summing DSP to mix the three callers together
•Cisco Catalyst 6000
–Three conferencing DSP channels. On the Cisco Catalyst 6000, all voice streams get sent to single logical conferencing port where all transcoding and summing takes place.
Figure 25-1 Multisite WAN Using Centralized MTP Transcoding and Conferencing Services
IP-to-IP Packet Transcoding Across Intercluster Trunks
Intercluster trunks connect Cisco CallManager clusters. Intercluster trunks allocate a transcoder on a dynamic basis.
The Cisco Catalyst 6000 module uses the MTP service regardless of whether transcoding is needed for a particular intercluster call. Cisco CallManager supports compressed voice call connection through the MTP service if a hardware MTP is used.
The following list gives intercluster MTP/transcoding details:
•Outbound intercluster calls will use an MTP/transcoding resource from the Cisco CallManager from which the call originates.
•Inbound intercluster call will use the MTP/resource from the Cisco CallManager that terminates the inbound intercluster trunk.
•Allocate additional DSP MTP/transcoding resources to Cisco CallManagers terminating intercluster trunks.
•For compressed callers, you can accurately provision the MTP transcoding resources.
Hardware-Based Conferencing Services
Hardware-enabled conferencing designates the ability to support voice conferences by using DSPs to perform the mixing of voice streams to create multiparty conference sessions. The voice streams connect to conferences through packet or time-division-multiplexing (TDM) interfaces.
The network modules, depending on the type, support both uncompressed and compressed VOIP conference calls. The modules use Skinny Client Control Protocol to communicate with Cisco CallManager to provide conferencing services. When the conferencing service registers with Cisco CallManager, it announces that only G.711 calls can connect to the conference. If any compressed calls request to join a conference, Cisco CallManager connects them to a transcoding port first to convert the compressed call to G.711.
Observe the following recommendations when you are configuring conferencing services:
•When you are provisioning an enterprise with conference ports, first determine how many callers will attempt to join the conference calls from a compressed Cisco CallManager region. After you know the number of compressed callers, you can accurately provision the MTP transcoding resources.
•Conference bridges can register with more than one Cisco CallManager at a time, and Cisco CallManagers can share DSP resources through the Media Resource Manager (MRM).
For specific information on the number of sessions that are supported, see the "Supported Cisco Catalyst Gateways and Cisco Access Routers" section.
- Thread starter
- #5
no prob
yeah its a bit confusing but a few reads later I get most of teh message i believe. Th eimportant parts i think:
This choice presents the question of how WAN users use the conferencing services or IP-enabled applications, which support only G.711 voice connections. Using hardware-based Media Termination Point (MTP)/transcoding services to convert the compressed voice streams into G.711 provides the solution.
However, the Cisco Catalyst conferencing services and some applications currently support only G.711, or uncompressed, connections
A packet-to-packet gateway designates a device with DSPs that has the job of transcoding between voice streams by using different compression algorithms. For example, a user on an IP phone at a remote location calls a user at the central location. Cisco CallManager instructs the remote IP phone to use compressed voice, or G.729a, only for the WAN call. If the called party at the central site is unavailable, the call may roll to an application that supports G.711 only. In this case, a packet-to-packet gateway transcodes the G.729a voice stream to G.711 to leave a message with the voice-messaging server.
When the conferencing service registers with Cisco CallManager, it announces that only G.711 calls can connect to the conference. If any compressed calls request to join a conference, Cisco CallManager connects them to a transcoding port first to convert the compressed call to G.711.
yeah its a bit confusing but a few reads later I get most of teh message i believe. Th eimportant parts i think:
This choice presents the question of how WAN users use the conferencing services or IP-enabled applications, which support only G.711 voice connections. Using hardware-based Media Termination Point (MTP)/transcoding services to convert the compressed voice streams into G.711 provides the solution.
However, the Cisco Catalyst conferencing services and some applications currently support only G.711, or uncompressed, connections
A packet-to-packet gateway designates a device with DSPs that has the job of transcoding between voice streams by using different compression algorithms. For example, a user on an IP phone at a remote location calls a user at the central location. Cisco CallManager instructs the remote IP phone to use compressed voice, or G.729a, only for the WAN call. If the called party at the central site is unavailable, the call may roll to an application that supports G.711 only. In this case, a packet-to-packet gateway transcodes the G.729a voice stream to G.711 to leave a message with the voice-messaging server.
When the conferencing service registers with Cisco CallManager, it announces that only G.711 calls can connect to the conference. If any compressed calls request to join a conference, Cisco CallManager connects them to a transcoding port first to convert the compressed call to G.711.
- Thread starter
- #7
You're exactly right, those are what helped me make the connection. The problem in our situation is that the TAC guy said "You should only use G.711 for the Conferencing region." Well I don't think he completely understood our situation as we have a lot of sites that are only on a 56k connection which G.711 will not support. That's obviously why we have the transcoding hardware. So, I have to go into CM and change all of the "slow" sites back to G.729 for conferencing which will allow them to conference.
- Status
Similar threads
- Locked
- Question