Hi Didier, Thanks for explaining.
I understand why second stream will have 21 byte header. I am jyst trying to figure out where exactl the code breaks. Previously i was able to pinpoint where uint16_t access was happening. In this crash, I am not sure which instruction from which is doing the problem work. Regards, Harpreet On Mon, 2009-11-30 at 14:27 +0100, Didier Barvaux wrote: > Hi, > > > In the attached debug print dump. > > If we look at the last packet being decoded. > > for this packet the rohc compressor gives below given print finally. > > [../rohc/rohc_comp.c:373 rohc_compress()] ROHC size = 529 (feedback = > > 0, header = 21, payload = 508), output buffer size = 2048 > > > > which says that the header size is 21. > > > > and in decompressor, the decoded header size for this packet is 20.. > > as printed by > > [../rohc/rohc_decomp.c:848 rohc_ir_packet_crc_ok()] size of IR packet > > header : 20 > > > > and the point to be noted here is that this thing happens only if I > > start the system by sending uncompressed profile packets. > > and then, when I send the very first ip profile packet this error > > comes up. > > > > may be there is something to be initialized properly when this change > > profile change happens at the start of application. > > > > can you please give your views here ? > > This behaviour is normal. > > The IR header is 20-byte long + the CID if the CID is not 0. So, the > CID may be omitted (0 byte), small (1 byte) or large (2 byte). In your > tests, you use small CIDs, so the compressor sends 20-byte IR packets > for the first stream (CID 0 is omitted) and 21-byte IR packets for the > next streams (CID 1 is not omitted and is transmitted over 1 byte). > > When the decompressor receives a packet, it first determines if the > compressor uses small CIDs or large CIDs because the format of the > ROHC header is different for small and large CIDs. The decompressor > then checks the CRC. The function that computes the CRC (see > rohc_ir_packet_crc_ok) also prints the size of the header, but without > the length of the CID since it was already analysed. It thus reports > 20 - 0 = 20 bytes for the first stream and 21 - 1 = 20 bytes for the > next streams. > > You get a different behaviour if you first compress one ICMP stream > with the Uncompressed profile or not: > - When you first compress one ICMP stream with the Uncompressed > profile, the compressor reserves the CID 0 for that stream. The next > IP stream got the CID 1 that can not be omitted from the ROHC > header. > - If you do not compress one ICMP stream with the Uncompressed profile > before compressing your IP stream, the IP stream got the CID 0 that > can be omitted from the ROHC header. > > I'm not sure I'm clear enough, ask me for more explanations if needed. > > Regards, > > Didier Barvaux > Viveris Technologies > > _______________________________________________ > Mailing list: https://launchpad.net/~rohc > Post to : [email protected] > Unsubscribe : https://launchpad.net/~rohc > More help : https://help.launchpad.net/ListHelp -- Software Engineer 1Spatial Australia +61 3 52616840 _______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
