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

["Price, Richard" <richard.price@roke.co.uk>]

> > 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. 
> 
> 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.

Hi Zhigang,

Both of Step 1 and Step 2 are already documented in the SigComp RFC.
If Step 3 never arises then Endpoint B can decompress the entire
stream without any problem, using the delimiting scheme from RFC 3320.

Step 0 and Step 3 are not defined in RFC 3320, but this is ok because
both steps are 100% application-specific. If the endpoint ever reaches
Step 3 then there are at least four ways that it could proceed:

i)   Always fail (i.e. no multiplexing allowed at all).

ii)  Fail unless it's the very first byte of the stream. This is just
     enough to allow application and SigComp streams to be multiplexed
     on the same port, but not enough to multiplex messages on the same
     stream.

iii) Use SigComp-style delimiters for everything (i.e. for both the
     application and the SigComp messages).

iv)  Let the application decide where the message ends and when to
     hand the parsing back to SigComp.

It's up to particular applications to decide which strategy is the
most appropriate - currently I haven't seen a convincing reason why
we need anything more complex than ii) for the case of SIP.

Regards,

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