Subject: [Sip] RE: [rohc] SigComp with EPIC compression for SIP messages

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 21 Feb 2005 08:50:13 +0100

The EPIC work was an experimental work that was brought to the ROHC WG as a header compression proposal. The work was never adopted by the WG and was terminated about 2 years ago, but some of the ideas about Formal Notation (FN) have been used in the ROHC TCP work. 
 
The SigComp user guide did (I am not sure about the new version just released) refer to EPIC, which is probably a mistake as algorithms are not specified in that document, and there is no reference available for an EPIC algorithm. 
 
BR
/Lars-Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Lepine, Jean-Pierre
Sent: den 18 februari 2005 19:18
To: [email-masked]; [email-masked]; [email-masked]
Subject: [rohc] SigComp with EPIC compression for SIP messages

Hi all,

I am currently looking at using SigComp with EPIC compression for SIP messages. After reading relevant RFCs and Internet drafts, a few things are not clear to me.

First, I understand that EPIC relies on a profile to compress and decompress data. The EPIC reference implementation from Roke Manor Research Ltd provides a profile for RTP. However, I can't find a profile for SIP.

Is there one out there?

I think I can write one but this would likely be a problem for interoperability since the decompressor MUST use the same profile. One solution would be to download the profile to the other endpoint but this does not look too good to me, partly because I have a concern about the profile size. Furthermore, I don't see how I could instruct the other endpoint to use a downloaded profile (file name and location ?).

Any other option?

Also, in the SigComp User Guide (draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is talking about EPIC and SIP but never mentions the need or existence of a profile.

Without a profile, how can EPIC be used ?

The mentioned section also shows compression results for three algorithms, including EPIC. All algorithms employed a static dictionary and shared compression.

Exactly how the EPIC results were obtained is not clear to me, in particular how EPIC was used ?

Only the Hierarchical Huffman algorithm ?

EPIC used in conjunction with DEFLATE ?

Did all three algorithms used the static dictionary described in RFC3485 ?

Any help would be really appreciated, Thanks.

_______________________________________________
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

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 22 Feb 2005 19:49:12 +0200

"Lars-Erik Jonsson (LU/EAB)" <[email-masked]> writes:
>The SigComp user guide did (I am not sure about the new version just
>released) refer to EPIC, which is probably a mistake as algorithms are not
>specified in that document, and there is no reference available for an EPIC
>algorithm. 

As you can see from the UDVM assembly code (the text also mentions
it) the compression algorithm referred as EPIC is just DEFLATE
with minor modifications. The UDVM assembly code in section 4.6
(and RFC 1951) is all the specification you need. 

A message compressed with DEFLATE consists of literals (bytes
0..255, end-of-block) and pairs (length, distance), where length
is 3..258 and distance in 1..32768. "EPIC" modifies DEFLATE to use
INPUT-HUFFMAN-coding for literals and (length, distance) pairs
insted of the normal static huffman codes, as specified in RFC
1951.

So, unlike DEFLATE bytecode "EPIC" does not need tables and the
literal/length symbols and distance values can be directly decoded
with a single INPUT-HUFFMAN instruction each. Another improvement
(?) is with the literal/length, it has two different codings,
depending whether the last symbol was a literal or length+distance
pair.

--Pekka

>I am currently looking at using SigComp with EPIC compression for
>SIP messages. After reading relevant RFCs and Internet drafts, a
>few things are not clear to me.

>First, I understand that EPIC relies on a profile to compress and
>decompress data. The EPIC reference implementation from Roke
>Manor Research Ltd provides a profile for RTP. However, I can't
>find a profile for SIP.

>I think I can write one but this would likely be a problem for
>interoperability since the decompressor MUST use the same
>profile. One solution would be to download the profile to the
>other endpoint but this does not look too good to me, partly
>because I have a concern about the profile size. Furthermore, I
>don't see how I could instruct the other endpoint to use a
>downloaded profile (file name and location ?).

>Also, in the SigComp User Guide
>(draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is
>talking about EPIC and SIP but never mentions the need or
>existence of a profile.

>The mentioned section also shows compression results for three
>algorithms, including EPIC. All algorithms employed a static
>dictionary and shared compression.

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