R=1 (what I can decompress) sender <------------------------------ receiver R=2 (I will send using these params) sender -------------------------------------> receiver R=4 (I too will send ROHC using these params) sender <------------------------------------- receiver
Correct, that is what I'm proposing for the bidirectional case (e.g., two devices connected by some form of bridged Ethernet/WLAN combination). (The sender might then occasionally transmit R=4 packets based on a NUD-like algorithm.)
I'm not sure how ROHC will work properly with multicast.
That is the other case with R=6 at the end of section 6 (penultimate paragraph). If the sender does not have direct information about the ROHC capabilities from its peer (which it would get based on negotiation packets with R=1 and R=4), the R=6 case allows setting up the compression based on some out-of-band information (such as configuration or some other negotiation protocol). See the caveats in that paragraph.
Gruesse, Carsten