Subject: [rohc] SigComp and SIP

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Apr 2002 13:04:38 +0300

Folks,

I have put together a draft about how to use SigComp and SIP.

Until it appears in the archives, you can fetch it from:
http://www.cs.columbia.edu/~gonzalo/draft-camarillo-sip-compression-00.txt

Note that this draft does *not* describe a DNS based approach.

As usual, feedback is welcome.

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 10:04:26 -0400

Gonzalo,

I think this is definitely a step in the right direction. I'll note that
this is yet another thing that wouldn't work without loose routing :)

A few comments:

* Section 3 leaves out an important means for obtaining the URI -
configuration. Ultimately, we want to move towards configuration of
outbound proxies through URIs, NOT IP addresses. One reason is that we
can support supplemantal information, just like this, as part of the
URI. 

* 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. Indeed, the
heuristics are somewhat ill defined. For example:

>  o In a previous transaction, the client obtained a URI for the
>           same server with the parameter comp=sigcomp (e.g., a Contact
>           header field in a 2xx response for a previous OPTIONS request
>           or an entry in the route set of a previous dialog).

How do I know that the OPTIONS request this time was routed to the same
element that got it last time? Indeed, if, last time, the contact URI in
the 2xx to OPTIONS had a comp param, and this time, it doesn't, isn't
this a good sign that it has NOT been routed to the same UA?

* 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. 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.

> 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.

>  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.

* section 7 - i think these considerations are addressed by sigcomp
itself. You should really discuss whether the proposed mechanism
introduces additional issues.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com