First of all thanks Didier for the response, we need your inputs for fixing this issue for our end-user customer who needs this ROHC enabled with support of the features.
To give you a background on the architecture, we are building a LTE network solution for the terrestrial Infrastructure for one leading SATCOM manufacturers and solution providers.
They are looking for using Open source solution to help support the Robust Header Compression, Decompression for the following streams: UDP IP, TCP IP and RTP UDP IP.
We have integrated your libraries to enable the ROHC in Uplink data flow and Downlink flow and that should ideally work seamless by virtue of the Specification. There should ideally be no call drops or drop in the bandwidth of the data or voice services if ROHC is enabled. Hope you now understand the architecture and capability needed.
Here are my answers marked with Inline [Poonam Ghosh]
The IPv4, UDP and RTP look good. The RTP payload looks good too, except for the 4 first bytes that all zeroes. Is it correct?
[Poonam Ghosh] No that's incorrect, we are expected to see the same payload in the dump (post decompress) as sent in the Original Data Packet.
If yes, that is quite strange since payload is seldom impacted by bugs. The best way to find the root of your problem is to reproduce it on my setup.
[Poonam Ghosh] Yes the issue 100% reproducible if you use the same configuration and the profile we have used with the Data Dump.
Is it the first packet of flow? If no, is it possible to get a PCAP file with the first packets?
[Poonam Ghosh] IT is the first and only packet what we are testing with the Profile: ROHCv2_PROFILE_IP_UDP_RTP
Do you use the default parameters of the library? If not, please give me the changed parameters.
[Poonam Ghosh] I have attached the Original (INPUT) packet dump used for calling the compress function.
What is the architecture of your setup?
[Poonam Ghosh] Shared with you on top. Let me know if you need any additional inputs.
First of all thanks Didier for the response, we need your inputs for fixing this issue for our end-user customer who needs this ROHC enabled with support of the features.
To give you a background on the architecture, we are building a LTE network solution for the terrestrial Infrastructure for one leading SATCOM manufacturers and solution providers.
They are looking for using Open source solution to help support the Robust Header Compression, Decompression for the following streams: UDP IP, TCP IP and RTP UDP IP.
We have integrated your libraries to enable the ROHC in Uplink data flow and Downlink flow and that should ideally work seamless by virtue of the Specification. There should ideally be no call drops or drop in the bandwidth of the data or voice services if ROHC is enabled. Hope you now understand the architecture and capability needed.
Here are my answers marked with Inline [Poonam Ghosh]
The IPv4, UDP and RTP look good. The RTP payload looks good too, except for the 4 first bytes that all zeroes. Is it correct?
[Poonam Ghosh] No that's incorrect, we are expected to see the same payload in the dump (post decompress) as sent in the Original Data Packet.
If yes, that is quite strange since payload is seldom impacted by bugs. The best way to find the root of your problem is to reproduce it on my setup.
Is the bug 100% reproducible in your setup?
[Poonam Ghosh] Yes the issue 100% reproducible if you use the same configuration and the profile we have used with the Data Dump.
Is it the first packet of flow? If no, is it possible to get a PCAP file with the first packets? PROFILE_ IP_UDP_ RTP
[Poonam Ghosh] IT is the first and only packet what we are testing with the Profile: ROHCv2_
Do you use the default parameters of the library? If not, please give me the changed parameters.
[Poonam Ghosh] I have attached the Original (INPUT) packet dump used for calling the compress function.
What is the architecture of your setup?
[Poonam Ghosh] Shared with you on top. Let me know if you need any additional inputs.
Thanks & Regards
Poonam Ghosh