9. Example
The following example illustrates the use of the parameters defined above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake between a UAC and a UAS through two proxies. Proxy P1 does not Record-Route but proxy P2 does. Both proxies support compression, but they do not use it by default. UAC P1 P2 UAS |(1)INVITE(c) | | | |------------>| (2) INVITE | | | |------------>| (3) INVITE | | | |------------>| | | | (4) 200 OK | | | (5) 200 OK |<------------| |(6)200 OK(c) |<------------| | |<------------| | | | | (7)ACK(c) | | |-------------------------->| (8) ACK | | | |------------>| | | | | | | | | Figure 1: INVITE transaction through two proxies Messages (1), (6) and (7) are compressed (c). We provide a partial description of the messages involved in this call flow below. Only some parts of each message are shown, namely the Method name, the Request-URI and the Via, Route, Record-Route and Contact header fields. We have not used a correct format for these header fields. We have rather focus on the contents of the header fields and on the presence (or absence) of the "comp=sigcomp" parameter. (1) INVITE UAS Via: UAC;comp=sigcomp Route: P1;comp=sigcomp Contact: UAC;comp=sigcomp P1 is the outbound proxy of the UAC, and it supports SigComp. The UAC is configured to send compressed traffic to P1, and therefore, it compresses the INVITE (1). In addition, the UAC wants to receive future requests and responses for this dialog compressed. Therefore, it adds the comp=Sigcomp parameter to the Via and to the Contact header fields. (2) INVITE UAS Via: P1 Via: UAC;comp=sigcomp Route: P2 Contact: UAC;comp=sigcomp P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2. (3) INVITE UAS Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAC;comp=sigcomp P2 forwards the INVITE (3) to the UAS. P2 supports compression, but it does not use it by default. Therefore, it sends the INVITE uncompressed. P2 wishes to remain in the signalling path and therefore it Record-Routes. (4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS The UAS generates a 200 OK response and sends it to the host in the topmost Via, which is P2. (5) 200 OK Via: P1 Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS P2 receives the 200 OK response. P2 Record-Routed, so it inspects the Route set for this dialog. For requests from the UAS towards the UAC (the opposite direction than the first INVITE), the next hop will be the Contact header field of the INVITE, because P1 did not Record-Route. That Contact identified the UAC: Contact: UAC;comp=sigcomp Since the UAC wants to receive compressed requests (Contact of the INVITE), P2 assumes that the UAC would also like to send compressed requests (Record-Route of the 200 OK). Therefore, P2 modifies its entry in the Record-Route header field of the 200 OK (5). In the INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds it in the 200 OK (5). This will allow the UAC sending compressed requests within this dialog. (6) 200 OK Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter. (7) ACK UAS Via: UAC;comp=sigcomp Route: P2;comp=sigcomp Contact: UAC;comp=sigcomp The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route). (8) ACK UAS Via: P2 Via: UAC;comp=sigcomp Contact: UAC;comp=sigcomp P2 sends the ACK (8) uncompressed to the UAS.
