Subject: [rohc] SigComp, the SIP dictionary and local states

From: "Lepine, Jean-Pierre" <[email-masked]>
Date: Tue, 1 Mar 2005 09:31:30 -0500

Hi all,<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

I would like to clarify a few things about SigComp, the SIP dictionary and
local states.

The SIP dictionary is a mandatory local state for a SIP implementation of
SigComp. In RFC 3485, the introduction says:

"The static SIP/SDP dictionary constitutes a SigComp state that can be
referenced in the first SIP message that the compressor sends out."

Also, regarding the requested feedback data, RFC 3320 at p.54 says:

"...the compressor sets the I-bit to 1 if it does not wish (or no longer
wishes) to access any of the locally available state items offered by the
receiving endpoint."

>From this, I understand that a compressor can ALWAYS access the SIP
dictionary at the remote endpoint, UNLESS it sets the I-bit in its requested
feedback data. This is the only way that the SIP dictionary can become
inaccessible to a compressor.

Am I right ?

A related but more general concern about local states is their relation with
compartments. RFC 3320 at p.22 says:

"Note that locally available state items (as described in Section 3.3.3)
need not be mapped to any particular compartment.  However, if they are
created on a per-compartment basis, then they must not interfere with the
state created at the request of the remote endpoint.  The special
state_retention_priority of 65535 is reserved for locally available state
items to ensure that this is the case."

I have a concern if an implementation chooses to create local states on a
per-compartment basis, which would be legal according to the above
statement. In this case, I understand that if a remote compressor creates
new state items, these can require lower priority states, including local
states, to be freed and hence become inaccessible to this compressor. If I
am right, this would be another way that the SIP dictionary can become
inaccessible to a compressor. However, I hope I am wrong because this could
likely create interoperability issues, since a compressor has no way to know
how local states are handled at the remote endpoint, i.e. created on a
per-compartment basis or not.

What about that ?

Thanks in advance for your help.
 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Pekka Pessi <[email-masked]>
Date: Thu, 03 Mar 2005 15:16:27 +0200

"Lepine, Jean-Pierre" <[email-masked]> writes:
>I would like to clarify a few things about SigComp, the SIP dictionary and local states.:p>

>The SIP dictionary is a mandatory local state for a SIP implementation of SigComp. In RFC 3485,
>the introduction says::p>

>"The static SIP/SDP dictionary constitutes a SigComp state that can be referenced in the first
>SIP message that the compressor sends out.":p>

>Also, regarding the requested feedback data, RFC 3320 at p.54 says::p>

>"...the compressor sets the I-bit to 1 if it does not wish (or no
>longer wishes) to access any of the locally available state items
>offered by the receiving endpoint.":p>

>From this, I understand that a compressor can ALWAYS access the
>SIP dictionary at the remote endpoint, UNLESS it sets the I-bit
>in its requested feedback data. This is the only way that the SIP
>dictionary can become inaccessible to a compressor.:p>

Generally speaking, a UDVM instance can access state items from
other compartments as well as from their own. This has been
mentioned in RFC 3321. It makes sense, because usually the SigComp
implementation can not know to which compartment the message
belongs. It is up to application to decide.

So, even setting the I-bit does not make the SIP/SDP state
unavailable.

...
>I have a concern if an implementation chooses to create local
>states on a per-compartment basis, which would be legal according
>to the above statement. In this case, I understand that if a
>remote compressor creates new state items, these can require
>lower priority states, including local states, to be freed and
>hence become inaccessible to this compressor. If I am right, this
>would be another way that the SIP dictionary can become
>inaccessible to a compressor. However, I hope I am wrong because
>this could likely create interoperability issues, since a
>compressor has no way to know how local states are handled at the
>remote endpoint, i.e. created on a per-compartment basis or
>not.:p>

RFC 3320 makes it quite clear if I-bit is set, an endpoint can
delete state items which it has offered to remote compressor. 
However, It does not tell whether the state items can be deleted
when the I-bit is not set.

This was discussed last August and November. However, the
conclusion was a bit confusing, if there was a conclusion.

I think that the consensus was that the compartment-specific
locally-available state items (LASI for short - that is very
fragile stuff in Finnish) can be deleted even without UDVM
bytecode setting the I-bit if the UDVM saves state items that push
the LASI out of the compartment. The controversial issue was
whether the local compressor can add more LASIs that can sneakily
push *earlier* LASIs out from compartment when the UDVM creates
its own state items. This may lead to failed decompression of
messages sent by remote end, because the knowledge of later LASI
may not reach remote at all or only after it has sent its own
message.

*I* think that both choises pretty much makes those states
useless, unless the compressor can make sure the compartment state
has not been changed since the remote end sent the message
offering the LASIs. IOW, if remote end has since received or sent
other messages which has modified the state items in compartment,
the LASI may be lost. This can be quite tricky, as the UDP packets
can be lost, duplicated or delivered out of order.

--Pekka