cme to cme meet-me conferencing bandwidth technique?

Unanswered Question
Apr 2nd, 2009

Can anyone share some information on how you do cme to cme meet-me conferening?

Here is a scneario with two CME's separated by a T1. CME1 conference has 30 participants using pure G.711 codec and CME2 conference has 31 participants usign pure G.711 codec.

- Why not just have one meet me conference and use g.729 codec? If you use G.729 codec your max conference participant will decrease from 32 (actually the max could be 64) to 8.

- Why not just have one meet me conference and use g.711 codec? g.711 uses 64kbps (payload only add another 16kbps) multiply that by 30 participants and you get a T1 bottleneck.

I am thinking that you can just bridge those two conference by forwarding CME1 conference to CME2 conference and the router would just see it as 1 G.711 rtp session, therefore conserving bandwidth. Is it that easy? has someone done this before? The thought just cross my mind by reading throught my ONT book and CCNP mentor video's.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
ivillegas Wed, 04/08/2009 - 11:14

Cisco Unified CME only supports three-party conference calls using a G.711 codec. This service supports conversion between G.711 mu-law and A-law and between G.711 and G.729. To allow callers who use a G.729 codec to join a conference, you need to specify the transcoding of G.729 to G.711 by using the dspfarm-assist keyword with the codec command, which allows the use of DSP resources on the router. DSP resources are limited, however, and there are disadvantages to using them for conferencing.

Meet-Me Conferencing in Cisco Unified CME 4.1 and Later versions:

Nicholas Matthews Wed, 04/08/2009 - 11:46

Using G.729 will significantly reduce your amount of participants because of the complexity.

You can configure a transcoder with the g729r8 assist keyword and it will transcode g729 calls to g711 so your conference will be g711 only.

You will get potentially bad results if you combine one conference with another. The conferencing DSPs take into fact the noise and volume level of each individual RTP streams to create the best possible RTP stream. When you have a stream that this has already occurred on, and has a mix of volume levels, you run the risk of doing misleading RTP stream mixing.



Paolo Bevilacqua Wed, 04/08/2009 - 11:54

I for one would be very curious of knowing the practical results of bridging two conferences.

I've found that often the cisco DSP implementation performs in a surprisingly good way.

sipr_ttgp Thu, 04/09/2009 - 07:11

Good, there is one person interested with the idea. I would do it if I have 2 CME's but I won't get my hand on the second one until next month.

You know I posted another technique to conserve bandwidth. If you just want to listen to conferences you can send the conference to a multicast address... You create a dn by:

ephone-dn 50

number 1100

name Multicast Bridge

feed ip port 2000

What you do is when you are in a conference you can transfer your connection to x1100 and the multicast feed will start. Then you can choose any program you want that can tune in to the rtp multicast ip and be able to decode g.711u codec. I use VLC for this matter. I even created a script like this:

cd "c:\Program Files\VideoLAN\VLC\"

vlc rtp://@

Cyberdata also make VOIP speakers that can tune in to this multicast feed up to 10 ip. I purchase one for testing but it has not arrive yet. The site's FAQ promise that it can do it and there's is nothing on the spec that tells me that it can't so it sounds promising.


This Discussion