B. Compressing SDP Packets

Session announcements are transmitted as SDP packets. SDP is a simple protocol, defined as ASCII text lines describing the announcement, separated by a CR LF. These lines all have the same format: 

x=value
, where x is any letter which defines the attribute to be defined (case sensitive) and value is the value given to the attribute. Several attributes are defined by SDP so far. The following is a SDP packet arbitrarily catched from the INTERNET: 

v=0
o=james 3054298051 3054298223 IN IP4 129.89.142.50
s=FreeBSD Lounge
i=Channel to discuss FreeBSD related issues.  Please keep video bandwidth below 64 kbps.
e=Jim Lowe <james@cs.uwm.edu>
p=Jim Lowe (414) 229-6634
c=IN IP4 224.2.100.100/127
t=0 0
a=tool:sdr v2.2a23
a=type:test
m=audio 16400 RTP/AVP 0
c=IN IP4 224.2.100.100/127
a=ptime:40
m=video 49200 RTP/AVP 31
c=IN IP4 224.2.100.102/127
m=whiteboard 32800 udp wb
c=IN IP4 224.2.100.101/127
a=orient:portrait
This encoding technique is quite simple to implement, because a parser for recognizing a SDP packet is very simple. But the format is very inefficient and waste a lot of bandwidth. This is a problem on slow-speed links like PPP links on normal telephone lines. Because of this the SDP packet should be compressed. The SAP protocol which is normally used on the INTERNET to carry SDP packets, defines a way to simply compress the SDP packet by using the gzip algorithm. The following document describes a better technique, which utilizes a better compression ratio then simply using the gzip algorithm. The resulting protocol will be called compressed SDP (CSDP).

B.1. CSDP

The SDP packet will be compressed sequential on a per attribute basis. Because the order of the attributes is specified in the SDP draft, it is not necessary to identify the attributes explicit by an ID. They can simply be identified by the order. If an optional attribute is not present in an SDP packet, it will be coded as not present (see below).

There are two groups of attributes which can be repeated several times, the Time Description and the Media Description. The first attribute of each group is mandatory, if the group is present. So these groups will also be repeated in the compressed SDP packet. The last (or even missing) group will be indicated by the first attribute. If it is not present in the compressed packet (violation of the SDP specification), then this group will no longer repeated.

B.2. The Presence Bit

Because there are some attributes which are optional, and others which can be repeated, every attribute will be preceded by an <presence-bit>. If this bit is equal to 1, then the attribute is present, if the bit is 0, it is not. If it is present (i.e. the bit was 1) then the attribute will also be repeated. For example, to specify an attribute once, the following sequence is produced: 

+-+-+-+-+-+ ... +-+-+-+
|1| the attribute   |0|
+-+-+-+-+ ... +-+-+-+-+
If the attribute occurs two times, then the following sequence will be generated: 

+-+-+-+-+-+ ... +-+-+-+-+-+-+-+ ... +-+-+-+
|1| the attribute   |1| the attribute   |0|
+-+-+-+-+ ... +-+-+-+-+-+-+-+ ... +-+-+-+-+
According to the SDP specification, there are some fields which are mandatory and have to be specified exactly once. So the usage of the <presence-bit> is not needed for such attributes. But to simplify the compression / decompression, and to make the algorithm more clear, every attribute will be encapsulated by the <presence-bit>. This makes it also possible to extend the SDP spec, so that such attribute can be repeated, of skipped. The overhead of two bits (1 and 0) can be accepted.

There is one exception regarding the usage of the <presence-bit>. The very first attribute, the version of the SDP packet, will NOT be encapsulated. This is to let us define new versions of SDP or this compression protocol, which uses a fully different encapsulation. Therefore, we need the version information in plain.

B.3. Text Compression

Several attributes include plain ASCII text designated to be read by humans. Such fields cannot be compressed like an IP address. So they these fields will be compressed by the gzip algorithm.

Tests have shown that, when the compressed header information for each attribute (e.g. the <presence-bit> for the i= attribute) were are directly followed by the text value (the textual description), the gzip algorithm works very poor. Because of this, the compressed SDP packet will be splited in four sections. 

+----------------------+
| version              |
+----------------------+
| header-length        |
+----------------------+
| header               |
+----------------------+
| compressed text data |
+----------------------+
The version section simply defines the SDP and CSDP version. The header-length section defines the number of bytes occupied by the version, the header-length and the header. The header section contains all the compressed SDP data, excluding the compressed text data. The last section contains the sequential appended text, which is compressed by gzip (the whole collected text-buffer will be compressed, not each attribute separately!).

The last section begins on a byte boundary. Because the compression is bit oriented, the last octet of the header section may be padded to the byte boundary. This can be done by appending 0 to 7 <final-bits>.

Theoretically, the length field can be ommited, because the end of the header can be detected automatically. The last Media Description group defines the end of the SDP packet, so the last byte is the one with the 0 presence-bit for the group. But during trying to implement the CSDP decompressing algorithm, we found out that it is a difficult to handle the text sections. Without the length indication, the parser has to parse the packet twice, resulting in a poor performance. So we decided to include the length indication.

B.4. CSDP Specification

The following sections specify the format of the compressed version of every attribute defined by SDP. The order given is the same as in the SDP draft.

