RFC 3486:Compressing the Session Initiation Protoc...
RFC-Ref

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.

Google
Web
RFC-Ref