Chris,

Thanks for the details. We have enough DSPs, but the FXOs will only be used for 911 Calls and as a backup for SIP Trunk if it goes down.

SIP Trunk wouldn't require DSP resources, and most of the time the DSP resources will be required by Ad HOC Conferencing, and God Forbid if someone calls 911. Since the DSPs can't be shared we have to find a way to provide DSPs for FXO Calls.

I don't think if either 2-Fxo or 4-Fxo cards come with embedded DSP resources. If this is the case the problem can be solved easily by replacing the Fxo Cards.

Is Software Based DSP is an option here?

You are correct that SIP trunks do not need DSP, but TDM voice ports such as FXOs do, and they need to be pre-allocated.

The VIC-FXO cards do not come with embaded DSPs, you have couple of options here, there is no software based DSPs:

use existing DSPs, which means you may have to decrease the number of supported conference sessions.

Get additional DSPs, if you have available PVDM slots

Get Network Module card with onboard PVMDs, such as NM-1V or NM-HDV

HTH,

Chris

Chris,

I need to verify this with you as I could not find any configuration doc on CCO. Customer wants to make sure that for example, from one DSP = 16 PVDM channels, they can assign two PVDMs channels to 2-Port FXO card, two PVDMs channels to a second 2-Port FXO card, and then the last twelve PVDMs channels to Ad-Hoc Conferenceing. This way they can make or receive four consecutive calls over the FXO cards for backup and 911 calls, and then the rest of the channels from the same DSP for some other stuff such as Ad-Hoc/Meet Me etc.

Is there any documentation as well on CCO which I can send it to my customer to back this up as well.

Best Regards,

Hi Abbas,

You cannot share a DSP between conferencing and any other use. You can calculate how many DSPs you have by dividing the PVDM2-X number by 16. You can also use 'show voice dsp group all'.

When your router boots up with analog ports, it will automatically allocate DSPs for those ports.

When you go to configure conferencing, IOS will check for a free DSP and will not find any. The maximum sessions it will allow you to configure is 0.

You will need a PVDM2-32 or larger for this configuration. (Oddly enough you can also get 2 PVDM2-8's though this may not be officially supported).

To back it up, you can use the DSP calculator on cisco.com:

http://www.cisco.com/cgi-bin/Support/DSP/dsp-calc.pl

hth,

nick

The problem is that that the customer has at least 180 small locations with Cisco 2800 series routers. Since the number of IP Phones are between 24-48, Cisco recommended to go with 1 DSP Resource/16-PVDMs channels for FXO ports and Ad-Hoc Conferencing. Note: SIP Trunk doesn't require DSPs and that is why Cisco recommended one DSP for backup FXO and 911, and Ad-Hoc Conferencing.

Chris in his earlier mail mentioned that DSP can be shared between Voice-Ports and Transcoding, but not between Voice-Ports and Conferencing. Is Transcoding an option to configure Ad-Hoc Conferencing?

As previously stated voice channels and conferences can not share DSPs, so your only solution is to put in more PVDMs.

Transcoders will not provide you with conferencing. Whoever provided the design should have known that the backup FXO lines will require DSPs, as there is no way around it.

Chris

You can do ad-hoc conferencing with 3 people by default without any hardware conferencing. This is something that is able to be done in software. This would all need to be g711 as well.

That is something you can do with only one DSP. Otherwise, fill out the DSP calculator and that is what you will need. I haven't filled these exact details out, but it will tell you a PVDM2-32 or larger.

Wish there was another way around it, but this is it.

hth,

nick

Nick,

How can you do conferecing without PVDMs with CallManager? You can do 3 party conferences with CME but I am not aware of being able to do this with CM without PVDMs or using CM as conference bridge in which case I agree with the G711 limitation, but you can have up to 128 participants with CM conference bridge not 3. CM does not have a mechanism not to invoke a conference bridge (software nor hardware) when conference is invoked, with CME you can configure software conferencing in which case the 3 participants per conference applies.

Chris

I'm more on the CME side of things - sometimes I assume the problem is a CME problem. The 3 participants is for software with CME.

With CCM you can do software based conferencing, and have a fairly large amount of sessions - 128 I want to say. There is a default CFB with CCM that uses software.

hth,

nick

The customer is running CCM6.1. If software based Ad-Hoc can be done with software then the problem is solved without having an additional DSP/PVDM resources. As Nick is suggesting that the software conferencing can support up to 128 sessions with 3-party calling, and I would assume that more than 3 users can be in a conference but of course it will decrease the session less than 128. Does someone have a lab where it can be confirmed that the software based conferencing can be done without having to rely on DSPs will be appreciated.

This is something that Cisco needs to fix it. I 1 DSP has 16 PVDMs, and only two channels will be used by 2-port FXO card then the rest of the PVDMs will be wasted. It will not be wasted in a traditional TDM environment where the the rest of the PVDMs can be used by primary link such as T1 or PRI. But in a SIP trunk the PVDMs are not needed, and should be available for other resources such as Ad-HOC or Meet Me conferencing.

No need to lab it out, CM server can serve as conference bridge and provide 128 participants in one session or multiple sessions totaling 128 participants. As I mentioned earlier these can only be g711 sessions, so this is not very good design for environment with multiple sites, especially that the mixing takes place on the CM server, so all streams would go through it. Typically you use G729 for call between sites, if you decide to go this route your conference calls will traverse WAN as G711.

As to your concern, this has been this case from the very beginning, and without going into too much technical details it would be very difficult to share a DSP between conference and voice, this is all very well documented throughout CCO, and it's the job of the pre-sales engineers to ensure they are quoting sufficient PVDMs, unfortunately most pre-sales engineers have never even read CM SRND doc, and all they rely on is the configuration tool, which very often puts us in this situation. I've lived it way too many times. Cisco also sells half a DSP PVDM2-8 for environments that do not need a full DSP.

My suggestion to you is to go back to the drawing board and decide if you require hardware based conference bridges ( I would strongly advise that) and if so, adjust the BOMs accordingly.

HTH,

Chris

Chris,

Thank you so much. This is very thorough explanation.

Best Regards,

I didn't see anybody mention the need to consider bandwidth utilization over the WAN. If you use the SW CFB in UCM, which can only do G.711, you will use 80k per leg when conferencing.

So if someone at a branch site makes a 3 way call with 2 outside callers, 240k of G.711 is sent back to UCM to be mixed. Depending on the WAN BW this can be a show stopper, so I try to always have a DSP for conferencing when possible.

Unfortunately, even the new "flex" DSP allocation doesn't let the conference bridge share with anything else.