[hydra-dev] White paper addressing Service Discovery for Hydra

[Kevin P. Fleming]

Nick Lewis wrote:

> Re section 3:
> In order to minimise latency I think any media conversion should be
> accomplished in a maximum of only three steps. There should be a small
> set of "native" formats for which there is fully meshed conversion
> capability. Other media formats should be convertible to one of these
> formats. For audio I suggest the following uncompressed native formats:
> 
> 8/8 Narrowband Voice @ 64Kb/s
> 16/16 Wideband Voice @ 256Kb/s
> 16/48 Standard Definition Music @ 768Kb/s
> 24/96 High Definition Music @ 2304Kb/s 
> 
> with channel bundling for mono, stereo, (quad?) and 7+1
> 
> All native formats should be converted in a single step e.g. straight
> from a 7+1 bundle of 24/96 HD audio to mono 8/8 narrowband audio

This is really more of an implementation issue, not a design issues. The
design proposed will work properly whether there are services available
to do one-step conversion, or if there are only multi-step services.
Also, you must keep in mind the needs for conference bridging: if a
conference has 8KHz, 16KHz and 32KHz channels included, then there may
be a need to 'stop' at intermediate conversion levels.

As far as I am aware, if PCM audio is going to be transported around the
system, the formats would be 8KHz/16bit, 16KHz/16bit, 32KHz/16bit (or
48KHz/16bit instead) and possibly 24KHz/96bit. There is no '8 bit' PCM
format; the only 8-bit formats in common use are G.711 ulaw/alaw, which
are lossy formats.

> Re section 4:
> When choosing a Media Specification Language do not overlook RFC 2327
> Session Description Protocol. It may not be perfect but is extremely
> widely used because of its association with sip. If something a bit more
> powerful is needed then I guess H.245 could fit the bill.

We've been discussing using Ice classes themselves for this purpose, as
that avoids having yet another generator/parser required in every media
component (since the Ice stuff is already present). I believe Ken and
Josh have some stuff to post shortly... so look for that. We've really
been striving to use type-safe interfaces and description systems
wherever possible, and binary too, since we have a messaging system to
use that will safely transport binary data amongst all supported platforms.

SDP itself is undergoing massive changes right now (see SDPCapNeg and
MediaCapNeg drafts), to support some of the things we already know we
want to be able to do in Hydra (namely expressing a set of 'possible
configurations' to be selected from by the receiver of the offer). The
capabilities of media endpoints have moved far beyond what the authors
of RFC2327 envisioned :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org