Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Session Announcement Protocol.
Nothing was collected or created yet.
Session Announcement Protocol
View on Wikipediafrom Wikipedia
The Session Announcement Protocol (SAP) is an experimental protocol for advertising multicast session information. SAP typically uses Session Description Protocol (SDP) as the format for Real-time Transport Protocol (RTP) session descriptions. Announcement data is sent using IP multicast and the User Datagram Protocol (UDP).
Under SAP, senders periodically transmit SDP descriptions to a well-known multicast address and port number (9875).[1] A listening application constructs a guide of all advertised multicast sessions.
SAP was published by the IETF as RFC 2974.[2]
Announcement interval
[edit]The announcement interval is cooperatively modulated such that all SAP announcements in the multicast delivery scope, by default, consume 4000 bits per second. Regardless, the maximum announce interval is 300 seconds (5 minutes). Announcements automatically expire after 10 times the announcement interval or one hour, whichever is greater. Announcements may also be explicitly withdrawn by the original issuer.
Authentication, encryption and compression
[edit]SAP features separate methods for authenticating and encrypting announcements. Use of encryption is not recommended. Authentication prevents unauthorized modification and other DoS attacks. Authentication is optional. Two authentication schemes are supported:
- Pretty Good Privacy as defined in RFC 2440
- Cryptographic Message Syntax as defined in RFC 5652
The message body may optionally be compressed using the zlib format as defined in RFC 1950.
Applications and implementations
[edit]VLC media player monitors SAP announcements and presents the user a list of available streams.[3]
SAP is one of the optional discovery and connection management techniques described in the AES67 audio-over-Ethernet interoperability standard.[4]
References
[edit]- ^ "SAP (v1 & v2): Session Announcement Protocol". Archived from the original on 2013-01-26. Retrieved 2012-04-06.
- ^ M. Handley; C. Perkins; E. Whelan (October 2000). Session Announcement Protocol. RFC 2974.
- ^ Viewing with Session Announcement Protocol (SAP), retrieved 2019-03-02
- ^ "AES67-2013: AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability". Audio Engineering Society. 2013-09-11. Retrieved 2014-02-11.
External links
[edit]Session Announcement Protocol
View on Grokipediafrom Grokipedia
The Session Announcement Protocol (SAP) is an experimental network protocol standardized by the Internet Engineering Task Force (IETF) in RFC 2974, published in October 2000, for advertising multicast session information to enable discovery of real-time multimedia sessions such as internet radio and video broadcasts.[1][2] Developed by authors Mark Handley, Colin Perkins, and Edmund Whelan, SAP operates over UDP and uses periodic multicast announcements containing Session Description Protocol (SDP) payloads to inform potential participants about session details without requiring prior configuration or knowledge.[1] This design helps prevent network congestion issues like broadcast storms by limiting announcements to well-known multicast addresses and incorporating mechanisms for session deletion and compression.[1][3]
SAPv2, as defined in the RFC, addresses limitations of earlier versions by introducing features such as authentication via PGP signatures, payload compression using zlib, and support for both IPv4 and IPv6, making it suitable for announcing multicast sessions in IP multicast-enabled environments.[1][4] The protocol's announcements are sent to specific multicast channels (e.g., 224.2.127.254 for IPv4) at dynamically adjusted intervals with a minimum of 300 seconds and typically on the order of tens of minutes for active sessions, using explicit deletion messages and implicit timeouts based on the announcement period to ensure reliable propagation across the network.[1] While primarily intended for multicast-based discovery in tools like session directories (e.g., SDR), SAP has been implemented in various networking equipment and software for multimedia streaming applications, though its experimental status means it is not universally deployed.[5][6]
This 8-byte sequence precedes the ASCII SDP payload.[1]
Compression in SAP is indicated by the C bit and uses the zlib algorithm (RFC 1950) to reduce payload size, applied before encryption if both are enabled; it is not a separate message type but modifies announcement or deletion payloads.[1] In earlier versions like v1, gzip was specified but corrected to zlib in v2 for consistency.[1] The compressed payload replaces the full SDP to save bandwidth in repeated announcements, with receivers decompressing the payload if the C bit is set; messages with failed decompression are discarded.[1] Authentication, if present, uses digital signatures (e.g., PGP or CMS) calculated over the packet excluding the authentication data itself, ensuring the compressed content has not been tampered with during verification.[1] Note that SAP does not employ hash functions like MD5 specifically for compression; instead, the 16-bit message ID hash in the header aids in uniquely identifying sessions for update or deletion purposes.[1]
Overview
Definition and Purpose
The Session Announcement Protocol (SAP) is a lightweight network protocol designed for announcing multicast IP sessions by distributing session descriptions to potential participants across the internet. It enables session directors to periodically multicast announcements containing essential metadata about ongoing or upcoming sessions, allowing receivers to discover and join these sessions dynamically without prior configuration or centralized coordination. Defined in RFC 2974, SAP operates over UDP and focuses on simplicity to support scalable multicast environments.[7] The primary purpose of SAP is to facilitate the dynamic discovery of multimedia sessions, such as audio and video streams in real-time applications like internet radio and television, by providing potential participants with the necessary information to connect without relying on dedicated servers. This protocol addresses the need for efficient session advertisement in multicast networks, where traditional unicast methods would be inefficient for large-scale distribution. By enabling receivers to listen for announcements on well-known multicast addresses, SAP supports spontaneous participation in sessions, enhancing the accessibility of real-time multimedia content.[7][3] A key distinguishing feature of SAP is its design to prevent broadcast storms, which can overwhelm networks through excessive query flooding; instead, it relies on periodic, controlled announcements sent over predefined multicast channels, ensuring efficient discovery without generating unnecessary traffic. This approach promotes network stability while allowing for the advertisement of session details like timing, media types, and URIs in Session Description Protocol (SDP) format, which complements session initiation protocols by supplying the metadata required for joining.[7][8]History and Development
The Session Announcement Protocol (SAP) emerged in the late 1990s as part of the Internet Engineering Task Force (IETF) efforts to support multicast communications for multimedia applications, initially drawing from earlier session directory tools developed by Van Jacobson at Lawrence Berkeley National Laboratory (LBNL).[7] Version 1 of SAP was designed by Mark Handley during the European Commission-funded MICE (Esprit 7602) and MERCI (Telematics 1007) projects, with its protocol (SAPv0) documented in a November 1996 memo and implemented in version 2.2 of the "sdr" session directory tool.[7] This early work addressed the need for efficient announcement of multicast sessions in emerging internet multimedia environments, building on formats like the Session Description Protocol (SDP) to enable discovery without prior configuration.[9] Development of SAP version 2 (SAPv2) occurred within the IETF's Multiparty Multimedia Session Control (MMUSIC) working group, which focused on protocols for managing multiparty multimedia sessions.[9] The primary authors were Mark Handley, affiliated with the AT&T Center for Internet Research at ICSI (ACIRI); Colin Perkins, affiliated with the USC Information Sciences Institute (with contributions during his time at University College London and later at the University of Glasgow); and Edmund Whelan, from the Department of Computer Science at University College London.[7][10] Handley led the overall design evolution from SAPv1, Perkins contributed enhancements for IPv6 support developed with Maryann P. Maher, and Whelan, along with Goli Montasser-Kohsari and Peter Kirstein, advanced authentication mechanisms as part of the European Commission ICE-TEL project (Telematics 1005).[7] Iterative drafts, starting with draft-ietf-mmusic-sap-00 in November 1996 and progressing through multiple revisions of draft-ietf-mmusic-sap-v2 from 1998 to March 2000, incorporated feedback via the MMUSIC mailing list to address scalability, security, and protocol refinements like updated compression and explicit session deletion.[9][11] The standardization process culminated in the publication of RFC 2974 in October 2000, designating SAP as an experimental protocol rather than a full Internet standard to allow further community input and refinement.[7] This milestone recognized SAP's role in facilitating session announcements for real-time multicast applications, influencing subsequent IETF work on multimedia transport protocols within and beyond the MMUSIC group.[9]Technical Specifications
Protocol Mechanics
The Session Announcement Protocol (SAP) operates as a push-based multicast protocol, where announcers periodically broadcast session descriptions to potential listeners without requiring any prior queries or rendezvous mechanisms, in contrast to pull-based discovery protocols that rely on explicit requests.[7] This model enables efficient session advertisement in real-time applications by leveraging UDP for lightweight, best-effort delivery over a well-known multicast address of 224.2.127.254 and port 9875 for IPv4 global scope, with equivalent addresses for administrative scopes and IPv6.[7] Announcers include an origin host ID, typically the IP address of the sender, and a version number (set to 1 for SAP version 2) in their packets to ensure unique identification and compatibility.[7] In the step-by-step operational flow, an announcer first calculates a dynamic transmission interval based on the number of active sessions and payload sizes, aiming to limit the aggregate bandwidth to approximately 4000 bits per second across all announcements; it then multicasts UDP packets containing session descriptions—often integrated with Session Description Protocol (SDP) for detailing media streams—at staggered times to avoid synchronization.[7] Listeners, configured to join relevant multicast scopes (discovered via external mechanisms like the Multicast-Scope Zone Announcement Protocol), passively receive these packets on the designated address and port, processing them to discover and join sessions.[7] Multiple announcers may advertise the same session for redundancy, scaling their rates to match a single announcer while using identical content to prevent conflicts.[7] The announcement lifecycle begins with the active announcing phase, where packets are sent periodically to advertise ongoing sessions, and may incorporate compression using algorithms like zlib to reduce bandwidth usage without altering the core description integrity.[7] As sessions evolve, version updates are signaled through changes in a message identifier hash, a 16-bit value derived from the payload, allowing listeners to detect modifications and fetch updated descriptions.[7] To conclude a session, announcers send explicit deletion messages authenticated with the same key as prior announcements, or listeners infer deletion via timeouts—either explicit end-times in the description or implicit after ten intervals or one hour without reception, whichever is longer.[7] For reliability and error handling, SAP employs the message identifier hash combined with the origin host ID to uniquely identify announcements, enabling listeners to discard duplicates and detect losses or updates without sequence numbers per se.[7] Multicast scoping further enhances this by restricting announcements to appropriate network zones (e.g., global or administrative), preventing overload in large domains and ensuring locality; the IP time-to-live is set to 255, though scoping is preferred over TTL for control.[7] These mechanisms collectively mitigate issues like lost packets or unauthorized changes through optional authentication, maintaining the protocol's efficiency in dynamic multicast environments.[7]Message Formats and Encoding
The Session Announcement Protocol (SAP), as defined in RFC 2974, employs a binary-encoded packet format consisting of a fixed header followed by optional authentication data, an optional payload type field, and the payload itself.[1] The header is 8 bytes long for IPv4 addresses without authentication data and 20 bytes for IPv6 without authentication data, structured to include essential fields for identification and processing.[1] Specifically, the header begins with bit-packed fields containing the version (V, 4 bits, set to 1 for SAP version 2), address type (A, 1 bit, 0 for IPv4 or 1 for IPv6), reserved bit (R, 1 bit, set to 0), message type (T, 1 bit, 0 for announcement or 1 for deletion), encryption bit (E, 1 bit, 1 if payload is encrypted), and compression bit (C, 1 bit, 1 if payload is compressed), followed by an 8-bit authentication length field indicating the number of 32-bit words of optional authentication data, a 16-bit message identifier hash for uniquely identifying the announcement version in combination with the originating source, and the originating source field (32 bits for IPv4 or 128 bits for IPv6, in network byte order).[1] SAP supports two primary message types: announcements and deletions, with compression and encryption as optional payload attributes rather than distinct types.[1] Announcement messages (T=0) carry a full session description in the payload, typically formatted as Session Description Protocol (SDP) data according to RFC 2327, which begins with an ASCII "v=0" line indicating SDP version 0.[1] The SDP payload includes an origin field in the format "o=<username> <session id> <version> <network type> <address type> <address>", where the address type specifies IP version (e.g., IN for Internet) and the address is the session's multicast address; this field uniquely identifies the session but differs from the header's originating source, which identifies the announcer's IP address.[1] Deletion messages (T=1) are used to explicitly remove a session from receivers' directories and contain a minimal payload consisting of a single SDP origin line matching the session to delete, requiring matching authentication from prior announcements for validity.[1] For backwards compatibility with earlier versions like SAP v0 and v1, announcement headers set V=0 or V=1 respectively, with simplified fields (e.g., no IPv6 support in v0/v1, originating source set to 0 in v0), but v2 tools can parse them while older tools cannot parse v2.[1] Encoding in SAP combines binary for the header and ASCII for the payload to ensure efficient transmission over UDP while maintaining readability for SDP.[1] The header fields are encoded in network byte order, with the bit-packed fields using standard binary representation (e.g., V=1 as binary 0001 in the high 4 bits).[1] The optional payload type field, if present, is a variable-length ASCII string terminated by a NUL byte (e.g., "application/sdp\0"), though it may be omitted for SDP payloads in compatibility mode.[1] Field lengths are fixed where possible: the bit-packed fields as described, authentication length 1 byte, message ID hash 2 bytes, and originating source 4 bytes (IPv4) or 16 bytes (IPv6), followed by authentication data in multiples of 4 bytes if used.[1] An example binary representation of a minimal IPv4 announcement header (V=1, A=0, R=0, T=0, E=0, C=0, auth len=0, msg ID hash=0x1234, source=192.0.2.1) is:00010000 00000000 00010010 00110100 11000000 00000000 00000010 00000001
00010000 00000000 00010010 00110100 11000000 00000000 00000010 00000001