I have simple Rtsp Source Filter which connects Rtsp Server and get Rtp packets. The problem is that i have to set media subtype in my Rtsp Source Filter Pin...[ Now i give substype hard-coded]
pMediaType->SetSubtype(&MyHardCodedSubTypeGUID);
What i want is create my pin dynamically with subtype according to coming stream. I get h264 and mpeg-4 streams from server.Their rtp packet payload format is dynamic: 96...Does not help me to identify if stream is mpeg4 or h264...
FFmpeg can able to get stream type[h264,mpeg4] from codec info...But how can i do myself?
Best Wishes
RTP payload is not only dynamic (96, 97 etc), it is also provided with payload type attributes you need to obtain format from and convert into DirectShow media type (see "H264*" below):
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=1
a=fmtp:96 packetization-mode=1
Related
I'm developing software feature for a Session Boarder Controller(SBC).
I'm trying to establish a SIP call using two SIP clients and a Session Boarder Controller(SBC). Asterisk is used as the soft-switch.
When I call, the SIP signalling is working fine. But I am getting audio only in one direction. I captured rtp packets on all interfaces using wireshark. I observed that rtp packets in one direction is being dropped by asterisk.
Note: There is no send only attribute in any of the SIP/SDP messages.
I would like to know if there is any settings in asterisk that may cause this issue?
One more thing that I would like to know is that, from where a SIP client gets the RTP connection information. The port information is present in the media attribute
m=audio 16388 RTP/AVP 8 0 101
From where does the client get the transport IP address? is it from the "o=" field or "c=" field in the SDP or any other fields in the SDP or SIP?
You should troubleshoot the problem by capturing the complete call with Wireshark. Then look carefully at:
Client A initial INVITE: which port is it expecting media on (m= line) which address is it expecting media on (c= line)
SBC for Client A initial INVITE: If the SBC is anchoring the media (I assume so) check m / c lines
SBC for Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client A expecting media on
Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client B expecting media on
Are all nodes in this direction sending media on to the correct ports / ips (look at the RTP streams in wireshark)?
Then check the other direction (based on the SDP in the 183 or 200 (depending on your signaling flow)).
Note: In wireshark there is a nice feature which helps alot: Telephony --> VoIP Calls, which shows you the call flow more graphically
I am trying to write a utility to extract the payload from RTP packet. From my understanding about the network packets and protocols, RTP is wrapped in UDP. How can we decide whether the UDP packet that we have captured has RTP packet wrapped in it? I mean it can also be NBNS or MDNS right? I am using Winpcap library and am new to it. I have been given a task to extract the RTP packets from any given pcap dump file.
Have a look at the RTP packet format at Wikipedia. By studying it you will find a few magic bytes which help you to detect potential RTP packets. Also, RTP packets don't travel alone and you can find related packets by source/dst IP+port and by sequence numbers:
At first find UDP streams, that is same source/destination IP+Port.
Then check if these streams look like RTP, that is the packets have the magic bytes and the sequence numbers suggest that these packets are a single RTP stream (there might be some duplicates or missing packets, but not too much).
I am working on analyzing H264 video data being streamed over a network. Right now, I am able to successfully extract and analyze the raw H264 for UDP. This process is going to be ALOT harder for the TCP/RTSP because of fragmentation and multiplexing.
Is the video compression / encoding any different on the TCP/RTSP multiplexed stream compared to the UDP stream?
It's only slightly harder as you typically have to demultiplex the audio and video, as well as the RTCP reports on the TCP connection. Fragmentation is not an issue.
Is the video compression / encoding any different on the TCP/RTSP multiplexed stream compared to the UDP stream?
No differences at all. The multiplexing of RTP/RTCP packets is defined in RFC2326.
As far as tools go, you can use openRTSP from http://www.live555.com which handles the transport for you (RTP over RTSP via the -t command line argument) and writes the frames to file.
With reference to Ainitak's comment, it's not that complex: there's a 4 byte header, '$' followed by the channel id, followed by the 2 byte length of the following RTP/RTCP packet. It's not too tricky to parse this.
How do TCP knows which is the last packet of a large file (that was segmented by tcp) in the scenario that the connection is kept-established. (like ftp or sending mp3 on yahoo messenger)
I mean how does it know which packet carries data of one.mp3 and which packet carries data of another.mp3 ??
Anyone ?
Thank you
There are at least 2 possible approaches.
Declare upfront how much data you're going to send. Something like a packet that declares Sending a message that's 4008 bytes long
The second approach is to use a terminating sequence (nastier to process)
So the receiver:
Tries to read the declared amount or
Scans for the terminating sequence
TCP is a stream protocol and fragmentation should be transparent to a TCP application. It operates on streams of data, never packets. A stream is assembled to its intended order using the sequence numbers. The sequence of bytes send by application is encapsulated in tcp segments. The stream is recreated on the receiver side before data is delivered to the application.
The IP protocol can do fragmentation.
Each TCP segment goes to the IP layer and may be fragmented there. Segment is reassembled by collecting all of the packets and offset field from the header is used to put it in the right place.
im now developing a project using winpcap..as i have known packets being sniffed are usually fragmented packets.
how to reassemble this TCP segements?..any ideas, suggestion or tutorials available?..
this i assume to be the only way i can view the HTTP header...
thanks!..
tcp is a byte stream protocol.
the sequence of bytes sent by your http application is encapsulated in tcp data segments and the byte stream is recreated before the data is delivered to the application on the other side.
since you are accessing the tcp datasegments using winpcap, you need to go to the data portion of the segment. the header of tcp has a fixed length of 20 bytes + an optional part which you need to determine using the winpcap api.
the length of data part in the tcp segment is determined by subtracting the tcp header length (obtained from a field in the tcp segment) and the ip header length (from a field in the ip datagram that encapsulates the tcp segment) from the total length (obtained from another field in the ip datagram).
so now you have the total segment length and the length of the data part within the segment. so you know offset where the http request data starts.
the offset is
total length-length of data part
or
length of ip-header + length of tcp header
i have not used winpcap. so you will have to find out how to get these fields using the api.
also ip datagrams may be further fragmented but i am expecting that you are provided only reassembled datagrams using this api. you are good to go!
There is no such thing as a TCP fragment. The IP protocol has fragments. TCP is a stream protocol. You can assemble the stream to its intended order by following the sequence numbers of both sides. Every TCP Packet goes to the IP level and can be fragmented there. You can assemble each packet by collecting all of the fragments and following the fragment offset from the header.
All of the information you need is in the headers. The wikipedia articles are quite useful in explaining what each field is
http://en.wikipedia.org/wiki/TCP_header#Packet_structure
http://en.wikipedia.org/wiki/IPv4#Header
PcapPlusPlus offers this capability out-of-the-box for all major OS's (including Windows). Please check out the TcpReassembly example to see a working code and the API documentation to understand how to use the TCP reassembly feature
Depending on the whose traffic you're attempting to passively reassemble, you may run into some TCP obfuscation techniques designed to confuse people trying to do exactly what you're trying to do. Check out this paper on different operating system reassembly behaviors.
libtins provides classes to perform TCP stream reassembly in a very high level way, so you don't have to worry about TCP internals to do so.