Session Announcement Protocol (SAP)

 

The Session Announcement Protocol (SAP) must be one of the simplest protocols around. To announce a multicast session, the session creator merely multicasts packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place. People that wish to know which sessions are going to be active simply listen to the same well-known multicast group, and receive those announcement packets. Of course, the protocol gets a little more complex when we take security and caching into account, but basically that's it.

  

Figure 6.2: Session Announcement Packets

The SAP packet format (for IPv4) is shown in figure 6.2. The Message Type (MT) field indicates whether this packet announces a session, or deletes an announcement. One bit (E) indicates whether or not the payload is encrypted and one bit (C) indicates whether or not the payload is compressed. The combination of message ID hash and original source is supposed to provide a unique announcement ID that can be used to identify this particular version of this particular session. This is useful for caching or for ignoring packets that we previously failed to decrypt, but as this announcement ID is not guaranteed to be unique, care must be taken to also check the packet length and periodically check the packet contents themselves.

SAP announcements can be authenticated by including a digital signature of the payload in the optional authentication header. Both PGP and PKCS#7 based digital signatures are currently supported in the SAP protocol, although currently not many announcements are authenticated. As multicast-based sessions become more popular and people attempt to subvert them, this will no-doubt change.

SAP announcements can also be encrypted. However, this does not mean that the standard way to have small private wide-area conferences will be to announce them with encrypted SAP - the Session Initiation Protocol is a more appropriate mechanism for such conferences. The main uses for encrypted SAP announcements would appear to be in intranet environments where the SAP announcement bother few additional people, or for very large sessions where members are charged to participate. In the latter case, it would probably be a good idea to provide an additional level of access control beyond SAP encryption because it is easy for one misbehaving participant to leak a SAP key to other potential participant unless the keys are embedded in hardware as they are with satellite television smart cards.

The announcement rate for SAP is quite low, with typically several minutes between repeated announcements of the same session. Thus a user starting a SAP receiver will have to wait for a few minutes before seeing all the sessions. This is normally solved by caching - either by running a SAP receiver in the background all the time to keep the cache up-to-date, or by going to a local SAP proxy on startup and requesting a cache download.

It should be clear that although SAP will scale to any number of receivers, it will not scale to huge numbers of sessions. It is currently an IETF Experimental Standard, which reflects this belief that we will eventually need to replace it with something different. In the meantime though, it is a great way to bootstrap the use of IP multicast, and with appropriate caching, SAP will be OK with up to a few thousand sessions advertised.

SAP should be used for sessions of some public interest where the participants are not known in advance. If you know who you want in your session, a better mechanism is to explicitly invite them using SIP.