Re: [emergency] IF Broadcast Pointers

[Rex Brooks <rexb@starbourne.com>]

Thanks Kon,

This is a nice kick in the pants. Summarizing the current state of 
web services will take a bit of work, since some things are baked, 
some nearly baked, some really half-baked, and some not in the mixing 
bowl yet. But this, along with your previously uploaded EMIF-SC 
One-way Data Delivery file, is an inspiration.

Ciao,
Rex

At 12:38 PM -0700 8/10/04, Kon Wilms wrote:
>Following up from the IF discussion this morning, hope this helps move
>things along. Note these are true IF level specs where referenced (i.e.
>packet level encapsulation and transport delivery) -- not application
>layer transport abstractions.
>
>For broadcast we have a couple of breakdowns for the USA marketplace.
>
>=== Digital Cable:
>
>http://www.scte.org/documents/pdf/SCTE182002ANSIJSTD042DVS208.pdf
>
>Defines the injection of EAS for cable networks using OOB broadcast.
>This is a cable_emergency_alert message inside an MPEG2 ts (transport
>stream). Digital cable set top boxes can be triggered with messages
>using this. We've implemented this at RCN, Comcast and I believe a few
>others with a product called DEAS.
>
>=== Analog Cable and Analog terrestrial/OTA (over the air):
>
>http://www.chyrongraphics.com/products/codi/index_b.html#codieas
>
>Since there is no universal addressability for analog systems (VBI is
>not ubiquitously supported), automated character generators are used.
>Above is one. Basically a simple video re-encoder with an overlay text
>crawl. Oxtel, Matrox, and others do the same thing. One can classify
>these systems as legacy, since when analog NTSC is phased out they will
>cease to be used in favor of table packet injection as described above
>and below.
>
>=== ATSC (digital terrestrial/OTA):
>
>http://www.atsc.org/standards.html
>
>For delivery to digital set top boxes in the realm of SI (service
>information (mpeg ts metadata)) data the following are pertinent: a/65b.
>For delivery of data to PC or TCP stack capable receivers, the following
>are pertinent: a/90, a/92. A/92 and A/65b are the most widely 'used'.
>We're currently using A/92 for CAP transport via a product called
>AlertStorm. Triggering of alerts for digital set top boxes is still up
>in the air, but the most likely candidate is a DCC (directed channel
>change) trigger, to force receivers to tune to a channel, and then tune
>back (the last part is not implemented or specced yet) to the original
>channel after the emergency notification is completed.
>
>A/92 is the only viable injection method currently, as settop boxes do
>not support DCC, and most stations use static PSIP table
>servers/injectors. One must implement a metadata channel for description
>of content details and addressability. All A/92 vendors do this in their
>own way, but in a way so as not to be specific to any datatype. Please
>note that although A/92 defines SDP for metadata, it is *not* sufficient
>for anything but basic data descriptors. To be blunt, no-one uses it.
>
>Also note that many A/92 systems can be deployed on any IP system, and
>transparently carried over UDP-capable networks (i.e. satellite to
>terrestrial to lan to WIFI to NexTel, etc.) and decoded by any OS
>embedded or other with multicast-capable TCP stack.
>
>=== Satellite (directv, echostar, etc.):
>
>These providers use either DVB or proprietary transport streams. DVB
>resembles ATSC in some ways. Commercial satellite providers roll out
>receivers to their specifications, and each provider requires a
>proprietary alert injection system (if supported at all). This is too
>big a nebulous to cover and the best approach is probably to blanket
>these services under proprietary/custom.
>
>The IFSC one-way data delivery document adds some bulk to these
>comments.
>
>I think that covers it all. If we need to look at worldwide broadcast
>standards then this list will need a lot of addition and refinement.
>
>Cheers
>Kon
>
>
>***********************************************************************************
>Information contained in this email message is intended only for use 
>of the individual or entity named above. If the reader of this 
>message is not the intended recipient, or the employee or agent 
>responsible to deliver it to the intended recipient, you are hereby 
>notified that any dissemination, distribution or copying of this 
>communication is strictly prohibited. If you have received this 
>communication in error, please immediately notify the 
>postmaster@nds.com and destroy the original message.
>***********************************************************************************
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request