Subject: RE: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sun, 5 Nov 2006 21:39:39 +0100

Can someone clarify for me the current status of NACK in regard to
SigComp.

This draft seems to imply that it is mandatory in some form but I don't
remember any statement in other ROHC documents implying that it is
anything other than just another optional extension.

Can someone point me at some words.

Regards

Keith

> -----Original Message-----
> From: cco [mailto:[email-masked]] 
> Sent: 31 October 2006 18:45
> To: [email-masked]'
> Cc: Gonzalo Camarillo; SIP WG; Drage, Keith (Keith); Dean Willis
> Subject: Re: [rohc] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03
> 
> On Tue, Oct 31, 2006 at 10:04:49AM -0600, Adam Roach wrote:
> > I have been asked to perform a dedicated review on the document 
> > draft-ietf-rohc-sigcomp-sip-03. My comments follow. Note 
> that I have 
> > implemented this specification, any many of my comments arise from 
> > issues I identified during such implementation.
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > I'm having a lot of difficulty parsing the final paragraph 
> in section
> > 3.2:
> > 
> >   Compressors that make use of initial state memory MUST 
> implement the
> >   SigComp Negative Acknowledgement (NACK) Mechanism 
> [RFC4077].  (Note
> >   that there is no such requirement on decompressors, but see also
> >   Section 6.)  For this requirement, initial state memory 
> is defined as
> >   the assumption of a non-zero SMS value before having received an
> >   advertisement of non-zero SMS (e.g., via returned parameters as
> >   specified in section 9.4.9 of [RFC3320]); ANY/SigComp as 
> defined in
> >   [RFC3320] does not have initial state memory.
> 
> cristian: and this gets even more confusing since at 3.4 we can read:
> 
> 3.4.  SigComp_version (SV) for SIP/SigComp
> 
>    For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320].
> 
>    For SIP/SigComp: >= 0x02 (at least SigComp + NACK)
> > 
> > 
> > There are two separate points of confusion for me:
> > 
> >   1. I don't understand the assertion that decompressors 
> don't need to
> >      implement RFC 4077. Decompressors serve the critical role of
> >      generating NACK messages when decompression fails. 
> (And, in fact,
> >      text at the end of section 6.3 implies that NACK 
> implementation is
> >      required in decompressors as well).
> > 
> >   2. The document has already established that stateless compression
> >      (i.e., compression that doesn't take advantage of initial state
> >      memory) is pointless for SIP endpoints -- so the clause
> >      "Compressors that make use of initial state memory" pretty much
> >      collapses to just "Compressors."
> > 
> > So, unless I've missed something, this paragraph should be 
> rewritten as:
> > 
> >    SIP/SigComp endpoints MUST implement the SigComp Negative
> >    Acknowledgement (NACK) Mechanism [RFC4077].
> 
> cristian: I think this should clear everything up; and there 
> should be no doubts on whether NACK should be used or not.
> 
> since you have already mentioned sipit, here is the 
> experience I have gained from the sigcomp testing done at the 
> last one: 
> clients that use dynamic compression but do not impl. NACK 
> _cannot_ recover from compartment/state mismanagement (which 
> can happen for various reasons either at the proxy or at the 
> client side); clients that implement NACK _do_ recover.
> 
> bye now!
> cristian
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 06 Nov 2006 01:53:38 +0200

Hi,

NACK support will be mandatory.

Cheers,

Gonzalo