[hydra-dev] Topic from Meeting

[Ed Guy]

Chris,

This isn't off topic at all, in fact, it is the topic at the highest level!
I'll take this as a lead in to discuss some high-level architecture and
requirements.

The first refinement to this scope is that we want to facilitate
*electronic* communication. ( and smell-o-vision has already been done
by Mr Todd.)

We can then talk about different communication *models*:
* bidirectional streams
* unidirectional streams
* Burst Messages ( e.g., IM)

The number of participants in each interaction or "session"
* Single
* Two
* Many
* None 

And the *timeliness* of the communication:
* Real time
* Time shifted ( think tivo and voicemail)
* Hop-Oriented  (something in-between like SMS which is queued in both
reliably and best effort fashion)

And *Media*: 
* text,
* voice,
* video,
* image,
* telemetry ( structured data)
* Presence & Presentities.
* blob ( opaque data)

Also,  there's the long list of *Encoding* methods
* G711, ...

Then, the *Transport*, e.g.,
* RTP
* IAX2
* ICE

( what have I missed or misconstrued?)

Now to get practical, this classification, although not completely
flushed out, gives us a framework to 
analyze the suitability of system interfaces & components. It also
allows us to
further discuss the scope, e.g., time shifting of text (email)  ought to
be out of scope,
but the hop-oriented, best effort, transport of text ( e.g. SIP INFO)
messages
ought to be in scope.

Looking again at email, (time shifted text) and time shifted voice (
voicemail) we find they are very similar. But,
while the  transport of these messages (in some forms) is clearly in
scope, it's doubtful
any one would suggest implementing traditional  email with hydra.  
Architecturally,  these are
peripherals that sit on the edge of the system.  They are essentially
automata, or *Service Agents".
Other forms of agents involved with the system include *User Agents.* 
*Gateways*, and Channel Drivers.

Jumping ahead to a more interesting part, the system could be decomposed
into a conceptual framework as follows:
* Handles ( user and service identities, nicknames, addresses, phone
numbers, etc)
* Control ( location, authentication, authorization, sequencing,
resource allocation, negotiating, configuration, fault detection,
performance monitoring, accounting )
* Media Exchange & Manipulation
* Frames ( media encapsulations )
* Agents ( internal, external, drivers, and gateways)
* Supporting Technology ( libraries, OS Components, etc.)

This top-level breakdown is probably not too contentious, but, please
debate away!

One more topic to discuss with regard to scope of control.  A Hydra
deployment, IMHO, is limited to a set of administrative domains,
administered
from one, possible redundant,  system.  Hydra methods are not designed
to be used between administrative domains.


/ed








On 4/2/10 10:07 AM, Chris Tooley wrote:
> It's slightly off topic, but I wasn't 100% certain of my memory so I
> looked it up.
>
> tele-:
> a combining form meaning “distant,” esp. “transmission over a
> distance,” used in the formation of compound words: telegraph.
>
> -communications:
> the imparting or interchange of thoughts, opinions, or information by
> speech, writing, or signs.
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/mailman/private/asterisk-scf-dev/attachments/20100402/42b12b75/attachment.htm