Hello, our company is developing a big wisp, and one of the products will be the voip for long distance, we have plan to used rb333 with xr2 cards and main ap, i wonder if anybody used voip with mikrotik.
thanks
-
-
elhombredelabata
just joined
- Posts: 10
- Joined:
Re: Voip
In our office, we have a VOIP PBX. In my house i have a linksys PAP2 FXS adapter and a Cisco ATA 186, they work grey with calls betwen these devices, but calls from outside are giving me lot of troubles with sound.
I am not sure, but thing is a mikrotik thing, of course some miss configuration of my part but really i can not find what i am doing wrong.
I am not sure, but thing is a mikrotik thing, of course some miss configuration of my part but really i can not find what i am doing wrong.
-
-
BrianHiggins
Forum Veteran
- Posts: 720
- Joined:
- Location: Norwalk, CT
- Contact:
Re: Voip
I don't reccomend using VoIP over 2.4hz... stick to 5.8 gear only, should give better performance.
Re: Voip
We are are a WISP and VoIP provider. We deploy Sipura SPA2002 (now the Linksys PAP2) and Cisco 7940/7960 IP Phones. Both devices work well on 2.4 and 5.8 fed equipment. Some customers go from the core router, through a 5.8 backhaul, through a 2.4 link which services their Linksys Router (don't know the model, they're all the same to me) and supplies Internet access to their half dozen Cisco 7940s and they have had no problems for months.
The biggest issue we had with wireless connectivity and VoIP was when the customer's location was receiving a poor signal the radios would reassociate to different bandwidth rates. I believe we simply set a smaller bandwidth rate (the best they could stay with) and they have had minimal problems.
The biggest issue we had with wireless connectivity and VoIP was when the customer's location was receiving a poor signal the radios would reassociate to different bandwidth rates. I believe we simply set a smaller bandwidth rate (the best they could stay with) and they have had minimal problems.
Re: Voip
I am running voip over 2.4ghz and for the most part it works well. There are times however, of high traffic clients that do cause a short period of degradation to voip calls. I believe if I was able to give a priority to the voip packets and just slow down (que) the rest it would be perfected. There are three ports that we use which are udp ports.
-Michael
-Michael
Re: Voip
I have personally found the easiest and most effective way to prioritize voip traffic on our network was to take our several voice servers IPs and have all traffic to/from these IP have priority. That way we only prioritize our own voip traffic (I don't care if vonage and anything else sounds crappy) and do not have to add lots of rules for client devices or try to use more cpu figuring out which packets on an interface are voip and which is not.
Just make the traffic to/from your voip servers happy. For external voip services / thats more difficult.
Scott
Just make the traffic to/from your voip servers happy. For external voip services / thats more difficult.
Scott
-
-
BrianHiggins
Forum Veteran
- Posts: 720
- Joined:
- Location: Norwalk, CT
- Contact:
Re: Voip
it could use some work, but it's a nice start... if you use this, and make changes (that improve it) please post them back hereAny of you have tried setting VoIP Priority ? I have some set up but i'm not sure is working fine since i see no packets queued in my queue tree...
Any help would be greatly appreciated...
VoIP Priority such as for Vonage...
Code: Select all
/ ip firewall address-list
add list="VoIP Servers" address=69.59.224.0/19 comment="Vonage" disabled=no
/ ip firewall mangle
add chain=forward action=jump jump-target=VoIPChain protocol=udp \
src-address-list="VoIP Servers" comment="VoIP Chain" disabled=no
add chain=VoIPChain action=add-dst-to-address-list dst-address-list="!VoIP \
Servers" address-list="Active VoIP Clients" address-list-timeout=5m \
comment="" disabled=no
add chain=forward action=jump jump-target=VoIPChain dst-port=10000-20000 \
protocol=udp dst-address-list="VoIP Servers" comment="VoIP Chain" \
disabled=no
add chain=forward action=jump jump-target=VoIPChain dst-port=10000-20000 \
protocol=tcp dst-address-list="VoIP Servers" comment="VoIP Chain" \
disabled=no
add chain=forward action=jump jump-target=VoIPChain dst-port=5060 protocol=udp \
comment="VoIP Chain" disabled=no
add chain=VoIPChain action=mark-packet new-packet-mark=VoIP passthrough=yes \
comment="" disabled=no
add chain=VoIPChain action=mark-packet new-packet-mark=VoIP passthrough=yes \
connection-state=related comment="" disabled=no
add chain=VoIPChain action=change-tos new-tos=min-delay comment="VoIP TCP TOS" \
disabled=no
add chain=VoIPChain action=accept comment="" disabled=no 
-
-
BrianHiggins
Forum Veteran
- Posts: 720
- Joined:
- Location: Norwalk, CT
- Contact:
Re: Voip
sure, but he only asked how to change the priority...changing tos to min-delay is good and all, but don't you have to have some queueing setup that actually affects the traffic ?
I gave him the packet mark as well as the changing the tos. I assume that he can create a queue to his liking from here...Any of you have tried setting VoIP Priority ?
*edit simply changing the TOS alone should have some affect on it, as well as when it leaves your network and gets to your upstream providers, they should use the TOS field to prioritize traffic as well.
Re: Voip
Forepoint,
Lets assume you provide your own voice services and are not concerned with external voice services... Since you detect the voip servers on your network by the source or destination address list for your servers then there would be no reason to have additional rules for the clients - correct? Seems redundant with my assumption above... Do you mark packets for clients who use voice services other than your own?
Scott
Lets assume you provide your own voice services and are not concerned with external voice services... Since you detect the voip servers on your network by the source or destination address list for your servers then there would be no reason to have additional rules for the clients - correct? Seems redundant with my assumption above... Do you mark packets for clients who use voice services other than your own?
Scott
-
-
BrianHiggins
Forum Veteran
- Posts: 720
- Joined:
- Location: Norwalk, CT
- Contact:
Re: Voip
We don't have any voice services of our own currently. I actually do have those rules deployed at one of our edge routers to mark the packets for other providers, as I do want to do anything I can to ensure that the traffic goes as smooth as possible for our customers. however at this time I've only got a seperate bandwidth queue for them at our edge router (we have 2 100mbps fiber feeds and we limit ourselves down to prevent costly spikes, I have an seperate rule to ensure the VoIP traffic never gets limited in throughput), I don't currently do anything on the other routers on the network beyond setting the TOS value
as far as having the additional rules if I did have my own, then no, there would be no reason, unless you wanted to play fair and try to help the voip traffic even if it wasn't your own service (they are still paying you for the connection, might as well try to make them happy, but I completly understand why you would prefer encourage the use of your own service...)
as far as having the additional rules if I did have my own, then no, there would be no reason, unless you wanted to play fair and try to help the voip traffic even if it wasn't your own service (they are still paying you for the connection, might as well try to make them happy, but I completly understand why you would prefer encourage the use of your own service...)
Re: Voip
The issue with using ToS is, that others have figured that one by now and are using it to mark their P2P or FTP traffic ToS min-delay just to get faster throughput.
QoS packet marking/queing based on known provider port settings/ranges certainly is the better approach.
/Martin
QoS packet marking/queing based on known provider port settings/ranges certainly is the better approach.
/Martin