Subject: RE: [rohc] draft-ietf-rohc-sigcomp-sip-08.txt and stateless compression

From: "Ofer Goren" <[email-masked]>
Date: Mon, 10 Dec 2007 15:49:10 +0200

Hi.

Stateless compression is defined as a compression without compartment.
Endpoint A, who does not support NACK recieves a compressed message from
B. Since B used a stateless compression in my example, B does not store
any states. How can A knows about it?

Maybe I'm missing something?

Thanks,
Ofer 

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Friday, November 30, 2007 17:39
> To: Ofer Goren
> Cc: [email-masked]
> Subject: Re: [rohc] draft-ietf-rohc-sigcomp-sip-08.txt and 
> stateless compression
> 
> On 11/27/07 9:40 AM, Ofer Goren wrote:
> > Section 9.4 in the draft suggests that stateless compression is not 
> > recommended.
> >  
> > What if I have a session going between endpoint A supporting this 
> > draft (sigcomp ver = 0x02) and an endpoint B with old 
> sigcomp version 
> > (0x01). B is sending a message using stateless compression. How can 
> > endpoint A know that no states were created on B? In other 
> words, what 
> > is the backward compatibility procedures when dealing with 
> stateless 
> > compression?
> 
> SigComp version 1 supports the storage of states -- in other 
> words, B _would_ store the states that A expected B to store 
> (and vice-versa). 
> The only difference between the versions is whether a 
> decompression failure causes a NACK message to be sent.
> 
> It seems to me that you may be confusing "stateful 
> compression" with the "shared compression" technique 
> described in RFC 3321. "Shared compression" is also 
> unaffected by the difference in UDVM versions.
> 
> /a
> 

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

---

From: "Ofer Goren" <[email-masked]>
Date: Mon, 10 Dec 2007 17:18:16 +0200

Hi.

I have several questions regarding chapter 9 of the draft:

1. If a UAC does not know the sigcomp-id of the UAS it sends messages
to, how should it obtain it?

2. Should a Proxy and a registrar share the same sigcomp-id if serviced
by the same entity (are they defined as 2 separate application for the
purpose of this draft)?

3. Suppose UAC wants to send a compressed REGISTER to the registrar. It
does not know the registrar's sigcomp-id, so compartment will be created
based on the remote address/connection. The 200 OK will be mapped to the
same compartment created for the REGISTER (as stated in 9.1, incoming
responses). If the REGISTRAR and the Proxy share the same sigcomp-id, a
new INVITE that will be sent from the UAC, will create a new
compartment, if created based on this sigcomp-id. Am I correct?

Thank you very much,

Ofer.

---

From: cco <[email-masked]>
Date: Thu, 13 Dec 2007 11:23:20 +0100

> any states. How can A knows about it?

cristian: you want to say that B is compressing packetwise and NOT
streamwise, right?

why should A know about it? as long as the decompression bytecode sent
by B is suitable for its compression and is working correctly A can
decompress without knowing the compression strategy used by B. (this is
the whole idea behind the UDVM)

otoh a real problem appears when B _uses_ stream (stateful) compression
and A does not support NACK...

bye now!
cristian