Pcapplay

From SIPp

remington arms serial numbers norton corporate 9 torrent atom bomb movie australian music torrents mla movie works cited placebo pure morning home link ello levitra dosage microsoft office professional 2003 product key activation fly fishing adobe acrobat 7.0 standard crack char iron byron video pool contractors license iowa drug testing laws pharrell frontin video shemale route seimens sl65 ringtones lni.wa.gov tradeslicensing electrical tazi what is the formula for density thick ghetto girls reasons for immigration to the us pantie video clips university of pittsburgh medical center address creampiesurprise masai rites of passage accident free video

PCAP Play feature implementation details

Overview of PCAP replay: Files involved are prepare_pcap.{h,c} and send_packets.{c,h}. Prepare_pcap files deal with reading a pcap file, extracting RTP (with various checks over IP and IP upper protocol) and precomputing UDP checksum. Packets are stored within a big array and indexed. Send_packet files deal with effectively sending packets and cope with timing glitches.

Here is a timeslice in a scenario life:

- When scenario file is parsed and a play_pcap is found, it creates matching action. Pcap file is parsed in prepare_pcap.c. Packets are processed and checked whether they are IPV4 or V6 and UDP. Lowest destination port number is used as base for RTP flows. UDP Checksum is precomputed in terms of RTP checksumming. Missing parts depending on IP addresses and UDP ports are left for send time. IT IS IMPORTANT TO CHECK PCAP FILE ONLY CONTAINS RTP STREAMS AND NO DNS FOR EXAMPLE!. If pcap file contains audio and video, packets will be treated the same way (and as RTCP also). Each file replayed gets a matching packet storage. For precision on this structure, see pcap_pkts in prepare_pcap.h and RTP pkt is a pcap_pkt.

- A single port number is used when sending RTP. This port number is deduced from 200 response received when in UAC mode. It is taken from the "m=audio" pattern. See call.cpp for details. Note that is video port is always audio port +2 (meaning in both captured RTP streams AND 200 Ok SDP), there is no reason why sipp should fail in sending both RTP streams.

- When playing packets, EACH call is given a reference to corresponding pkts storage (file.pcap <-> pkts storage) and a target port (** which is different for each call is you want to simulate several UACs**). tcpreplay stuff is then used. UDP check is computed (parts involving IP and ports) and pkt is sent using a RAW socket (** and network interface is magically found by system based on IP in pkt**).

Howto record your self-made pcap file

1. Capture packets by ethereal (or tcpdump) during a call. (to call a "play music" IVR is good idea; The capture time is the audio replay time)
2. Filter captured packets, we need only one-way udp (rtp) packets. Save them as a new .pcap file by ethereal (or tcpdump).
3. Copy your .pcap into pcap directory which is placed in sipp root directory.
4. Play your self-made .pcap and don't forget to change the playing duration correspondingly in .xml.