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

From: cco <[email-masked]>
Date: Tue, 31 Oct 2006 19:44:50 +0100

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

_______________________________________________
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: "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
> 
> 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
>