I got a pcap file with voip conversation, how i can separate RTP packets from the other packets?
I can obtain sip packets, but I can't differenciate the RTP packets from the rest.
Search for RTP headers as defined in RFC3550 within your file. Or better use pcap-filter, for instance with this wiki (look for "Q: What is a good filter for just capturing SIP and RTP packets?").
If you want to see the RTP traffic in wireshark then:
Select Analyze->Display Filters...
Select "UDP", OK
Right click on any UDP packet and select "Decode as..."
Select "RTP" from the list, OK
Now you can see all RTP packets.
Hope that helps. :)
p.s. edited to note that this is for Wireshark. Thanks to a commentor for pointing that out!
Check #macs recommendation about PCap filter. If this cannot satisfy your needs (e.g. you need to filter out RTP packets of specific SIP session) there's no simple way. You need to parse SIP messages, retrieve RTP port numbers, takes packets going to/from these ports in particular time period and (optionally) check if these packets are RTP by checking their headers (magic number in headers)
An open source software that extract the RTP/RTCP packets from a pcap file are:
rtpbreak: http://dallachiesa.com/code/rtpbreak/doc/rtpbreak_en.html
xplico: http://www.xplico.org
From the source code you can view and understand the methodologies used.
I can obtain sip packets, but I can't differenciate the RTP packets
from the rest.
If you are able to decode the SIP, then you can find (inside INVITE message) the SDP message. If you decode it you can find the IP and PORT of RTP "stream" (and RTCP => port + 1). With these informations you can identify uniquely the RTP and RTCP packets. Keep in mind that there are often packages (with the same IP-PORT) with the STUN protocol which must be separate from RTP.
You have to consider where is the packet capture (network context and constraints), you may take into account NAT.
Related
I'm using the libpcap for capturing all packets on a specific port. But I need to separate and know clearly which packets my device is sending, and which ones it is receiving.
Actually I use pcap_close() for capturing packets, and it's working well ; but the struct pcap_pkthdr doesn't contain any information if the packet is received or sent.
I have a few options, but I think all of them are not quite good:
I could try getting my own IP and compare it with the IP inside the IP Header, but it's a big heavy to always check my IP and compare it...
I could do two pcap filter with in one src host and the other dest host. But that would make no sense to have two filter like this, and I wouldn't know how to capture with two separate filter.
So, am I wrong ? If not, is there an efficient way to separate received from sent packets ?
Thank you !
Source mac can tell if it is ingress or egress. If packet captured has source Mac of host, it is egress else it is ingress.
I want to filter sdp packets to be able to identify the possible sessions initiations for rtp streams. I'm using pcap library for c++ to read the packets and I would like to write a parser for sdp packets but I don't know which protocols can encapsulate sdp other than SIP and MGCP (I mean after UDP). Or If anybody can shed any light on how does wireshark filters/identifys SDP packets.
If we limit ourselves to the protocols over which SDP can directly run, then, if we look at the current master-branch version of Wireshark:
any protocol that uses a media type to describe its payload could, in principle, carry SDP, with a media type value of "application/sdp", although I don't know whether, in practice, you'll ever see, for example, SDP-over-HTTP rather than, say, SDP-over-SIP;
the BICC bearer control tunneling protocol, specified in ITU-T Recommendation Q.1990, can carry SDP, with the Tunneled Protocol Indicator having the value of 0x20 for SDP;
the Cisco Session Management protocol can carry SDP;
the ISUP (ISDN User Part) protocol can carry SDP;
the Gateway Control protocol (RFC 3525; an earlier version was called MEGACO) and MGCP (RFC 3435) can carry SDP;
the Session Announcement Protocol (RFC 2974) can carry SDP.
Which of those you will see in present-day network traffic is another matter.
As for the protocols on top of which those run, well, most of them run on top of TCP or possibly UDP, or on top of something that ultimately runs on top of TCP or possibly UDP, which means that they will then run on top of IPv4 or IPv6, which means that they will then run on top of any link layer that can transport IPv4 or IPv6, meaning Ethernet and 802.11 and PPP and....
However, ISUP, at least, can run on top of old-fashioned telephony networking stacks, such as the Signaling System No. 7 stack; whether it transports SDP when run on those stacks is another matter.
I'm trying to build RTP media projector for only audio streams.
A user will create a session with the server and possibly broadcast audio stream.
The server will send to the user audio streams of all the other active users.
Can the server send media from a single port or does it need to be able to use a range of ports for sending? (I know it needs to listen to ports 1024 - 65535).
Does the server need to use ICE or can it just respond to the SDP request right away?
How does RTCP works in this scenario? Does the server sends quality of service feedback in the name of clients or acts as a client and sends feedback for himself?
What does the server do with quality of service feedback from the clients?
Does the server need to do something with the media packets like changing timestamps or just deliver them as is, assuming all clients are using the G.711 codec?
Thanks
The MCU can use a single port if it is the passive side in the peer-to-peer connection or a separate port for each session if it is the active side.
The MCU can act as a Translator and just forward RTCP packets from clients but this might result with high bandwidth usage. A more complicated MCU can parse RTCP packets and generate RTCP reports from this info.
The MCU need to decrypt and re-encrypt the RTP packets but as long as all the participants are using the same codec, there is no need for transcoding.
The info can be found in the RTP rfc
http://www.ietf.org/rfc/rfc3550.txt
How do I write a C++/MFC program to make a server as a bridge for clients to stream their audio? I have been told to use UDP and RTP protocol but due to my lack knowledge of media streaming, I couldn't make it work. What is relationship between UDP and RTP and steps needed for server to listen, accept and handle packet transfer between client to client.
As unwind said, generally RTP runs on top of UDP. It's called a conectionless protocol.
This is the specification of UDP: http://www.ietf.org/rfc/rfc768.txt
An this is the specification of RTP: http://www.ietf.org/rfc/rfc1889.txt
You can find very useful information about RTP on this site. There are different libraries and docs.
It's possible to write a "RTP forwarder" application.
RTP generally runs on top of UDP, to get away from TCP's streaming behavior, TCP always delivers data in-order, which is not optimal for real-time applications.
It might be possible to do a "dumb" forwarder that is not RTP-aware, but instead is configured to e.g. accept UDP packets to port X, and forward all traffic to host:Y, packet by packet. Not sure if that works in practice, though.
I'm developing the application that sending MPEG video over IP network using RTP protocol.
In order to test it I'm looking for a software tool that can measure network jitter, recognize RTP packets reordering events and show results as a graph.
Any help is highly appreciated.
You can do a trace and then analyze it in Wireshark. Probably it won't recognize the RTP streams at first (it doesn't know the port number), but you can select one packet and choose 'Decode As.. RTP'. After that, go to 'Telephony / RTP / Stream Analysis' and you will get comprehensive RTP statistics.
The solution is to use Wireshark: Open Main menu->telephony->RTP->Stream analysis...
More information is here: http://wiki.wireshark.org/RTP_statistics
#Dima, if you are looking for a software tool capable of measuring network jitter, I suggest you check out http://www.netrounds.com. This is a cloud-controlled software solution for IPTV MPEG transport monitoring in line with ETR 101 290. You can measure both PCR and RTP jitter.
RTP jitter will show any network jitter problems in your transport path, whereas PCR jitter will also include any jitter introduced by encoding/transcoding.
There is a free version of Netrounds available that supports monitoring of two IPTV MPEG transport streams (channels) concurrently. Channels are received by the probe/agent by IGMP join messages sent to the corresponding multicast groups.
DISCLAIMER: I am affiliated with Netrounds.