RE: [rohc] Preliminary minutes from San Francisco

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

Zhigang,

Thanks for those comments, these were all missing from the
notes I received, but I can personally confirm the first two
items. For the third one, I am not sure exactly what was
said on the meeting, so I do not know if the text below
really reflects how this meeting discussion ended. Anyway
I will add some words about your comment, and the fact that
there was a disagreement.

Cheers,
/L-E



> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: den 10 april 2003 19:07
> To: Lars-Erik Jonsson (EAB); rohc@ietf.org
> Subject: RE: [rohc] Preliminary minutes from San Francisco
> 
> 
> Hi,
> 
> According to my notes, the following are missing from the minutes.
> I would suggest to add them after the text quoted below from the 
> preliminary ROHC minutes.
> 
> ------------------------------------------------------------------
> >  - SigComp interoperability report (West)
> 
> > The main problem had to do with consumption of decompressor memory
> > because bytecode consumes memory in two places, making bootstrapping
> > very difficult.
> 
> Zhigang Liu pointed out that he had raised the "double 
> counting" issue 
> among SigComp authors sometime last year, so it is not a new issue. 
> 
> > We should then not
> > consider RFC 3486 as binding SIP to SigComp, but only defining how
> > an application finds out if SigComp is being used. This means that
> > we need a new document to specify other SIP specifics for SigComp.
> 
> Lars-Erik Jonsson then asked who were willing to handle this 
> SigComp-SIP 
> binding document. Zhigang Liu volunteered to be the editor.
> 
> > - The SigComp binary multiplexing issues (Price)
> 
> > The mixing problem raised was triggered by the requirement that SIP
> > messages may contain binary data. In UDP, framing comes from the
> > packet, but for TCP there are both application and SigComp
> > delimiters. Problems would then arise if uncompressed application
> > messages are multiplexed with SigComp messages. Carsten noted that
> > for TCP, the first byte would indicate whether SigComp is used or
> > not, and there seems to be something wrong with the layering here.
> > If there is a problem, it is probably because of misuse of SigComp.
> > Richard agreed, what should be made clear is that SigComp should
> > not be switched on/off within a connection. If someone wants to send
> > some messages uncompressed, that can be handled within SigComp.
> 
> Zhigang Liu pointed out that it seems to be easy to multiplex 
> uncompressed 
> application message and SigComp messages on one TCP connection, since
> each application message has its own framing. It's a matter spelling
> out the requirement and logic.
> 
> It looks not everyone has the same understanding of the 
> issue, and further
> discussion will continue on the mailing list.
> ------------------------------------------------------------------
> 
> BR,
> Zhigang
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc