Hi Andrew,
We are really careful not to offer defense services, because we don't want
Codec2 to be tangled up with ITAR and similar law in other nations. So,
please reassure us this is not for a government contract. I've attached
some boilerplate below that explains the problem.
Thanks
Bruce
*No National Defense Participation*
Due to our need to comply with ITAR, EAR, and the export laws of other
nations, *we can not allow the participation for the purpose of creating
devices or services for national defense.* This would expose us to
regulation that would prevent international collaboration on our projects.
Individuals employed by defense vendors or national governments who are
clearly working on defense projects may not post to the mailing lists and
discussion forums or cooperate in development.
*Participation for national disaster preparedness and response (for
example, by FEMA in the U.S. and many Amateur Radio organizations
worldwide) is allowed and encouraged. Defense vendors may be required to
demonstrate that they are working on a contract with a national disaster
preparedness organization such as FEMA.*
The Problem From The Radio Amateur Viewpoint
Many of our wireless projects are for use by Radio Amateurs (“ham radio”
operators). Each nation regulates the use of particular communication
technologies by their Radio Amateurs. Digital communications are
particularly subject to regulation, because of the potential for them to be
used with encryption and the special equipment necessary for a national
regulator to receive them. So that nations continue to authorize use of our
work on the air by their Radio Amateurs, our projects must clearly not be
for any military purpose.
When Radio Amateurs participate in DX-peditions
<https://en.wikipedia.org/wiki/DX-pedition>, they travel to another nation
for the purpose of making on-air contacts from an area that has few or no
local ham radio operators. Hams collect contacts from such rare and distant
locations, and thus appreciate the Amateurs who go to those places and make
contacts from them with other hams worldwide. The local governments whose
nations are visited by DX-peditions must be assured that the hams are not
spies and are not there for any military purpose. Often local governments
are unfamiliar with the technology that is brought on DX-peditions, and
fearful because they do not own any means to receive and decode the signals
– especially in the case of ORI’s digital communications projects, which
may be seen as cryptography even when signals are actually sent in the
clear.
Suspicion of Radio Amateurs by national governments has resulted in their
imprisonment in various countries and could even result in execution. More
often it results in the government suddenly rescinding the privilege of
operating in their nation, often after the hams have gone to great expense
to travel to an inaccessible place, chartering ships or aircraft and
bringing lots of large and heavy equipment. ORI works to prevent such
suspicion by maintaining its projects as clearly non-military.
On Mon, May 7, 2018 at 10:05 PM, Andrew Baek <ab...@troicom.com> wrote:
> Hi David,
>
>
>
> I would like to ask on packetization of Codec2 such that the packets can
> be reassembled and decoded on the receiving end.
>
>
>
> 1. Overall we would need to packetize the coded bits into a certain size,
> say 64bits, 128bits, ...
>
> 2. I was wondering how a continuous audio stream could be packetized after
> Codec2 encoding
>
> 3. I was reading the Codec2 Wiki page, and it looks like Codec2 actually
> generates a certain number of bits every frame, e.g. 64 bits every 20msec
> for Mode 3200.
>
> 4. Does this mean I can just send out 64-bit packets one after another
> and reassemble on the receiving end? Of course, we would need some type of
> rate buffers.
>
> 5. Primarily I was concerned that we would need to take care of some
> state variables as the speech would be continuous.
>
> 6. It may be that any state variables are maintained within Codec2 so it
> would be transparent to us.
>
>
>
> If the frame-by-frame packet generation is reasonable, would it be
> possible to receive a pointer as to where to tap out the packets?
>
>
>
> Regards,
>
>
>
> Andrew
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
--
Bruce Perens K6BP - CEO, Legal Engineering
Standards committee chair, license review committee member, co-founder,
Open Source Initiative
President, Open Research Institute; Board Member, Fashion Freedom
Initiative.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
