rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Thierry,

> What I expected is a complete reset of the compressor with
> intermediate variables and without the byte indicating the choice of
> the context.
> 
> For me, reseting is like making free and then a create the compressor.

You're right that the ROHC library does not perform a reset that
behaves like a free + create. The internal variables of the context are
not all reset to their default value.

The state/mode are reset, so one RTP stream for example goes back to
mode Unidirectional and state IR, and it will start emitting IR packets
for the first next packet of the streams.

In contrast, other context variables are not changed. This especially
true for the context variables that define:
 - whether a context is used or not,
 - the streams that matches the contexts.

In the real-world, that means that a full reset (ie. free + create, or
any equivalent without memory free/allocation) will cause a Context
ID / stream change, while the current reset won't.

With an example:
 * let's say we have 3 streams before reset:
     stream #1 uses CID 0
     stream #2 uses CID 1
     stream #3 uses CID 2
     (other contexts are not used)
 * now, we perform a full reset and start receiving the streams in the
   order #3, #2, #1:
     stream #3 starts using CID 0 and emits IR packet
     stream #2 starts using CID 1 and emits IR packet
     stream #1 starts using CID 2 and emits IR packet
     (other contexts are not used)
 * if instead of a full reset, we perform a current reset and start
   receiving the streams in the order #3, #2, #1:
     stream #1 still uses CID 0 but emits IR packet
     stream #2 still uses CID 1 but emits IR packet
     stream #3 still uses CID 2 but emits IR packet
     (other contexts are not used)

Another example with less streams after reset:
 * let's say we have 3 streams before reset:
     stream #1 uses CID 0
     stream #2 uses CID 1
     stream #3 uses CID 2
     (other contexts are not used)
 * now, we perform a full reset and start receiving only 2 streams in
   the order #3, #2:
     stream #3 starts using CID 0 and emits IR packet
     stream #2 starts using CID 1 and emits IR packet
     (other contexts are not used)
 * if instead of a full reset, we perform a current reset and start
   receiving only 2 streams in the order #3, #2:
     stream #1 still uses CID 0 but emits IR packet
     stream #2 still uses CID 1 but emits IR packet
     stream #3 still uses CID 2 but emits IR packet
     (other contexts are not used)

So, a current reset does not cause a stream/CID re-association as a
full reset would do. From my point of view, it doesn't seem to be a
major problem in real world. But maybe that behaviour does not fit
well with your own use case. Is it the case?

Regards,
Didier

Attachment: signature.asc
Description: PGP signature