[svctest] [Fwd: Questions to Vidyo]
Eric Le Guiniec
eric at vidyo.com
2008. Jún. 11., Sze, 21:43:30 CEST
HI Andras, please see our answers below, let us know further comments or ideas you may have.
Thanks
Eric
1. Firewall/NAT traversal:
o What is the current technology you promote?
[VIDYO] For NAT: ICE/STUN for FW port blocking: TLS
o We heard about Vidyo proxy, what is it all about?
[VIDYO] The VidyoProxy act as a back-to-back user agent, i.e. terminates and reinitiate the video, audio and control streams. The VidyoProxy can also terminate the TLS tunneled traffic and reinitiate an open UDP traffic.
Notes (with researcher community hat on):
o We have been experiencing that H.323/SIP does not fly due to firewall/NAT traversal problems (often requires days of fw/NAT debugging)
o Adobe and other webconferencing solutions use HTTP tunneling
o We think that an HTTP tunneling option would solve any of the problems
[VIDYO] HTTP tunneling is very similar to TLS tunneling which also adds the secured handshake to create the tunnel. All traffic is tunneled over HTTPS port (443)
o We also think that Vidyo proxy solution (as far as we understand it) is not feasible, since a European-level service would require deployment thousands of gateways, which is obviously impossible.
[VIDYO] TLS client without VidyoProxy onsite will be sufficient in most of the cases. VidyoProxy will only be required to large sites where a Vidyo is onsite, please note that VidyoProxy will also host The Routing Functionality allowing cascading (floating Port Licenses) with main routers and therefore leveraging important bandwidth savings.
2. Audio stream delivery:
o We are wondering how audio delivery is happening in your solution.
o Since Vidyo router is switching packet, we suppose that audio mixing is also avoided.
[VIDYO] Right, the VidyoRouter identifies in real-time the 3 audio streams with the highest energy (loudest speakers) without actually tapping into the audio stream (a patent pending method). Only those streams are passed to each client in the call, which is responsible for the mixing.
o How the audio delivered without mixing? All-to-all? What happens when 20 participants are there?
[VIDYO] See above
3. AAI enabling the web interface:
o What do you think, is there a chance to AAI-enable (maybe Shibboleth or eduGAIN) your Vidyo portal?
[VIDYO] Yes, on our roadmap there's a LDAP-based integration for authorization and authentication (H2/08)
4. Camera support:
o We have just received some information on this issue
o A few notes:
- Is there a plan to support firewire cameras (many of our users use e.g. a Sony camera on a tripod to get better quality and autofocus)
[VIDYO] On the VidyoDesktop yes, as long as the camera driver has a DirectShow support. Currently there are no plans for this for the VidyoRooms.
- I understand you being USB-biased due to better performance by the OS/drivers. It is still a question whether a huge userbase (generally thinking) could tolerate this or not? (ie. forcing all users to get rid of good old PCI hardware).
[VIDYO] Again, as long as the camera or capture card support DirectShow we'll be able to use that video stream.
5. Dialling out/inthrough gateway:
o Currently, we use e.164 for both H.323 and SIP
[VIDYO] We support this as well.
o How the dialling in (to Vidyo cloud) is done at the gateway? (How a user could indicate Vidyo meeting room?)
[VIDYO] A client would dial a prefix which identifies the GW followed by the numeric extension assigned to the meeting room.
The SIP Server would have to be configured to push those type of E.164's to the GW (e.g. configure a forwarding rule or trunk). The GW can be configured with "inbound" multiple prefixes associated with the capabilities of the call (CIF/384K, 4CIF/767, 720P/1.5M, voice) or just with a single prefix, in which case the maximum capacities will be set according to the cap-exchange negotiation.
o How the dialing out is done? (How the number translation is done to E.164 at the gateway?)
[VIDYO] Same concept. A similar multiple/single "outbound" prefixes are configured on the GW, which subscribes with those to VidyoPortal. A Vidyo user has to enter the prefix and then the external E.164 to place a call. The VidyoPortal will direct that call to a free GW which will remove the prefix and send a query to the SIP Server (and/or to the GK).
6. Management of Vidyo solution:
o How is the management done of Vidyo components (portal, router, gateway, etc.)?
[VIDYO] All is done at the VidyoPortal - under admin pages "Settings->Components". VidyoRouters and VidyoGateways will have hyperlink to their own configuration page.
o How to configure them?
[VIDYO] See above
o Is there SNMP support for standard based regular retrieval of system parameters?
[VIDYO] We will support only SNMP Traps generated from the VidyoPortal for local warnings and warnings coming from any components.
o How conferences/users could be monitored?
[VIDYO] from The admin pages of the VidyoPortal
7. Gateway:
o It would be very important to test the gateway solution due to interoperability issues (protocol and codec compatibility).
o Can you please provide general technical information about the gw?
[VIDYO] See attached a draft of the datasheet (not finalized yet).
o What is the capacity of the gateway (number of calls in function of transcoding done)
[VIDYO]
* 1 x HD720P30 @ 1.5 Mbps
* 4 x 4CIF @ 768 Mbps
* 12 x CIF @ 384 Kbps
* 50 Voice-only
o How a layout is assembled at the gateway (transmitting a VC from Vidyo cloud to H.323/SIP world)? Are all the Vidyo participants decoded, assembled onto a screen, and encoded?
[VIDYO] Yes, up to a maximum of 9 simultaneous views.
Is there voice activated modes where louder speakers are on the screens?
[VIDYO] on the roadmap.
Eric Le Guiniec
G.M. Vidyo EMEA
T +33 613 507 915
F +33 488 718 839
W www.vidyo.com
-----Message d'origine-----
De : svctest-bounces at listserv.niif.hu [mailto:svctest-bounces at listserv.niif.hu] De la part de Andras Kovacs
Envoyé : mercredi 11 juin 2008 13:35
À : svctest at listserv.niif.hu
Objet : [svctest] [Fwd: Questions to Vidyo]
Hi All,
Sorry about bugging you... Have you received those questions? Are they
relevant? Anybody to add something? (thanks).
The other issue is the way we test. How could we access the Surfnet
equipment? Do you want me to contact Michiel Schok and get him onto this
list?
Thanks.
Andras
-------- Original Message --------
Subject: [svctest] Questions to Vidyo
Date: Wed, 04 Jun 2008 12:29:56 +0200
From: Andras Kovacs <akov at niif.hu>
Reply-To: akov at niif.hu
Organization: NIIF/HUNGARNET
To: svctest at listserv.niif.hu
Hi All,
First of all, I would like to thank to Vidyo for their commitment in
such testings. Hopefully, we will be able to do an extensive testing in
the forthcoming weeks and that will be a valuable input for you as well.
These are the first technical questions to Vidyo (discussed in Bruges
with some GN2 people).
1. Firewall/NAT traversal:
o What is the current technology you promote?
o We heard about Vidyo proxy, what is it all about?
Notes (with researcher community hat on):
o We have been experiencing that H.323/SIP does not fly due to
firewall/NAT traversal problems (often requires days of fw/NAT debugging)
o Adobe and other webconferencing solutions use HTTP tunneling
o We think that an HTTP tunneling option would solve any of the problems
o We also think that Vidyo proxy solution (as far as we understand it)
is not feasible, since a European-level service would require deployment
thousands of gateways, which is obviously impossible.
2. Audio stream delivery:
o We are wondering how audio delivery is happening in your solution.
o Since Vidyo router is switching packet, we suppose that audio mixing
is also avoided.
o How the audio delivered without mixing? All-to-all? What happens
when 20 participants are there?
3. AAI enabling the web interface:
o What do you think, is there a chance to AAI-enable (maybe Shibboleth
or eduGAIN) your Vidyo portal?
4. Camera support:
o We have just received some information on this issue
o A few notes:
- Is there a plan to support firewire cameras (many of our users use
e.g. a Sony camera on a tripod to get better quality and autofocus)
- I understand you being USB-biased due to better performance by the
OS/drivers. It is still a question whether a huge userbase (generally
thinking) could tolerate this or not? (ie. forcing all users to get rid
of good old PCI hardware).
5. Dialling out/inthrough gateway:
o Currently, we use e.164 for both H.323 and SIP
o How the dialling in (to Vidyo cloud) is done at the gateway? (How a
user could indicate Vidyo meeting room?)
o How the dialling out is done? (How the number translation is done to
E.164 at the gateway?)
6. Management of Vidyo solution:
o How is the management done of Vidyo components (portal, router,
gateway, etc.)?
o How to configure them?
o Is there SNMP support for standard based regular retrieval of system
parameters?
o How conferences/users could be monitored?
7. Gateway:
o It would be very important to test the gateway solution due to
interoperability issues (protocol and codec compatibility).
o Can you please provide general technical information about the gw?
o What is the capacity of the gateway (number of calls in function of
transcoding done)
o How a layout is assembled at the gateway (transmitting a VC from
Vidyo cloud to H.323/SIP world)? Are all the Vidyo participants decoded,
assembled onto a screen, and encoded? Is there voice activated modes
where louder speakers are on the screens?
Sorry for the question-tsunami. ;)
Thanks in advance.
Cheers,
Andras
_______________________________________________
svctest mailing list
svctest at listserv.niif.hu
https://listserv.niif.hu/mailman/listinfo/svctest
--
Andras Kovacs
Network Engineer
-------------------------------------------------------------
NIIF/HUNGARNET e-mail: akov at niif.hu
Victor Hugo str. 18-22. tel: +36 1 450 3082
H-1132 Budapest, Hungary fax: +36 1 350 6750
_______________________________________________
svctest mailing list
svctest at listserv.niif.hu
https://listserv.niif.hu/mailman/listinfo/svctest
--------- következõ rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: https://listserv.niif.hu/pipermail/test/attachments/20080611/10f0f4d8/attachment-0002.htm
További információk a(z) Test levelezőlistáról