[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages



Richard,

> Regarding point a), I don't see how this can be done without
> talking about specific protocols. 

I agree if you mean the exact logic (see below). But what I had in 
mind for a) is a generic or abstract logic as follows:

0. Endpoint B informs endpoint A that it supports SigComp AND
multiplexing of uncompressed message and SigComp message on
a TCP connection. This should be part of the SigComp discovery.

1. Endpoint B reads in one byte. 

2. If the first 5 MSB of the byte is 11111. this is the beginning
of a SigComp message or a SigComp message delimiter (0xFFFF). 
Endpoint B enters "SigComp parsing mode" and processes byte stream
according to SigComp until it encounters END-MESSAGE instruction 
or Sigcomp delimiter. When that happens, go to 1. 

3. Else, this is the beginning of an uncompressed message. Endpoint
B enters "uncompressed parsing mode" and parses the byte stream 
according to the delimiting scheme of the application messages. 
When reaching the end of application message, go to 1. 

Note: it is assumed that uncompressed application messages start
with UTF-8 encoded character. Otherwise, the logic does not work.

Note: the sigcomp can deliver the bytes to application layer either as 
they are arriving or at the end of the application message.

Note: this abstract demultiplexing logic can be either done at
SigComp layer (decompressor dispatcher) or at application layer.
That is a choice of local implementation.

Now, back to your comment. I certainly agree with you that detecting 
end of application message in Step 3 depends on a particular application 
protocol. But other than that, the rest is pretty generic. We can 
consider the above as the abstract logic that will be "instantiated" 
when binding SigComp to a particular application.

> Regarding point b), it might be good to have some recommendations
> on how to implement an efficient compressor for messages with
> binary content. 

Yes.

> A suitable home for these would be the SigComp
> User Guide, which already talks about the various different
> compressors that can be used in conjunction with SigComp.

OK. I don't mind where it ends up as long as the issue finds
a home. I can provide some text.

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc