Re: [rohc] SigComp with EPIC compression for SIP messages

"Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com> 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

>-----Original Message-----
>From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Lepine, Jean-Pierre
>Sent: den 18 februari 2005 19:18
>To: rohc@ietf.org; sip@ietf.org; sipping@ietf.org
>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.

>_______________________________________________
>Rohc mailing list
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc