Topology may get garble, hence describing the same as below.
IP Phone and CCM on one side. Two MGCP Gateways across MPLS having PSTN termination. There is point-to-point T1 between both Gateways. One incoming call (55555555) from MGCP GW 1 and one Outgoing Call via MGCP GW 2 (22222222). Now what happens when conference is initiated by IP phone user.
Following is the detailed summary:
G.729 codec on WAN. Two hardware conference bridges, CFB_GW1 and CFB_GW2. MRG has CFB_GW2 as first choice followed by CFB_GW1.
Phone no 55555555 calls ext 1001. Ext 1001 answers the call and presses the conference button. 1001 dials 22222222 via GW2. 22222222 answers the call and 1001 presses conference button and all three are in a conference call.
Question: Which conference bridge would be used here, CFB_GW1 or from CFB_GW2? Once 55555555 drops the call, how signaling and RTP will be flowing between 1001 and 22222222? Both MGCP GW are reachable to each other via point-to-point T1 (not shown in the topology aove).
What if MRG has CFB_GW1 as first choice followed by CFB_GW2?
OK, the media resources are selected at 3 levels in this order:
MRGL at device
MRGL at device pool
the phone that presses the confrn button will use it's available resources hunting thru the above elements to find which CFB to use.
if the MRGL from the phone has a MRG with CFB_GW2 as first place that is going to be the one used if resources available.
once a conference party leaves and only two parties remain the connection is established directly between them in order to release the conference resources. in this case the RTP would flow directly between 101 and the GW that handles the call to 22222222 which would be GW2 in this case.
in case the MRG had CFB_GW1 as first option and resources are available that would be used
I understand CFB is responsbile for multiplexing all the RTP streams and sending unicast stream to all parties (minus their own RTP stream).
Now what I understood from your explanation is, when conferncing is on, all voice streams are going to MGCP VG 2 (CFB_GW2 is first choice) and from there unicast stream flows to 1001, 22222222 and 55555555. Now if 22222222 drops the call, 55555555 will directly talk to 1001. The RTP flow between 55555555 and MGCP VG2 ceases the moment conference resources are released.
If again a new conference is initiated by 1001, RTP stream from 55555555 and 1001 will get routed to MGCP VG2 (CFB GW2) and multiplexing and so on.....
That means CCM keeps on changing the RTP Peers of parties involved in this scenario.
you're very welcome inner_silence and your understanding is right, the RTP sessions keep changing if you drop the conference and then create a new one depending on the phone that presess the cnfrnc softkey
the same would happen if you use a HW CFB but in that scenario the RTP would point to the IP of the router or cat65K that has the DSP recources.
BTW if you look in the CDR records for this you should see connections to BXXXXXXXXXXX those are the bridges that are created when you request the conference feature. they will keep changing the numbers so they're unique
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...