4. Sending a Request to a Server
A request is sent to the host part of a URI. This URI, referred to
as the next-hop URI, is the Request-URI of the request or an entry in
the Route header field.
If the next-hop URI contains the parameter comp=sigcomp, the client
SHOULD compress the request using SigComp as defined in [2].
If the next-hop URI is a SIPS URI, the request SHOULD be compressed
before it is passed to the TLS layer.
A client MUST NOT send a compressed request to a server if it does
not know whether or not the server supports SigComp.
Regardless of whether the request is sent compressed or not, if a
client would like to receive subsequent requests within the same
dialog in the UAS->UAC direction compressed, this client SHOULD add
the parameter comp=sigcomp to the URI in the Contact header field if
it is a user agent client. If the client is a proxy, it SHOULD add
the parameter comp=sigcomp to its URI in the Record-Route header
field.
If a user agent client sends a compressed request, it SHOULD add the
parameter comp=sigcomp to the URI in the Contact header field. If a
proxy that Record-Routes sends a compressed request, it SHOULD add
comp=sigcomp to its URI in the Record-Route header field.
If a client sends a compressed request, it SHOULD add the parameter
comp=sigcomp to the topmost entry of the Via header field.
If a client does not know whether or not the server supports SigComp,
but in case the server supported it, it would like to receive
compressed responses, this client SHOULD add the parameter
comp=sigcomp to the topmost entry of the Via header field. The
request, however, as stated above, will not be compressed.
For requests within a dialog, a next-hop URI with the comp=sigcomp
parameter is obtained from a Record-Route header field when the
dialog is established. A client sending a request outside a dialog
can also obtain SIP URIs with comp=sigcomp in a Contact header field
in a 3xx or 485 response to the request.
However, clients establishing a session will not typically be willing
to wait until the dialog is established in order to begin compressing
messages. One of the biggest gains that SigComp can bring to SIP is
the ability to compress the initial INVITE of a dialog, when the user
is waiting for the session to be established. Therefore, clients
need a means to obtain a comp=sigcomp URI from their outbound proxy
before the user decides to establish a session.
One solution to this problem is manual configuration. However,
sometimes it is necessary to have clients configured in an automatic
fashion. Unfortunately, current mechanisms for SIP client
configuration (e.g., using DHCP [6]) do not allow to provide the
client with URI parameters. In this case, the client SHOULD send an
uncompressed OPTIONS request to its outbound proxy. The outbound
proxy can provide an alternative SIP URI with the comp=sigcomp
parameter in a Contact header field in a 200 OK response to the
OPTIONS. The client can use this URI for subsequent requests that
are sent through the same outbound proxy using compression.
RFC 3261prop [1] does not define how a proxy should respond to an OPTIONS
request addressed to itself. It only describes how servers respond
to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261prop
says:
Contact header fields MAY be present in a 200 (OK) response and
have the same semantics as in a 3xx response. That is, they may
list a set of alternative names and methods of reaching the user.
We extend this behavior to proxy servers responding to OPTIONS
addressed to them. They MAY list a set of alternative URIs to
contact the proxy.
Note that receiving incoming requests (even initial INVITEs)
compressed is not a problem, since user agents can REGISTER a SIP URI
with comp=sigcomp in their registrar. All incoming requests for the
user will be sent to this SIP URI using compression.
