Multicasting How to

[wlarsong]

My current setup is as follows: My company uses VLC for Video Conferencing at the moment we are using the UDP protocol and we are at two locations.

We have just opened a new office and now we want multistream video conferencing.

We are on M$ windowsXP at all locations. What I would like to do is a UDP Multicast with a centralized VPN. (vitrual private network)

I know that multicasting address begin after 224.0.0.1- so:

How do i use VLC on Windows ( I could use linux but M$ prefered) to create a Multicast server?

Does my LAN/ VPN IP need to be in 224.0.0.1- ?

a How to would pre MUCH appreciated. I like to UDP protocol as it is better at transporting video. Anyone Have some good website are documentation i could read. The VLC documentation is very sparse when it comes to this.

[wlarsong]

Ok so i did some research and I found that wikipedia had an excellent article on Multicasting

http://en.wikipedia.org/wiki/IP_Multicast

what i ended up doing was having all of my Clients VPN in to my network and then broadcasted on my server to UDP address 255.255.255.255 this enables multiple people to view a stream under UDP so lon as they are in the same network

[matthew.geier]

http://en.wikipedia.org/wiki/IP_Multicast

what i ended up doing was having all of my Clients VPN in to my network and then broadcasted on my server to UDP address 255.255.255.255 this enables multiple people to view a stream under UDP so lon as they are in the same network

Sending video to your broadcast address probably isn't such a great idea unless it's a VERY small network. EVERY host on the network is going to recieve and have to process the data even if they are not interested.

You really should pick a 'proper' multicast address and have ethernet switches that understand how to properly filter it.

[wlarsong]

so how would i do that UDP to a 224.0.0.XX address and do i need special switches that are designed for multicasting?

Or will the run of the mill router beable to do this

[tkernen]

You want switches that support at leadt IGMP snooping else you will be flooding all the ports on your network.

[matthew.geier]

You want switches that support at leadt IGMP snooping else you will be flooding all the ports on your network.

I'm multicasting multiple live video streams out of DVB cards. The network 'switches' support a combination of IGMP snooping and proprietory Cisco CGMP. I also have multiple network segments connected via Cisco routers , that co-operate with the switches for the CGMP stuff.

The result is, no client computer should see a video stream at it's ethernet unless it asked for it. Doesn't always work properly, but if all 14 video streams were flooded to all parts of my network, there would be a meltdown

Also even if your switches don't do proper igmp snooping, using a 'proper' multicast address will enable machines not interested in the video stream to ignore it down in the hardware of their ethernet chips, instead of having the broadcast handed into the operating system for attention.

A working 'vlm' example -

Code: Select all

new asiasat3-3760 broadcast enabled setup asiasat3-3760 input "dvb://" setup asiasat3-3760 option dvb-adapter=0 setup asiasat3-3760 option dvb-frequency=3760000 setup asiasat3-3760 option dvb-srate=2600000 setup asiasat3-3760 option dvb-lnb-lof1=5150 setup asiasat3-3760 option programs=1,3,4,5,2,9,12,30,11,7 setup asiasat3-3760 option ts-es-id-pid setup asiasat3-3760 output #duplicate{dst=standard{access=udp,mux=ts,url=239.255.100.99:1234,sap,group="Usyd META",name="Usyd META - Deutche Welle (Germany)"},select="program=30",dst=standard{access=udp,mux=ts,url=239.255.100.107:1234,sap,group="Usyd META",name="Usyd META - TV5Monde (France)"},select="program=12",dst=standard{access=udp,mux=ts,url=239.255.100.129:1234,sap,group="Usyd META",name="Usyd META - Al Jazeera International"},select="program=9",dst=standard{access=udp,mux=ts,url=239.255.100.130:1234,sap,group="Usyd META",name="Usyd META - NOW (Hong Kong)"},select="program=1",dst=standard{access=udp,mux=ts,url=239.255.100.131:1234,sap,group="Usyd META",name="Usyd META - Bloomberg (US)"},select="program=2",dst=standard{access=udp,mux=ts,url=239.255.100.132:1234,sap,group="Usyd META",name="Usyd META - Indus Music (Pakistan)"},select="program=3",dst=standard{access=udp,mux=ts,url=239.255.100.133:1234,sap,group="Usyd META",name="Usyd META - Channel G"},select="program=4",dst=standard{access=udp,mux=ts,url=239.255.100.134:1234,sap,group="Usyd META",name="Usyd META - Indus Vision (Pakistan)"},select="program=5",dst=standard{access=udp,mux=ts,url=239.255.100.135:1234,sap,group="Usyd META",name="Usyd META - Indus Plus News (Pakistan)"},select="program=11",dst=standard{access=udp,mux=ts,url=239.255.100.136:1234,sap,group="Usyd META",name="Usyd META - Muslim TV1 (?)"},select="program=7"} control asiasat3-3760 play

