xviii ◾ Preface
WebRTC WG investigated the capabilities of existing SDP standards, they found that WebRTC
needs extensions of SDP to accommodate the full spectrum of new capabilities.
Historically, SDP was rst developed to be used for Session Announcement Protocol (SAP)
(RFC 2974) for distribution of the session information related to audio/video codecs and others to
the users who will participate in the session. SDP’s main task had been only one-way distribution
of the session capability (e.g. audio/video codec type, data applications, and/or others) informa-
tion to the participants while SIP was developed to two-way conferencing where session capability
negotiations among the conference participants on real-time, initial SDP capabilities developed
for SAP were not at all suitable. To introduce capability negotiation capabilities, at times it proved
so dicult that people became frustrated whether this SDP might have to be discarded.
Finally, the oer/answer model introduced by RFC 3264 (see Section 3.1) has been the water-
shed that rescues SDP to make a viable candidate for capability negotiations dynamically in real
time among the participants. Since then researchers and developers have been extending SDP
introducing many more capabilities as time goes by. Recently, WebRTC WG has introduced
many other capabilities in SDP.
Although SDP serving quite well for point-to-point multimedia conferencing, its protocol
architecture is such that it cannot be extended for distributed multipoint multimedia conference
as of today. e only multipoint conferencing that is oered today is the centralized star-like
topology with priori known address of the centralized controller. In centralized conference archi-
tecture is again capability negotiations are done using SDP in point-to-point fashion only. When
we work with SDP, we have to know its limitations how and where we can use SDP for setting up
the multimedia conferencing dynamically.
It has created a new urgency to publish a book on SDP providing full treatments due its own
merits. Like all other standards, we have to know exactly how many RFCs have been published
even related to the base SDP over two decades, and how they are interrelated to each other after so
many extensions and enhancements with new features and capabilities, corrections and modica-
tions with latest agreed-upon interpretations based on implementation and interoperability test
experiences, and future researches for breaking new ground knowing what already exists in SDP.
Like SIP, this book on SDP is the rst of this kind that attempts to put all SIP-related RFCs
together with their mandatory and optional texts in a chronological systematic way as if people
can use a single “super-SDP RFC” with almost one-to-one integrity from beginning to end to see
the big picture of SDP in addition to base SDP functionalities.
It should be noted that the texts of each RFC in the IETF are reviewed by all members of a
given WG throughout the world, and rough consensus is made which parts of texts of the draft
need to be “mandatory” and “optional” including whether a RFC needs to be “standards track,”
“informational,” or “experimental.” e key point is when one tries to put all SIP-related RFCs
together making a textbook has serious challenges how to put all texts together because it is not
simply to put one RFC after another one chronologically. It takes texts of each RFC needs to be
put together for each of these particular functionalities, capabilities, and features keeping integ-
rity. Since this book is planned as if it is like a single-SIP RFC, I have a very limited freedom to
change any texts of RFCs other than some editorial texts to make it look like a book. I have used
texts, gures, tables, and references from RFCs as much is necessary so that all can use all those
as they are found in RFCs. All RFCs along with their authors are provided in references, and all
credits of this book go primarily to those authors of these RFCs and many IETF WG members
who shaped nal RFCs with their invaluable comments and inputs. In this connection, I also
extend my sincere thanks to Ms. Alexa, IETF Secretariat, for his kind consent for reproducing
www.TechnicalBooksPDF.com