CUCMBE and SRST over ADSL 4Mbps/768kbps on both ends

remi-reszka · ‎04-26-2010

Has anybody set up a CUCME or CUCMBE over ADSL link? What I am planning on implementing is a CUCMBE in the main site with SRST on the remote site. In remote site I will have around 20-25 phones. Maximum amout of calls between the site at pick will be around 5. Will I have enough bandwidth for call signaling and the voice traffic? I was also thinking to pass all incoming external calls in the remote site to AA on CUCMBE in the main site, how would that work? How would the ADSL perform here? Thanks for your input.

Robert Thomas · ‎04-26-2010

Remi,

There's a couple of factors you need to consider. The one that worry me the most is end to end delay, it's very common to see huge Round trip delays over ADSL infraestructure. If you have less that 150 ms of end to end delay you should be okay. Second because you can only have 768 Kbps of troughput in one direction you should consider QoS to avoid other applications from starving your voip bandwidht.

Now from the routing perspective how does your ADSL tight into your HQ? The ADSL will give you access only to the internet or to your corporate network as well? Will you bring up a VPN to the Public IP? Does this circuit operate somewhat like a MPLS?

Cheers,

remi-reszka · ‎04-26-2010

Hi rothoma2,

Here is a link where I am having a conversation with "tcatlinins" on this https://supportforums.cisco.com/message/3061214#3061214

We will have one dedicated ADSL link for voice only, no data will travel this link as yet but of course the voice will be going through a VPN over this ADSL link. The Internet access on bosh sites will go through another ADSL link that will be dedicated for Internet access only. So to speak we will have 2 ADSL connections at each site. The latency between the sites (round trip delay of course) is around 40-50ms and is stable (no jitter) so we should be good to go. We will have a static IP on HQ so for VPN we will either use Easy VPN or DMVPN with one spoke only.

So what do you think? We should be OK to go with CUCMBE and SRST or CME on the remote site? What else would I need to take under consideration? What would be better for the remote site? CME or SRST running on 2901 with SCCP protocol or some other vedor SIP gateway for analog phones that would also do SRST and SIP trunking to CUCMBE?

Robert Thomas · ‎04-26-2010

Remi,

It's all about QoS. In this case there's no guarantees from the provider to give a specific SLA. You may get very good QoS because your two offices are connected only to one provider and the pipes that tie together both ends with BGP are underused and very much stable, so you got a very mpls like connection and as well the packets go for not that many hops, however this could change overtime or even overnight. The QoS on this two spoke offices will be somewhat wild west and you got to be take into consideration with your initial design. But if you see the scenario right now is in your favor go for it.

I like more the CME style deployment, becuase you offload your call processing and can take decisions quicker. You can confgure multiple priority dial peers to redirect calls and so on, but SRST would do it as well.

For FXO definetly you are looking at cards placed into the GW, VG224, ATA or any Analog to Digital adapter will only give you FXS ports.

I'm sorry I cannot help you very much with VPN, but I'm voice only for now.

Cheers,

remi-reszka · ‎04-27-2010

No, you help me a lot. I think I will go with CME for local signaling for 20 analog telefones but for the voice mailboxes we will go over WAN to CUCMBE in HQ. For the voice mailboxes I can also use G.729 or it will have to be G.711?

But how will I integrate the CME with CUCMBE in HQ? Over H.323 trunk between CME and CUCMBE?

For instance if I implement 3rd party SIP analog voice gateway for analog phones (we will not have IP phones as yet) do I also need to go SIP trunking between the remote site (CME) and HQ (CUCMBE)?

Can you please give me some design and configuration ideas or examples?

Thanks in advance.