[cisco-voip] Part 2: Conferencing Codecs Across WAN

pavan katta pav.ccie at gmail.com
Tue Jan 19 23:55:22 EST 2010


Jason,
Please see inline.

If you still have questions shoot me an email and we can talk.

-pavan


On Tue, Jan 19, 2010 at 9:15 PM, Rhodium <rhodium_uk at yahoo.co.uk> wrote:

> Hi Pavan,
>
> I think I understand but want to clarify a few things to make sure I got it
> if you don't mind...
>
> >
> > Assume phone b1 is in a conference with b2 and a1,
> >
>
> /* So phone b1 initiated the conference and hence this above conference is
> using the cfb in router B. */
>
 ==================

> [pavan] That is correct.
>
=====================

>
> > If a1 adds another party a2 to the conference, (conference
> > extension) a new rtp stream would flow from a2 to the cfb inals
> > site b
>
> /* So a1 then puts the original conference on hold and calls a2, a1 then
> pushes the cfrn button and a2 joins the cfb in router B because b1
> originally invoked the conference. I was under the impression that thought
> a1 would use its MRGL and hence the cfb would be router A  but it doesnt
> seem that this is the case in basic mode according to this link as only the
> conference host can join another participant:
>
>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/6_1_1/ccmsys/a05confb.html
>
> */
>
===========================

> [pavan] There is a service parameter called "Advanced Ad-hoc Enabled" which
> controls this behavior. If this paramter is set to False, only b1 can
> add/remove participants in the conference. If set to true, everybody can
> add/remove.
>
   Also a1 can press hold on his conference call, make a new call to a2 and
then join these together using Join softkey. Using Conference key is not the
easiest way to get it to work.
   The conference initiator's MRGL is used to allocate a CFB at the very
begining. As long as this conference call does not downgrade down to a 2
party call, the same CFB is reused for additional parties that are brought
into the conference.
=============================


> > If a1 places the existing call on hold and creates a new
> > conference with a2 and a3, now we have a conference resource
> > in site a which has rtp streams from a1,a2& a3. Assume
> > that a1 now joins both these conferences together with the
> > active call being the second conference call( conference
> > chaining), we will end up with conference1 containing b1,b2
> > and cfb in site a. Conference2 contains a1,a2,a3 and cfb
> > from site b.
> >
>
> /* I am assuming that this is an advanced linear conference as per the
> definition in the document, so any party can invoke a second conference */
>
 ==================

> [Pavan] When a1 is in a conference, he can always hold that conference call
> and make a new conference call. You don't need to enable "Advanced ad-hoc
> conference" for it. Advanced ad-hoc conference parameter comes into the
> picture when you want  to join the two conferences (called conference
> chaining) on b1. If you don't want to join these two conferennces, that
> parameter has no relevance.



> =================
> So basically, in advanced conferencing (whether linear or nonlinear), the
> RTP streams flow directly between the CFBs as well so if I have an example
> of two conferences in both site a and site b and I conference them in and if
> the default codec is g729, i can have only one g729 codec stream between the
> two CFBs conserving bandwidth as each participant is restricted to their own
> CFB.
>
> ==============================================
[pavan] If you had one conference in site a and another different conference
in site b, then you would be unable to chain them together as you don't have
a common phone to complete the conference chaining operation. However
assuming you have one RTP stream traversing the wan between the sites
before, you may end up with one or two RTP streams after the chaining. Let
me try to explain

Consider the following
conference1 uses CFB1 and is completely contained in siteA with a1,a2 and a3
in it and this conference was initiated by a1.
conference2 uses CFB2 and is completely contained in siteB with b1,b2 and b3
in it and this conference was initiated by b1.
Also assume that advanced ad-hoc service parameter is turned on (default
off).

Now assume that  one of the phones in Conference2 extends the conference by
bringing in a3 into the conference. (new call from a3's perspective). At
this time you have one RTP stream across your sites between a3 and CFB2. Now
a3 is the only phone who is capable of joining these two conferences
(chaining).

This is where it gets tricky, so pay attention
You would normally join these two conferences together using the Join key.
It can also be done using the conference key but join is simpler to
understand. It makes no behavioral difference which softkey is used.

At this point you would have one active call and one held call. Depending on
which call is held you will see different results.

CASE 1:
Conference1 call is Active call and Conference2 call is Held call.

When the Join key is pressed, you will see the following happen
 Conference1 will contain a1,a2,a3 and CFB2
 Conference2 will contain b1,b2,b3 and CFB1
 You will see one RTP stream across your sites between CFB1 and CFB2.


CASE 2:
Conference1 call is Held call and Conference2 call is Active call.

When the Join key is pressed, you will see the following happen
 Conference1 will contain a1,a2 and CFB2
 Conference2 will contain b1,b2,b3, a3 and CFB1
 You will see TWO RTP streams across your sites between (CFB1 and CFB2) and
(a3 and CFB2).

Phew!!
===========================================================

> Right?
>
> My head does hurt from this...
>
> Jason
>
>
>
>
>


-- 
-----------------------------------------------------------
Pavan Katta
CCVP,CCDP,CCNP,CCDA,CCNA
Development Engineer - Enterprise Voice
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100119/e69695da/attachment.html>


More information about the cisco-voip mailing list