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
Related
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 need to do some validation testing of a new feed handler I have made. I have some pcap data that I captured from the production network and I would like to have my development feed handler connect to the "replay" of this data and compare the results.
My pcap:
I have a prod application that connects to a data feed, a TCP connection to an external server lets call assume this is 123.456.789.1:1234. This external sever then sends data to my application there is almost no client to server communication the server just sends the client data until the client drops. I have a pcap of all the packets sent to and from port 1234. I got this pcap by mirroring the production port (SPAN) on the switch and attaching tcpdump to an interface plugged in to the mirrored network port. When I look at the PCAP in wireshark it has all the data I would expect.
My problem:
I am in no way a network engineer and I am unsure how I can use this pcap to test my application. What I would like to do is "replay" this stream form the pcap and connect to it with my development application to validate that the data is being handled the same was it was on the prod connection.
I would like to some how "replay" the data sent from 123.456.789.1:12344 on 127.0.0.1:1234 and then connect to 127.0.0.1:1234 with my dev application. I looked at tcpreplay but from the documents I can not seem to figure out if it can do this, I get the feeling that they do not handle the tcp session data, and I could do this if it was a UDP stream, but tcpreplay can not act as the external server. Did I read this wrong or is there another tool that will let me do this?
thanks!
You may want to use netcat if you just want to throw some data back at your tool, and you don't care about what the tool sends.
You would do this by extracting the raw data sent by your tool from the pcap file (this tool may be helpful) and then piping that into netcat.
I've developed an app which sends RTP packets to a local ip client. So the client has to listen on the specified port (rtp://:#portnumber, on VLC) to play the streamed data. Right now i'm going to develop the code needed to create the SDP file needed to start streaming.
My doubt is, how to send this file to the client? At the beginning of the RTP stream?
Really n00b at this point. Any help will be useful.
Thanks
VLC specifically supports RTSP, HTTP, SAP protocols for establishing session and communication. And of course the local file system (file://)
so basically you can call vlc in some manner like this (I cannot test it but should be like this):
vlc file://path/to/sdp-file
or
vlc rtsp://server-path:port/sdpfile.sdp
and so on
Aside from storing the SDP file in the local system, perhaps HTTP would be easiest if you have up and running http server on your server machine.
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.
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.