[Namaste-dev] Re: Thoughts on ACP Interoperability
Timothy J. Salo
salo at saloits.com
Mon Jul 14 21:34:36 PDT 2008
Frank Brickle wrote:
> On Sun, Jul 13, 2008 at 2:11 PM, Bob McGwier <rwmcgwier at gmail.com
> <mailto:rwmcgwier at gmail.com>> wrote:
> Is there no middle ground? That is, what is to prevent us from
> implementing the CAI sans the vocoder and passing the digital
> streams encapsulated in "AMSAT-MAC"? Is there something that
> prevents this?
> Nothing prevents. I believe this is exactly what we *should* do. What's
> required, however, is...a port and a socket.
Huh? "... a port and a socket"?
> Or maybe just a little more, in the form of a tunnel through which alien
> EMCOMM packets can move over AMSAT links.
Should these "tunnels" over/through the ACP actually
transport IP packets?
If not, what should they transport?
Isn't it really important for the ACP system to transfer
IP packets between devices connected to ACP ground stations?
If it is important for ACP to transfer IP packets, is there
any need to transfer any other kind of packet?
> If we were to adopt something
> sensible like Jingle or SIP for signalling, then the tunneling would be
> off-the-shelf anyway.
I'm not convinced that SIP is the right answer, but I
would have to think about this some more.
It seems like there might be two classes of systems
architectures: voice-oriented architectures and
Am I correct in understanding that the ACP payload will
have absolutely no understanding of voice, that it will
be simply a packet switch?
It might be worthwhile to explore data-oriented architectures,
where all of the voice issues (e.g., codecs, transcoding,
call setup, etc. etc.) are moved outside of the ACP system
boundary. This might considerably simplify the ACP system
architecture and implementation. The voice piece could
become another related project. Or, maybe existing solutions
could be used to provide voice services, either commercial
off-the-shelf or open source solutions.
> Whatever the exact transport mechanism, though, there's essentially
> nothing to *do* at the AMSAT end, in this scenario.
I think this supports the model as the ACP payload as a
pure packet switch. While this is still pretty complicated,
it is at least on the simple end of the complexity spectrum.
More information about the Namaste-dev