Subject: [Sip] Re: [rohc] SigComp and SIP

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 May 2002 13:05:24 +0300

Jonathan,

thanks for the comments. Answers inline:

Jonathan Rosenberg wrote:

> * Section 3 leaves out an important means for obtaining the URI -
> configuration.

I actually listed confirguation in the second set of bullets. The ones
that deal with URIs without comp=sigcomp. However, in another of your
comments you propose to get rid of that list.

I will remove the second list and add "configuration" as a bullet here.

> * I think a client MUST NOT send a sigcomp request to a server if it
> doesn't know whether it supports compression. Section 3 provides cases
> in which you can sort of guess whether it does. I don't like that. The
> guesses are just that - guesses, and may be wrong. 

Yes, I agree. I will turn the SHOULD NOT into a MUST NOT and remove
these bullets.

> * I think its worth noting a few things about this approach. First, a
> proxy that gets a request uncompressed, and wants to get it compressed
> in subsequent requests, can return a 301 with a contact header that has
> the comp parameter. This will result in a caching of the binding in the
> client that sent the request.

Yes. I believe this is already covered with the bullet below:

\item The URI was obtained from a \header{Contact} header field in a 3xx
or 485 response to the request.

> Secondly, a SIP element that implements
> this will need to be prepared to receive compressed or uncompressed
> messages on the same port, and thus will need to look at the cookie in
> the topmost bits to demux.

Yes, this is the basic idea behind this approach. I have added the
following text:

"A SIP element that supports compression will need to be prepared to
receive compressed and uncompressed messages on the same port. It will
perform demultiplexing based on the cookie in the topmost bits of every
compressed message."

> 
> > A response is sent to the host in the sent-by parameter of the Via
> >    header field. If the topmost Via header field contains the parameter
> >    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
> >    response SHOULD NOT be compressed.
> 
> I would say MUST NOT be compressed. The criteria is - will things work
> if you violate this? If I send a compressed response to something which
> doesn't support it, the response is discarded. The result is total
> failure of the transaction. There is no recovrey. So, it should be MUST
> NOT.

OK, it will be a MUST NOT.
 
> >  A proxy performing Record-Route inspects the Record-Route and the
> >    Contact header fields in the response. It looks for the URI of the
> >    next upstream (closer to the user agent client) hop in the route set.
> >    If this URI contains the parameter comp=sigcomp, the proxy SHOULD add
> >    comp=sigcomp to its entry in the Record-Route header field.
> 
> Why? If the upstream element doesn't support this extension, the sigcomp
> parameter is ignored, and the message is sent uncompressed. Thats what
> you want. The decision about whether to insert a URI with the comp
> parameter should be entirely a local one.

This covers the following scenario:

UAC----P1-----P2-----UAS

The UAC sends an INITE to UAS. P2 records route, but P1 does not.
When the 200 OK for the INVITE reaches P2, the contact and RR header
fields will look like this:

Contact: [email-masked];comp=sigcomp
RR: P2

If P2 does not add comp=sigcomp to his entry in the RR, UAC will be able
to receive compressed traffic (the contact has comp=sigcomp), but will
be unable to send compress traffic (the RR entry for P2 does not have
it).

Making P2 add comp=sigcomp resolves this asymmetry

Thanks for the comments,

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip