Hi all, I am working on a dissector for srtp which can decrypt and play audio.So once the dissector runs and processes a packet and then there is a rollover,next time i try to play audio my dissector thinks that the packets belonging to the first cycle are also the packets after rollover so it keeps the roc 1 which results in a failure.I really hope I made sense! So can someone help me in figuring out how to either stop the dissector from processing already proccesed packets again or get the correct roc for the current packet! Thanks a lot! -koundinya asked 26 Jun '15, 07:30  koundi |
One Answer:
The pinfo->fd->flags.visited flag allows you to know when a given packet is seen for the first time. So you can use this to do whatever you want / need to do on first pass, then save the result and retrieve it afterwards (for subsequent passes). That's what is done for request response tracking for example. You can find more info in doc/README.request_response_tracking file for example, or by checking the use of this flag in other dissectors. answered 26 Jun '15, 10:32  Pascal Quantin Thanks for the prompt response I will test it tomorrow and let you know how it goes,then i will accept your answer.Thanks so much! you guys rock:) (26 Jun '15, 11:14) koundi hi pascal, I did find the flag that you pointed me to,But It doesnot help me because 1.My packet is first read as rtp(as all srtp packets are just proccesed as rtp packets) and is processed before I pass the key to the rtp dissector. 2.so when I send it the key it has already been processed by rtp dissector and I cant differentiate between the 2nd and third time when it is being processed. 3.For storing the decrypted data I am using the data sources which I add when it is decrypted the first time.so that I can check if it is already proccesed by srtp then I just give the dissector the decrypted tvb when the rtp dissector is called. I am implementing the srtp decryption as part of the rtp dissector.Please suggest an alternative way for the dissector to remember that srtp has not been done even though rtp dissector has proccesed the packet once Thanks a lot! -koundi (29 Jun '15, 04:59) koundi |
Note that dissectors shouldn't play audio themselves; if you can plug into the same mechanism that the existing audio player code does, that would probably work better, and, if you can't plug into that mechanism, that's a deficiency in that mechanism, and you should file an enhancement request on the Wireshark Bugzilla.
yes I am taking care of that I pass it on to the rtp tap so that I can use the telephony->rtp->analyse option to see srtp streams as well adn play them.