We are making calls using JsSIP. We are seeing "Sender's packet count" is very high in Wireshark. Can some one explain what is this Sender's count and why this count is so much big?
It means "total number of RTP data packets transmitted by the sender".
RTCP packets contain statistics about an RTP session.
RTP packets carry audio and video stream data. So, high number of RTP packets is normal in most situations.
Related
I want to simulate a simple client/server application streaming 2-3 4k 25 fps videos within 5G network using OMNeT++ stack. After capturing all incoming video flows with opencv and encoding with h264 codec I have roughly 20 kilobytes for each frame encoded as bytes -- uint8_t. Of course capturing for each of flow happens in a separate thread.
Now I want to send it to some clients over 5G using UDP protocol. If you look almost at every open source implementation of video streaming, the process of transmission is presented very simple:
uint_8* buffer; // encoded frame
int size; // buffer size
send(clientSocket, buffer, size, 0); // send to client
and on the client side a loop with an appropriate recv pulls. The same basically happens in every OMNeT++ simualtion.
Of course a UDP packet with around 20Kb payload will be fragmented on its way to pass good old IPv4 1500 bytes MTU at the backhaul part of a standard 5G architecture. So here comes my question: could I benefit something if I try to reduce my maximal UDP payload to, let's say, 1280 bytes to avoid IP fragmentation and to fit IPv6 minimum reassembly buffer size?
I'm afraid that if I just cluelessly send the encoded frame as in the code above, some fragmented packets may be lost and my decoder (h264 as well) on the client side can fail to decode the frame. Well however the same could happen if I send mine fragmented 1280 bytes packets... so here the question is pretty general, considering the fact that it happens in OMNeT++ simulation but with real video files: is there any advantage of controlling the packet size before sending or you just can cluelessly send any less than 64 Kb UDP datagram and just chill?
Im trying to figure out which is the maximum size of a RTP packet. I know that the minimum header size is 12 bytes, but i dont find anything about the payload.
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
I hope you understand my question :)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size?
The RTP standard does not set a maximum size so you're free to do this.
(Jumbo packets often have issues of their own with transport, but that's generally to do with the lower layer protocols playing up.)
It is possible that the maximum size of the RTP packet is the same as the UDP payload maximum size? I mean, that i have only a RTP packet with a huge payload. Is this possible and, in this case, there is any recommended size for the RTP packet for not doing this?
Yes, you could create a 1446 byte long payload and put it in a 12 byte RTP packet (1458 bytes) on a network with an MTU of 1500 bytes.
By the time you include an 8 byte UDP header + 20 byte IP header + 14 byte Ethernet header you've 42 bytes of overhead which takes you to 1500 bytes.
In practice if you're transporting this over the internet, this traffic is getting encapsulated or carried across varied transport layers, you'd probably want to keep it below 1400 bytes to be on the safe side.
For example im encapsulating MP3 frames in RTP. Do I make an RTP frame with 1 MP3 frame, 2, or how many?
RTP has a one-to-one mapping from one unique source to one RTP stream (Unless the streams are mixed/muxed together into one stream) so each of the MP3 sources would be put into their own RTP stream, each with it's own unique Synchronization Source Identifier (SSRC) to differentiate between each stream.
For more info on RTP there's the RFC 3550 itself, there's a great book by Colin Perkins called "RTP: Audio and Video for the Internet", I'vea fair bit on RTP on my blog and I've also created a Python library for creating RTP packets.
I have a simple application where I send OPUS packets from one client to other say A to B.
A reads one packet from a OPUS file, and send to B.
Again after 20ms or 30ms reads one more packet and send to B, so on..
Till now I was using RTP over UDP, so on receiving side at B, when I receive the packet, I receive complete packet. After receiving complete packet I write to a new file.
This works fine.
Now I am planning to support RTP over TCP.
A will read a complete packet from OPUS file and send to B.
When packet is received at B, it may be received as a single packet or multiple packet (tcp behaviour). My requirement is, I should buffer the data till I receive complete packet. Once I receive complete packet, I will write it to a file.
Now my question is, how do I determine the length of OPUS packet at B while I receiving, so that I can buffer it.
Do not want to use libopus etc if somehow I can avoid it. If by any means from received data, can I find out length of packet?
TCP is a stream protocol. You have two primary choices: add a length word (16 bits is enough) before each Opus packet (read length, then read packet, dealing with buffering (wait to get enough bytes for the read), or pad every Opus packet to a specific size. Opus doesn't use fixed-size packets; they depend on the content and the bitrate and quality settings.
I've been experimenting with isochronous USB transfers using WinUsb, and it turns out that WinUsb always sends data as fast as possible:
WinUsb_WriteIsochPipe packetizes the transfer buffer so that in each interval, the host can send the maximum bytes allowed per interval.
However for the kernel drivers you can apparently send shorter packets:
The MaximumPacketSize value indicates the maximum permitted size of the isochronous packet. The client driver can set the size of each isochronous packet to any value less than the MaximumPacketSize value.
I wondered how USB audio handles this. As far as I can see in the spec they just two alternative configurations for the interface - a zero bandwidth one, and a non-zero bandwidth one. There is a flag that says whether the endpoint requires full-size packets or not.
So my questions are:
a) What is the best way to handle sending less than full-speed data. Should I have a whole array of alternate configurations with different max packet sizes?
b) Should I expect to be able to send shorter-than-maximum packets? If so why doesn't WinUsb allow this?
Maybe you have to call WinUsb_WriteIsochPipe once for each packet you want to send. Make sure to use asynchronous I/O so you can queue up dozens or hundreds of requests ahead of time.
We use an embedded device to send packets from a serial port over a serial-to-Ethernet converter to a server. One manufacturer we use, Moxa, will always send the packets in the same manner which they are constructed. Meaning, if we construct a packet size of 255, it will always send the packet in a 255 length. The other manufacturer, Tibbo, if we send the packet size 255, it will break the packet up if it is greater than 128. This is the answer I received from the Tibbo engineers at the time:
"From what I understand and what the
engineers said, even if the other
devices provide you with the right
packet size now does not guarantee
that when implemented in other
networks the same will happen. This
is the reason why we feel that packet
size based data transfer through TCP
is not reliable as it was not the way
TCP was designed to be used."
I understand that this may not be how TCP was designed to be used, but if I create a packet of 255 bytes and TCP allows it, then how is this outside of how TCP works? I understand that at some point the packet may get broken up but if the server is expecting a certain packet size and Moxa's offering does not have the same problem as the Tibbo device.
So, is it possible to guarantee a reasonable TCP packet size?
No. TCP is not a packet protocol, it is a stream protocol. It guarantees that the bytes you send will all arrive, and in the right order, but nothing else. In particular, TCP does not give you any kind of message or packet boundaries. If you want such things, they need to be implemented at a higher level by your protocol.