Subject: [rohc] rfc3485 state id as part of returned Sigcomp parameters?

From: "Vishal Sudan" <[email-masked]>
Date: Thu, 9 Mar 2006 22:06:21 +0530

Hi all,

I have a question regarding Sigcomp parameters.

rfc3320 says regarding Sigcomp Parameters in section 3.3

<quote from rfc3320 sec 3.3>
...the following parameters are
   provided to modify SigComp behavior when receiving SigComp messages:

   decompression_memory_size
   state_memory_size
   cycles_per_bit
   SigComp_version
   locally available state (a set containing 0 or more state items)

   Each parameter has a minimum value that MUST be offered by all
   receiving SigComp endpoints.  Moreover, endpoints MAY offer
   additional resources if available; these resources can be advertised
   to remote endpoints using the SigComp feedback mechanism.
</quote>

My question/doubt is whether a endpoint supporting the mandatory 3485 dictionary 
has to advertize it ( 3485 ) using the parameter mechanism?

The document is very clear on what has to be advertized using parameter 
mechanism - anything over and above the minimum capabilities. But is rfc3485 within
minimum capabilities for a SIP endpoint?

Thanks,
Vishal Sudan

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

---

From: "Vishal Sudan" <[email-masked]>
Date: Thu, 16 Mar 2006 12:18:48 +0530

Thanks for sharing your perspective - I guess thats the way to go.

Cheers,
Vishal Sudan

-----Original Message-----
From: Cristian CONSTANTIN [mailto:[email-masked]]
Sent: Friday, March 10, 2006 9:01 PM
To: John Barber
Cc: Vishal Sudan; [email-masked]
Subject: Re: [rohc] rfc3485 state id as part of returned Sigcomp
parameters?

On Thu, Mar 09, 2006 at 04:44:57PM -0000, John Barber wrote:
> Hi Vishal,
> 
> Good point. I don't think this is made clear in any of the relevant
> specifications.
> 
> Since all SIGCOMP implications for use with SIP *must* provide the
> Sip/Sdp dictionary as an item of locally-available state, it would not
> seem to be necessary to advertise it - the other end is entitled to
> assume that it is present in all cases.
> 
> My own implementation plan is:
> 1) Don't advertise it
> 2) If remote advertises it, ignore the advertisement
> 3) Assume that the bytecode I send can use the dictionary state item
at
> all times.

cristian: I make the same assumption.
(slightly off topic: I wonder if anyone has or works on having a sigcomp
stack for something else than SIP...)

bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net