What is it?
It's peer-powered broadcasting leveraging the Session Initiation Protocol (SIP) and a few SIP-enabled tools and services to relay streamed data across multiple peers. It's currently not a "software package". It's a methodology, that might one day motivate the community to define key protocols, perhaps one day leading to the development of software packages dedicated to broadcasting over SIP. Until then, we'll explore what can be done today using freely available SIP software and services and start pinpointing limitations to be addressed.
Why not just use PeerCast and other dedicated P2P Broadcasting technologies for streaming media?
I can't think of a reason! They're worth trying out, and if this post does nothing but bring them publicity, we'll be off to a strong start. Check out projects similar to PeerCast.
Why Peer-to-Peer for Broadcasting?
While the vast majority of "content" can be consumed asynchronously, such as with podcasting, certain timely events and massively shared experiences warrant more "real-time" coverage.
P2P's already actively being used for digital asset delivery: thanks to pioneering peer-powered digital asset distribution frameworks such as BitTorrent, RedSwoosh, and Dijjer, it's becoming easier to leverage aggregate "visitor" bandwidth to more effectively deliver content.
Broadcasting in real-time to large audiences needs more P2P-love, as it remains today too onerous for independent authors to broadcast in real-time to masses. Leveraging peer-to-peer technologies for broadcasting is a fascinating human evolution in further freeing ourselves from our dependency on Big Media.
Phone, Cable, Media companies, are working around the clock lobbying legislators to keep a choke-hold on distribution of content, and the way we use broadband. Smart, legal, exciting applications of peer-to-peer technologies can further help legislators understand the importance of unfettered broadband connectivity.
When was SIPCasting first more or less successfully used? And how?
Well, in theory as early as the first time a group of people connected together in a SIP audio conference. The SIP RFC is dated circa 1995 so there had to be some geeks back then trying some cool stuff on local networks. But most recently, during the Apple WWDC 2006 Keynote, by a few TheAppleBlog readers, eager to listen to live spoken updates from a field correspondent, as a complement to textual coverage performed elsewhere. Here's an outline of the logistics of setting-up a basic SIPCast.
How is SIPCasting different? What does SIP give us?
SIP enables slightly different use cases: When two peers have established contact via SIP/STUN, both peers can exchange data in real-time over UDP. Data can go both ways. This enables SIP to power many forms of real-time communications. Traditional "broadcasting" is very-much a one-way process: Data flows from one source, to be passively received and consumed. SIP provides a strong framework for content consumers to also send data back to the "broadcaster". In essence, in a basic SIP session, there is no real such thing as a "broadcaster" and "consumer", but rather a tacit agreement between two peers, designating who "talks" and who "listens". In the specific use case of a live audio broadcast, a "listener" might choose to "speak up", in a more interactive framework. This may often not be desirable, and dedicated software would seek to provide a measure of control over available interactivity.
SIP provides a standard framework to execute the dirty work: SIP, STUN, SDP already define the low-level mechanisms for peers to find each-other, agree on the logistics of the session, and exchange media RTP packets over UDP, even through the vast majority of NAT configurations. Many peer-to-peer frameworks keep reinventing their own protocols to solve these problems.
SIP is versatile: SIP enables a slew of peer-to-peer applications based on mature, open standards. A while back, EarthLink R&D released a proof of concept SIP-powered peer-to-peer file sharing application written in Java: SIPShare.
SIP is highly interoperable: If something speaks SIP, chances are just about anything can conceivably connect to it. You've got a SIP-based radio broadcast? A Zyxel wifi phone user just might give you a ring from an airport Boingo hotspot. Perhaps a MindSpring, GizmoProject, or Free World Dialup user might plug your SIPCast address into their phone. Heck, if you mapped an ipkall.com 360 area code phone number to your SIP address, anybody with a plain old cell phone would be likely to dial you up and listen-in.
SIP addressing is powerful ... and convenient: Consider one of many possible forms of SIP addresses: sip:theappleblog@earthlink.net. Looks familiar? Just like an e-mail address. SIP also supports "session forwarding". I can arbitrarily decide to forward calls to my SIP address to another SIP address. Domain name registrars need to capitalize on this today, and add this as a feature alongside wild-card mail forwarding @somedomain.bleh. This is achievable by declaring your SIP proxy host as a handler of SIP traffic via DNS SRV records.
What Now?
We need to attempt more practice-runs of larger-scale audio SIPCasts using SJPhone, and/or perhaps even asterisk.
We need to document the many obvious and not-so-obvious limitations of this ad-hoc setup.
We need to define some use cases for SIPCast software that allows control over interactivity levels, and streamlines the peer discovery and media relay processes.
No comments:
Post a Comment