I guess I'm going to be quite naive here, but it sounds like you have what I would call a "traffic cop" application. You open a pcap file and read a packet, then decide where it should go, direct that traffic there. Get next packet, etc.

I'm not quite understanding why there is a need to store any significant amount of data at all - I mean why it's not possible to just decide on-the-fly where the packet should go rather than having to save them for processing later?

Sounds like these SIP packets determine when a call starts and when a call ends and that you can assign some kind of callid to that unique call. Further that the "inbetween packets" can also be easily id'ed as belonging to a particular call.

I don't know how many calls are in one pcap file. But it could be that you can just have filehandles open to all of them - Depends upon OS filehandle limits. Open a new file when you see a new call starting.

You could use a hash to map call-ids to file handles. Something like this:

#!/usr/bin/perl -w
use strict;

my %filehandles;

foreach ('call1','call2')
{
   open my $fh, '>>', $_ or die "can't open $_ for append $!";
   $filehandles{$_}=$fh;
}

# use call_id in the print to select the right filehandle to
# write to

my $call_id = "call1";
print {$filehandles{$call_id}} "to file1\n";
$call_id = "call2";
print {$filehandles{$call_id}} "to file2\n";
[download]

Sounds like these SIP packets determine when a call starts and when a call ends and that you can assign some kind of callid to that unique call.

I've seen a lot of stupid protocols, but I would be surprised if SIP, Session Initiation Protocol , didn't provide this callid, since this seems to be the entire purpose behind SIP

thanks buddy. did try that out. didn't quite work.. think it's a net::pcap limitation. i'll save that in my bag of tricks though? :)