From: jakem38671omitthis@yahoo.com
I sincerely appreciate your reply.
Here are some answers and further info.
> Each site has a unique private subnet such as site-A=192.168.10.0 and
> site-B=192.168.25.0
That is the plan.
> Each site has more then one available fixed (static) public IP address.
The main site has two fixed Ips (can likely get more if necessary); the
remote site has only one.
> Each site has a good firewall (Cisco PIX or ASA, even a PIX 501 would do).
The main site has a Sonicwall TZ 170; the remote site will have a Sonicwall
SOHO3.
> Each site has sufficient bandwidth to support 100Kbps per active call,
> plus
> your internet traffic.
The main site has a dynamic T1 product capable of 1.2Mb/700Kb (down/up); the
remote site has Bellsouth DSL being installed in a few days. In my
experience, that will provide similar speeds, perhaps a bit slower, surely
on the upload side. Two Norstar T7316 phones will be installed in the remote
location. The voice traffic is light, and I expect simultaneous use of the
phones only rarely. There will be two PCs in the remote office connected to
the network. I need them connected via VPN so they can access an Excel
spreadsheet on a workstation in the main location.
> Each site has a router that will provide prioritization (QoS) to your
> voice
> traffic, won't help over the internet but at lease your voice will get out
> ahead of the data traffic.
Not at this point. The Sonicwall is the only router in the main location,
and so far I only have the Soho3 for the remote location.
> Normally I wouldn't recommend using an internet connection, since there is
> no QoS between sites you could get wildly varying performance and dropped
> connections. Definitely don't use it for client/customer calls, and
> internal
> calls only if they understand the possible problems.
I agree. I've done MCK and VoIP in general over p2p connections a few times,
but only twice over internet - once with very good results and once with
awful results. I'm hopeful that bandwidth and the low quantity of phones and
the light voice traffic in general (in the remote office, anyway) are all on
my side.
> In the firewall create a translation for the private IP of each MCK to an
> available Public IP. Allow inbound traffic for the UDP range and TCP used
> by
> the MCK. Unlike SIP, the MCK uses both UDP, for voice, and TCP, for
> signaling. You can get these from MCK. Point each MCK at the others Public
> address, and set a pass-code/password. That's really all there is to it.
I have not thought of it this way. Are you suggesting one-to-one NAT (which
indeed would necessitate at least two ip addresses at each location - one
for voice, one for data)? Alternatively, would port forwarding work? Which
raises another question I've never considered: Does port forwarding
introduce delay to the traffic, perhaps making it a poor method for voice?
If I'm reading your suggestion correctly, then we don't really create a
"vpn," but rather we point the MCK units at each other's static IP (which is
accomplished via a public-to-private ip address translation) ??
Thank you again,
Jm
"RC" wrote in message
news:46127042$0$32552$88260bb3@free.teranews.com...
> Done many a MCK like this. I do need a little more
> information/clarification.
>
> When you say on the same network please tell me the subnet addressing in
> the two sites isn't the same. This could cause problems. I'll make some
> assumption, you can consider these recommendations as well.
>
> Each site has a unique private subnet such as site-A=192.168.10.0 and
> site-B=192.168.25.0
> Each site has more then one available fixed (static) public IP address.
> Each site has a good firewall (Cisco PIX or ASA, even a PIX 501 would do).
> Each site has sufficient bandwidth to support 100Kbps per active call,
> plus your internet traffic.
> Each site has a router that will provide prioritization (QoS) to your
> voice traffic, won't help over the internet but at lease your voice will
> get out ahead of the data traffic.
>
> Normally I wouldn't recommend using an internet connection, since there is
> no QoS between sites you could get wildly varying performance and dropped
> connections. Definitely don't use it for client/customer calls, and
> internal calls only if they understand the possible problems.
>
> In the firewall create a translation for the private IP of each MCK to an
> available Public IP. Allow inbound traffic for the UDP range and TCP used
> by the MCK. Unlike SIP, the MCK uses both UDP, for voice, and TCP, for
> signaling. You can get these from MCK. Point each MCK at the others Public
> address, and set a pass-code/password. That's really all there is to it.
>
>
> --
> RC
> rcohen_at_cominc_dot_net
>
> The only thing I guaranty about my free advice is that it's mine and it's
> free.
>
> "JM" wrote in message
> news:buSdnb2ooseFpJLbnZ2dnUVZ_hSdnZ2d@comcast.com...
>> I'm setting up some MCK voip gateway/branch units to extend our PBX over
>> an internet connection to a remote office. I don't need security, but
>> rather a point-to-point connection, where the branch unit is on the same
>> network as the gateway unit. Therefore, I need two hardware units
>> pointed at one another. I have a static public IP at each location.
>>
>> Recommendations? Have I provided enough info?
>>
>> thank you,
>>
>> jm
>>
>>
>>
>>
>
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