Note the multicast addresses have been chosen in conjunction with my campus network manager to ensure the transmissions don't 'leak' out of our network and onto the internet, as we are connected to the 'mbone' and a bad choice of address and/or 'ttl' would have the transmissions available to other mbone sites. The broadcasters might then take notice of what we are doing...
I understand that the 239.255.x.x area is reserved for 'local' use.

[tkernen]

Note the multicast addresses have been chosen in conjunction with my campus network manager to ensure the transmissions don't 'leak' out of our network and onto the internet, as we are connected to the 'mbone' and a bad choice of address and/or 'ttl' would have the transmissions available to other mbone sites. The broadcasters might then take notice of what we are doing...
I understand that the 239.255.x.x area is reserved for 'local' use.

I would not recommend using TTL as a reliable mechanism as a boundary for your multicast traffic, that was designed for the old days (aka the 90's). ACLs are much more of an up to date method for dealing with this.

[matthew.geier]

Note the multicast addresses have been chosen in conjunction with my campus network manager to ensure the transmissions don't 'leak' out of our network and onto the internet, as we are connected to the 'mbone' and a bad choice of address and/or 'ttl' would have the transmissions available to other mbone sites. The broadcasters might then take notice of what we are doing...
I understand that the 239.255.x.x area is reserved for 'local' use.

I would not recommend using TTL as a reliable mechanism as a boundary for your multicast traffic, that was designed for the old days (aka the 90's). ACLs are much more of an up to date method for dealing with this.

I don't control the border router, but I understand it does have ACLs to prevent my multicast transmissions from leaking out.

Other people haven't been so carefull I notice - we can currently get a number of Satelite TV channels via Canberra and at one point some one in the US was 'leaking' CNN.

[tkernen]

I don't control the border router, but I understand it does have ACLs to prevent my multicast transmissions from leaking out.

Other people haven't been so carefull I notice - we can currently get a number of Satelite TV channels via Canberra and at one point some one in the US was 'leaking' CNN.

In general there is a lack of education on how to design a proper multicast enabled and aware infrastructure. I too see all sorts of "interesting" groups pop up on the multicast enabled parts of the Internet.

[geo]

Other people haven't been so carefull I notice - we can currently get a number of Satelite TV channels via Canberra and at one point some one in the US was 'leaking' CNN.

Gday Matthew.

Actually, that's deliberate from Canberra.

http://uctv.canberra.edu.au/Members/geo ... ralia-wide

cheers - George

[matthew.geier]

Other people haven't been so carefull I notice - we can currently get a number of Satelite TV channels via Canberra and at one point some one in the US was 'leaking' CNN.

Gday Matthew.

Actually, that's deliberate from Canberra.

http://uctv.canberra.edu.au/Members/geo ... ralia-wide

cheers - George

Our legal people said broadcasting around the campus was dubious, so I'm not sure the of the legal position of what they are doing - broadcasting off their own campus to others. I can only assume they got each broadcaster to agree to redistribution over the Australian research net.

Grangenet has encouraged all sorts of bandwidth hogging behavour to use the capacity of their net gen network. (Aus equivalent of Internet2 or Europe's research 'net that I can't remember the name of at the moment - Gerant ?).

It would be great if we could share our broadcasts around, each location could recieve a couple of channels each, and over all, we could get a really good channel sweep.
As it is, I have 4 dishes on the top of my building. (One appears to have just failed..)

[geo]

As we (Ucan and Usyd) are both signatories to the AVCC's screenrights agreement, our legal people say it's OK. But then we've never been challenged on it, and you get a different answer from everyone you ask.

The only streams we're rebroadcasting are FTA satellite ones. The subscription networks definitely don't allow it with their streams.

We're specifically not forwarding our local Canberra DVB-T FTA channels beyond our campus border, as that's where DCITA have broadcast rules about Oz content. (You can't broadcast a local channel Oz-wide as in some circumnstances the content (security/fire alert) might cause problems.

We did it to show off the capabilities of GrangeNet. When GrangeNet closes at the end of the year we'll be shifting our streams out to Aarnet.

Sorry you lost a dish. Feel free to use our streams if they're on your net already. And if you're ever down this way, be sure to drop in!

George