Subject: [rohc] SigComp USD upload

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

Hi,
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. This procedure may be inefficient for a number of reasons e.g. 

1.The message which carries the USD will carry a significant overhead. If this is a time critical message, the effect of using SigComp on this message may even be worse than if not using sigcomp.

2. As has been noted in the sigcomp implementers guide (for uploading byte codes) draft-ietf-rohc-sigcomp-impl-guide-05.txt, the upload mechanism can be inefficient in case of limited DMS since in principle two copies of the uploaded state must be stored (one with the compressed message and one in the circular buffer). This may also make the upload of the USD difficult or even impossible with some messages.

Compression using a USD has the potential to be really effective (perhaps the only way to be) from the start of a session, if the upload could be made efficient and done before the first time critical message.

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.

Is this something that others would find useful as well?

Best Regards
Jan

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Sep 2005 11:10:10 +0200

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

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 06 Sep 2005 15:04:58 +0300

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

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

Or do you have some special application in mind?

--Pekka