Subject: RE: [rohc] Examples for Uni-Directional Compression

From: [email-masked]
Date: Thu, 15 Apr 2004 18:12:00 +0300

Hi,

This could happen with erroneous SIP implementation
that does not comform to RFC3486 i.e. does not
set comp=sigcomp flag in the Via header field of SIP request.

br, paulius

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: Thursday, April 15, 2004 5:36 PM
> To: [email-masked]
> Subject: [rohc] Examples for Uni-Directional Compression
> 
> 
> 
> 
> 
> 
> Hi all,
>      RFC 3320 mentions that unidirectional compression is 
> possible using
> SIGCOMP.
> According to my understanding
> 
>       A
> B
>       |        SiGComp Compressed Message       |
>       |---------------------->----------------------------------- |
>       |                             |
>       |                             |
>       |  Un Compressed Message (normal)   |
>       |-----------------------<---------------------------------- |
>       |                             |
>       |                             |
> 
> That means that Endpoint B is also SIGCOMP aware .
> My basic doubts is in which pratical scenario Endpoint B will 
> choose to
> send
> normal message in place of the compressed messages.This is 
> will drastically
> effect the compression ratio.
> 
> Thanks & Regards
> Saurabh
> 
> Saurabh Gupta - HSS Bangalore Ext 7067
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: [email-masked]
Date: Fri, 16 Apr 2004 16:10:16 +0530

Hi Richard,
      From your mail I understand that in downlink direction (which does
not want to do compression),
the sigcomp message can be formed with following specifications to achieve
higher compression ratio:-
1.  Returned feedback data containing state information
2. The 12-bit code_len field which specifies the size of the uploaded UDVM
bytecode must
be set to zero (to specify "null" decompression algorithm)

So incase Decompressor dispatcher receives SigComp message which has
code_len field set to
zero then it must return the message as it to the application but it must
process the feedback response.

Please confirm if this understanding is correct.

thanks and regards
Jyoti

             "Richard Price"                                               
             <ellyptic@hotmail                                             
             .com>                                                      To 
                                       [email-masked]                 
             04/16/04 03:23 PM                                          cc 
                                       [email-masked],                      
                                       [email-masked]              
                                                                   Subject 
                                       RE: [rohc] Examples for             
                                       Uni-Directional Compression         

                                                                           

Hi Jyoti,

If you want to use the SigComp feedback mechanism to
improve the compression ratio in the uplink direction, but
don't need to compress the messages in the downlink
direction, then you can apply SigComp to the downlink
messages with a "null" compression algorithm.

In other words, you can use SigComp in both directions,
with an efficient, CPU-intensive algorithm in the uplink
direction where compression is useful, and a null algorithm
that just attaches a SigComp header to the raw
uncompressed message in the downlink direction where
compression isn't needed.

Regards,

Richard

>From: [email-masked]
>To: "Richard Price" <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked]
>Subject: RE: [rohc] Examples for Uni-Directional Compression
>Date: Fri, 16 Apr 2004 10:54:45 +0530
>
>Hi Richard,
>        I have another doubt in this :- Incase application wants to
>compress in one direction (say uplink) and not in other direction
>(day downlink) then  how can "feedback mechanism" be used
>to establish the "state" (since the ack for the state established
>is sent in sigcomp message and remote application is not sending
>any sigcomp message). Further,that means in case the
>compression is uni-directional and feedback mechanism can not
>be used for establishing state ,So overall compression ratio will
>be very less (because decompression bytecode will be sent
>everytime).
>
>So, Doubt is that although in practical scenario, compression in
>one direction is possible but which mechanism does SigComp
>provide to achieve this feature so that compression ratio is less.
>
>
>regards
>Jyoti

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger