Subject: Re: [rohc] SigComp and SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 02:01:22 -0400

more old email. So sue me. Responses inline:

Gonzalo Camarillo wrote:
> Jonathan,

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

Why doesn't it? If a proxy is sigcomp enabled, it should have 
record-routed with sigcomp parameter in the first place.

-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

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Jun 2002 10:40:02 +0300

Jonathan,

inline:

> record-routed with sigcomp parameter in the first place.

If we specified that a proxy that supports SigComp MUST use it,
everything would work as you stated. However, I would like a proxy to
have the possibility of not using SigComp even if it supports it.

Section 7 of:
http://search.ietf.org/internet-drafts/draft-camarillo-sip-compression-01.txt

contains an example about the scenario I was describing in my previous
mail.

Thanks for the comments,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Jun 2002 16:10:32 -0400

Gonzalo Camarillo wrote:
>>>>>  If this URI contains the parameter comp=sigcomp, the proxy
>>>>
> SHOULD
> 
>>>>add
>>>>
>>>>parameter is ignored, and the message is sent uncompressed. Thats
>>>
> what
> 
>>>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).
>>

Well, you are trying to achieve the (somewhat odd) goal of allowing the 
proxy to indicate that it would prefer not to use sigcomp, unless 
someone around it doesn't record-route, so that sigcomp would be needed 
in order to avoid unidirectional compression. Is there a reason for 
supporting this case? For any individual dialog, either a proxy 
indicates it can do compression, or it doesn't. I don't see the need for 
this case, and it complicates what is otherwise a fairly simple and 
elegant solution.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Jun 2002 11:19:44 +0300

Hello,

> this case, and it complicates what is otherwise a fairly simple and

The trade-off we have is the following:

If we go for the simplest mechanism, every time two adjacent proxies
support SigComp, they will exchange compressed messages. This means that
when two wireless terminals exchange SIP signalling thru a set of
SigComp capable proxies, all the messages will be compressed, even
between proxies.

We can avoid this and make that compression is used only over the air
interface (i.e., not between the proxies in our example), but we have to
have proxies inspect Record-Route header fields.

If folks think that it is OK that two proxies that support SigComp MUST
always exhange compressed messages, I will be glad to simplify the
draft. If people feel that compressing when it is not really needed is
unacceptable, we will keep the current Record-Route inspection
mechanism.

Personally, if nobody has big concerns about performance of precessing
power, I would suggest that we simplify the mechanism and make it
mandatory the use of compression for all entities that support SigComp
(as suggested by Jonathan).

Regards,

Gonzalo