RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on thesame TCP connection

[zhigang.c.liu at nokia.com]

> [You can allow uncompressed messages in the first message only if you 
> don't need to differentiate between SIP and SigComp connections.]
> This is trivial to implement, but still an extension.  Again, 
> I'd like to hear arguments why you need to save those 13 bytes.)

(I've been keeping silence since the Carsten holds the editing
baton of sigcomp-sip-02. Thought somehow not good to make noise 
before it comes out. But this caught my eyes ...)

IMO, I don't think saving 13 bytes is worth the extension. But
does the extension allow a sender to send non-SigComp message
(i.e. plain SIP) and later "switch on" SigComp on the same TCP
connection? If yes, I think it's a good to have. 

The reason (which I've raised earlier) is that a sender 
may not know whether a receiver supports SigComp or not when
sending the first SIP message (e.g. request). So it has to send
the first message as is. Later (e.g. after receiving a response
to the request), it may discover the receiver actually supports 
SigComp. In that case, it would be good that the sender can
send the second and subsequent SIP messages using SigComp on
the same TCP connection already opened.

Of course, this is needed only if both of following are true:
1) SigComp support is not mandatory. (It is in 3GPP, but do we
expect it's always the case in general?)
2) The sender wants to reuse the same TCP connection. (Of
course, the sender may open a second TCP connection. But
there are benefits to reuse TCP connections.)

BR, Zhigang


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