Doubts in ROHC Feedbak in RTP Profile

"Gangadharan G, TLS-Chennai" <[email protected]>
Newsgroups gmane.ietf.rohc
Message-ID <66E8AEE9980BB44CA5FCAD39EBA56AC60391D534@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
Hi All,

 

I have listed down my doubts in the ROHC Feedback mechanism in RTP
Profile.

Please help me to clarify it.

 

1) The Sliding Window structure for the List Compression is different
for R-Mode and U/O-Mode.

    The RTP CSRC and IP-extension header uses List compression.      

    So, those fields have to be reinitialized when there is a Mode
Transition (transit from U to R Mode).

    I.e., when the C_TRANS is PENDING, the compressor has to send
IR/IR-Dyn/UOR-2 packets 

           with all dynamic fields (at least the field that needs to be
reinitialized)

    __but__ RFC 3095 doesn't mandate the compressor to update the
dynamic fields while mode transition. 

    

    Whether we need to send IR/IR-Dyn/UOR-2 packets with all dynamic
fields or not?

    Also whether the compressor does downward state transition while
Mode transition?

 

2) In R-Mode Feedback, 

    Section 5.5.2.1.  Decompression logic (R-mode) specify that

The decompressor SHOULD act according to section 5.3.2.2.3 when CRCs

            fail, except that no local repair is performed.

    I.e.., send Nack (k_1 out of n_1) when CRC fails

 

    Section 5.5.2.2.  Feedback logic (R-mode) specify that 

            When context damage is detected, send a NACK(R) if in Full
Context

            state, or a STATIC-NACK(R) if in Static Context state

 

    Does the above statement specify to send NACK for each failure? 

    If so, then it contradicts with the statement in the section
5.5.2.1(mentioned earlier).

 

3) In R-Mode Feedback logic, 

    Does the Decompressor have to send the NACK for the rejected packet
in SC State?

    But RFC 3095 mentioned about sending NACK for rejected packet in
O-Mode (Section 5.4.2.2) and for R-Mode.

 

4) When the D_Trans is Initiated or Pending, the Decompressor send
Ack/Nack for each received packet.

    Whether the Decompressor does upward/downward state transition after
sending the Ack/Nack?

    Or, the Decompressor has to follow the corresponding Mode Feedback
logic for State transition, 

    even though it send Ack/Nack for each packet.

 

5) When the D_Trans is Initiated or Pending, Whether the Decompressor
has to send Static-Nack or Nack in SC state?

 

6) RFC 3095 mentioned about what the Compressor and Decompressor has to
do when there is a Mode transition.

   But it does not specify when the Decompressor has to initiate the
Mode Transition. Is it implementation specific or Link-Layer dependent?

   The upward mode transition is required for better compression.

   Is there any real time need for the downward mode transition?

 

Please forgive me if I am ignorant on anything.

 

Thanks,

Gangadharan

 



DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
Rohc mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/rohc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.