Hi,
Following the e-mails, some days ago, on the H323 analysis feature, I've written what I think could be a useful version of it for other protocols. It is not really an analysis function, just a listing one, looking for VoIP calls, showing them and allowing them to be filtered. It currently works -hopefully- for SIP and ISUP. It does not plot the calls because, as I've said elsewhere, I think this might be better done as an external function, unrelated to the type of protocol being displayed.
The focus is slightly different than in the H323 case. It looks for sessions and shows them with calling and called number. Once a session is selected, the filter button will add an "OR" for the session to the current display filter. In that way, if two calls are related -what might be inferred throught the calling/called identities and/or the starting time- it is quite straigthforward to filter them together.
The structure is very much the same as in the H323 analysis, so it should be quite simple to merge them; I have not done it so as not to interfere with the work being done there and because of the focus on call ids and calling and called numbers.
There are some points that I'm still not sure how to solve, so maybe someone can help:
- the status of the call for SIP is quite complex to analyze. There are many issues involved -the fact that a call can have many dialogs, that the call state might be different for each call leg, that the initial speaker might not be present, etc-; and unfortunately it is linked to the possibility of reusing the call identifier -i.e. you can only be completely sure the call id will be different for different calls if you can now for sure when one call is over-. Right now it simply trusts the call identifier will not be reused -which I think is likely, at least for the likely span of a trace- and makes a halfhearted attempt to identify the call state
- for ISUP I am trusting the fact that the ISUP tap info seems to come deterministically before the MTP3 one, and so I can remember the ISUP specific information and then use it when I receive the MTP3 one. But I don't know for sure if that is always correct - I am still trying to understand completely the tapping mechanism-
- it is not clear for me whether, and how, the memory used by the taps should be freed; some of it is allocated per packet, so I think it should be freed by the module that uses it; however, that makes it impossible for other modules to use it afterwards, in case they are working simultaneously; right now I'm freeing the info I have added, so that should not happen
I hope I'm sending the patch in a correct way; if not please tell me. <<voip_calls.diff>> <<voip_calls.c>> <<voip_calls.h>> <<voip_calls_dlg.c>> <<voip_calls_dlg.h>>
Any comments/suggestions would be greatly appreciated.
Best regards,
Francisco
Attachment:
voip_calls.diff
Description: Binary data
Attachment:
voip_calls.c
Description: Binary data
Attachment:
voip_calls.h
Description: Binary data
Attachment:
voip_calls_dlg.c
Description: Binary data
Attachment:
voip_calls_dlg.h
Description: Binary data