For every length filed defined below, a value with all bits set to 1 is reserved to indicate a length extension. This allows us to efficient compress attributes with a usual length, and makes it still possible to encode larger attributes. The format and usage of the extension mechanism has not been defined up to now.

Each attribute but the version one, is preceded by a <presence-bit> as defined above. It is indicated by a P-bit.

B.4.1. Version (v=)

This field is mandatory for all SDP packets, and it is the only one, which is NOT preceded by the presence-bit!

B.4.2. Header-Length

This is not a SDP attribute, but is necessary for decoding the compressed SDP packet. This field indicates the length of the header, which preceeds the compressed text section.

B.4.3. Origin (o=)

The origin field specifies the origin of the announcement.

B.4.4. Session Name (s=)

This field gives the session a reasonable name.

B.4.5. Session Description (i=) or Media Title

This optional attribute describes the session.

B.4.6. URI (u=)

This optional attribute specifies an URI for further informations about the session.

B.4.7. E-Mail (e=)

This optional attribute defines an e-mail address for a contact person regarding the session. This field can be repeated.

B.4.8. Phone Number (p=)

This attribute defines a phone number for a contact person regarding the session. This field can be repeated and is optional.

B.4.9. Connection Information (c=)

This attribute defines where the session is being transmitted (i.e. on which network address). It is optional and can be repeated. This filed can also be used in the Media Description group.

B.4.10. Bandwidth (b=)

This optional attribute specifies the bandwidth consumed by the session.

B.4.11. Times (t=)

This attributes defines the time, when the session will be active. It also starts the Time Description group. If it is present, then the group definition (t=, r= and z=) will come next. Otherwise these other attributes will be skipped.

B.4.12. Repeat Interval (r=)

This optional attribute specifies, when the session will be repeated. Note that this field can only occur within a Time Description group.

B.4.13. Timezone Adjust (z=)

This optional attribute specifies, some kind of timezone adjustments. Note that this field can only occur within a Time Description group.

B.4.14. Encryption Key (k=)

B.4.15. Session Attribute (a=)

This attributes defines additional attributes.

B.4.16. Media (m=)

B.4.17. Combined Compression of <net-type> <addr-type> <addr>

Network-addresses are specified as a triple in SDP. In contrast of coding each part separately, we will combine these three field into one logical unit.

The compressed version consists of a fix 4 bit header which defines the combined type of the address format. The following formats has been defined up to now:

B.5. Comparison of SDP and CSDP

The following is a comparison of the SDP, the gziped SDP and the CSDP sizes. The SDP packets has been grabbed from the INTERNET during several hours, so they represent a set of usual transmitted SDP packets. The packets are ordered on the original size: 
Nr	SDP/bytes	gzip'd	ratio/\%		CSDP	ratio/\%

19	178		157	11.7		86	51.6
04	274		210	23.3		158	42.3
20	336		245	27.0		194	42.2
16	356		260	26.9		195	45.2
09	371		247	33.4		201	45.8
18	378		290	23.2		217	42.5
01	381		286	24.9		228	40.1
14	381		298	21.7		230	39.6
05	406		293	27.8		213	47.5
03	408		294	27.9		231	43.3
24	416		307	26.2		249	40.1
07	458		304	33.6		248	45.8
06	459		309	32.6		255	44.4
21	466		309	33.6		238	48.9
23	505		340	32.6		245	51.4
15	505		341	32.4		245	51.4
17	505		341	32.4		245	51.4
11	518		354	31.6		291	43.8
22	531		342	35.5		250	52.9
10	565		380	32.7		316	44.0
13	644		429	33.3		351	45.4
08	647		394	39.1		305	52.8
12	665		447	32.7		356	46.4
02	744		435	41.5		372	50.0
25	834		524	38.3		399	52.1
00	837		517	38.2		360	56.9

The following is a graph, which compares the size of the compressed SDP packet, once compressed by gzip and once with the method described here:

You can see very clear that the CSDP compression is much more effective than simply applying gzip to the SDP packet, as expexected by the author. BTW, it is interesting that the two plots have nearly the same shape, but they the CSDP plot is lowered by an offset compared to gzip.

Another interesting comparison is the compression ratio using the two different compression tachniques:

Once again you can see that the shape is nearly the same. But the major result is, that the CSDP method has a compression ratio of approximately 40% to 55 %, compared to 15% to 40% when using gzip. The arithmetic mean of the gziped SDP packet is 30.5%. It is 46.8% when using the CSDP compression.

B.6. Summary

As shown in the last sections, the here explained method for compressing SDP packets is much more efficient than simply using gzip. The average gain compared to gzip is about 15% (46.8% - 30.5%), which seems to be a notable value.

But there are also some kind of pitfalls. First, the compression algorithm shown here strictly relies on the order of the SDP lines. While implementing the algorithm explained above, I realized that there are still a lot of SDP packets on the net, which do not strictly care about the order, even sdr. So prior to compression, a reordering of the fields was necessary. Doing so results in correctly ordered SDP packets, so that there was no packet, which couldn't be compressed.

Of course, extending the SDP (e.g. adding new tags) will cause a problem. But it should be easy to adapt such changes to CSDP as well.

File was created Wed Feb 26 17:43:11 1997 by tex2html