JINX now supports VOIP

[rpm]

http://www.mybroadband.co.za/nephp/?m=show&id=5458

 

[ic]

The switching fabric at JINX has now been configured in such a way that companies connected to JINX are able to keep their voice and data traffic separate.

Interesting, I assume this means that all non-VoIP traffic passing through the JINX-VoIP tunnel(s) is shaped&|deprioritised to preserve VoIP QoS...?

 

[Syndyre]

http://www.mybroadband.co.za/nephp/?m=show&id=5458Interesting, I assume this means that all non-VoIP traffic passing through the JINX-VoIP tunnel(s) is shaped&|deprioritised to preserve VoIP QoS...?

That would seem to be the only reason to separate it.

 

[Roman4604]

http://www.mybroadband.co.za/nephp/?m=show&id=5458Interesting, I assume this means that all non-VoIP traffic passing through the JINX-VoIP tunnel(s) is shaped&|deprioritised to preserve VoIP QoS...?

Not exactly, the JINX switches have just been configured to run 2 seperate VLANs, one for data (current) & new one for VoIP. Seperate physical/logical router interfaces are used to connect to each VLAN , therefore each ISP can control their own QoS policy on each independantly as per their requirements. The JINX infrastructure does not enforce any policy.

 

[Ant_Brooks]

Interesting, I assume this means that all non-VoIP traffic passing through the JINX-VoIP tunnel(s) is shaped&deprioritised to preserve VoIP QoS...?

No, there is currently no shaping or (de)prioritisation done on either the VoIP or non-VoIP traffic, at least as far as the JINX switching fabric goes. There isn't any need to do this, since the existing infrastructure is handling all of the traffic just fine.

However, it is possible that some of ISPA's members might want to shape or prioritise their VoIP traffic in the future, so we've made sure that they are able to separate this traffic at the exchange level. We're also busy analysing the likely future needs of ISPA's members as far as JINX goes, so I wouldn't rule out some more upgrades/changes during the course of the year.

 

[ic]

No, there is currently no shaping or (de)prioritisation done on either the VoIP or non-VoIP traffic, at least as far as the JINX switching fabric goes. There isn't any need to do this, since the existing infrastructure is handling all of the traffic just fine.

However, it is possible that some of ISPA's members might want to shape or prioritise their VoIP traffic in the future, so we've made sure that they are able to separate this traffic at the exchange level. We're also busy analysing the likely future needs of ISPA's members as far as JINX goes, so I wouldn't rule out some more upgrades/changes during the course of the year.

thanks for clarifying .

Part of the reason I posted what I did post - even though it turns out not to currently be implemented within JINX, was also to point out that under specific circumstances, prioritisation &| shaping should not be regarded as being evil: e.g. preserving VoIP QoS for a VoIP-specific tunnel|VLAN by effectively giving more priority to recognised VoIP data packets &| shaping non-VoIP data packets - IOW quite legitimate to protect VoIP QoS for everyone - of course this would probably require invasively identifying all non-VoIP packets at the possible expense of not recognising some legitimate VoIP packets.

Not forgetting of course, that from a consumer's POV, the shaping & de-prioritisation that Telkodemonopolies forces on SAIX ADSL customers, is evil, and is designed to force people to pay a huge premium for """unshaped""" [allegedly untouched] SAIX ADSL, but I am digressing...