Subject: RE: [rohc] SigComp USD upload

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Tue, 6 Sep 2005 16:06:40 +0200

Hi Carsten,
I think that it should if possible be a SigComp message and not a SIP message to do this, in order to separate the sigcomp functionality from SIP. However I have a feeling that SIP might be the right place from a current security/authentication perspective.

BR
Jan

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: den 6 september 2005 11:10
To: Jan Christoffersson (LU/EAB)
Cc: Carsten Bormann; rohc
Subject: Re: [rohc] SigComp USD upload

One question is whether this signalling has anthing to do with the  
SigComp protocol itself.
NACK obviously has to; here it seems that having a way to establish a  
state (SigComp protocol) and a way to pin down this state as part of  
the registration or some other protocol (*outside* SigComp, maybe  
some SIP-based mechanism) is the right way to handle this.

Maybe a new header:

SigComp-Dictionary-That-Is-Meant-To-Become-Part-Of-My-Registration- 
State: fe207a704564d25d6497a188af39a098513b5517

(The state-ID needn't be in hex, base64 might be better.)

Gruesse, Carsten

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

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Tue, 6 Sep 2005 16:07:36 +0200

Hi Pekka,
comments inline.

BR
Jan
-----Original Message-----
From: Pekka Pessi [mailto:[email-masked]]
Sent: den 6 september 2005 14:05
To: Jan Christoffersson (LU/EAB)
Cc: rohc
Subject: Re: [rohc] SigComp USD upload

"Jan Christoffersson (LU/EAB)" <[email-masked]> writes:
>An efficient way to use SigComp for compression of SIP (and other
>protocols too, I assume) is to use some kind of user specific
>dictionary (USD), i.e. a dictionary which is specific to a
>particular user. One issue with the USD is how to get it in place
>to begin with. Currently it must be uploaded from the UE to the
>proxy in the same way as the byte code is. 

I have thought that a typical USD would be "shared state", a state
that is created in UDVM side and announced as locally available
state using returned_parameters. It can be created just like any
other dynamic state, I don't see why it has to be uploaded
separately.

[Jan]The main problem with this approach is that you have to wait for a SIP message (which could be a time critical message). Another is that a shared state should be "an uncompressed version of a compressed message" [RFC 3321]. But in principle it could be done in this way.

...
>I think what is needed is some out-of-band signalling, sent
>without an application (SIP) message, and with the ability to
>save state. Then this message could be sent before the time
>critical signalling to upload the USD before it is needed and
>thereby ensure efficient compression from the start. This
>out-of-band signalling is similar to the NACK message, which is
>also sent without a SIP message.

If the SIP application using SigComp uses compartments tied to
registrations, it is always possible to send a dummy SIP request
(OPTIONS, for instance) to outbound proxy and use it to set up the
USD. Likewise, if you happen to use compartments bound to a
dialog, you can send an OPTIONS request with Max-Forwards: 1
within that dialog.

[Jan]Having SigComp to prompt the application to send a dummy message feels a bit strange. If possible, SigComp should be transparent to SIP (I know, this may not always be possible..).