Page 3 of 4

Re: H323 Simulation

Posted: Thu Jan 03, 2013 9:23 pm
by paulej
durani_01 wrote:How we will send and receive data with different data rates, using a single machine?
Just put in some kind of artificial delay when sending packets. For example, suppose you call this function to send a packet:

Code: Select all

    fixed_delay = 40;  // fixed delay in ms
    random_jitter = random(30); // some random jitter between 1 and 30 ms
    sleep(fixed_delay + random_jitter);

    // Now really send the packet
This is very crude, of course. It does not take into consideration the fact that the "fixed delay is rarely fixed and actually does change as network routes change or as traffic load increases. In any case, you get the idea. You can make this as sophisticated as you want.

Re: H323 Simulation

Posted: Thu Jan 03, 2013 9:44 pm
by durani_01
Thank you very much for your ideas.
I got it what you want to explain.

Now sir
Can we send data on different data rates eg. 16kbps, 32kbps etc using the same single machine for sending and receiving?
How? Explain with example if possible.


Re: H323 Simulation

Posted: Fri Jan 04, 2013 1:37 am
by paulej
durani_01 wrote:Can we send data on different data rates eg. 16kbps, 32kbps etc using the same single machine for sending and receiving?
How? Explain with example if possible.
This is basic programming work. It has nothing to do with encoding or even networking. You have data and you send it at a controlled rate. If you want to print characters on the screen at two per second, could you do that? It's the same kind of thing.

Re: H323 Simulation

Posted: Mon Jan 07, 2013 4:44 am
by durani_01
Dear Paul

thank you very much for your reply.

How we will create, send and receive a voice packet of 20ms of size 100 bytes.
If possible kindly explain with example.

Re: H323 Simulation

Posted: Mon Jan 07, 2013 3:27 pm
by paulej
If this is purely for simulation and you're writing code for Windows, then perhaps:
1) Create a thread that handles packet transmission
2) On that thread, have a loop that sends a packet containing 20ms packet (could just be random data)
3) Then have that thread sleep for 20ms

I really don't understand the line of questioning at this point. These are not telephony questions, but basic programming questions.

Re: H323 Simulation

Posted: Tue Feb 12, 2013 6:06 pm
by durani_01
Dear Paul
I want to keep a check on the network congestion, so that I can manage my data rate and jitter buffer size.
I want to keep check of 1% on the network congestion that if congestion increase or decresea 1%, increase or decrease jitter buffer size or data rate.
Is it afforadable or possible to implement. Means such a small check will make the system more complex. all the time will be wasted in switching.

Or should I increase the check size. e.g. 5% or 10% or 20%.

Please guide.

Re: H323 Simulation

Posted: Tue Feb 12, 2013 6:24 pm
by durani_01
for example at receiver side

this is the packet arrangement.
with the help of RTP receiver will store them in buffer sequentially.

But my question is that
Where the packets will be stored or wait before entering in buffer.

means packet [1] is received
after that packet [3] is received
after that packet [2] is received.
after that packet [5] is received.
after that packet [4] is received.
the buffer will look like
then [1] space [3]
then [1][2][3]
then [1][2][3]space [5]
then [1][2][3][4][5]
the buffer will left the space for the proper sequence number packet to come or something else.

please guide.

Re: H323 Simulation

Posted: Wed Feb 13, 2013 1:54 am
by paulej
Implementing the right jitter buffer management is not something I can simply prescribe. That said, I would not simply say "increase it by 10%", for example. If you are dealing with voice packets, what you want is to play the voice as quickly as possible without experiencing excessive buffer under-runs.

Let's assume you have 10ms G.711 "frames" sent one "frame" per packet. If you transmit the packet across the globe, the delay might be 100 or even 300ms. There is also delay in encoding and decoding. So, you do want to minimize any additional delay by having an excessively long jitter buffer.

When the PSTN was the only means by which voice communication occurred, the ITU recommended an end-to-end delay that did not exceed 100ms. I would still argue that is ideal, but packet-switched networks today often do introduce more delay. So, the new recommendation is to not exceed 400ms. However, most would agree that is high. Over a satellite link, though, it might be the norm.

So, when you get a packet, try to play it. If the next packet arrives too late, take note of that excess delay. Let's say the packet arrived 2ms too late. That would suggest there is a max average jitter of at least 2ms. Perhaps the second packet was delayed 10ms. Again, you can assume that the max average jitter is 10ms.

Keep in mind that the IP network is always changing. So, don't maintain jitter buffer calculations for extended periods of time. I would personally consider maintaining an average jitter measurements over the last 5 minutes. Specifically, I would maintain an average of how much in excess a packet is "late". For jitter buffer management, you're not so concerned about end-to-end delay, but you're concerned with how late a packet is relative to when it should have arrived based on the current clock.

Let's suppose you just started playing a packet:the time is 0ms. You are maintaining a buffer of 3 10ms frames. At 8ms into playing this packet, you receive a new packet. This packet is early by 2ms. That's good, but might suggest the jitter buffer is too large. Perhaps the packet arrives after 15ms. It's effectively 5ms late. That suggests the jitter buffer might be too small. So long as the packets are arriving within this window, though, having 3 10ms packets in the buffer is plenty. There would be no need to increase the jitter buffer.

Now, at what point do you increase the buffer? Perhaps if you see the excess delay exceeding the number of ms of audio in the jitter buffer. That is, if you have 30ms of audio in the buffer, but are seeing average excess delays of 50ms, perhaps you want more packets in the jitter buffer.

Now, is maintaining an average sophisticated enough? Or, do you need to maintain also look at the standard deviation? Don't forget to thow out statistical outliers, too. You don't want to compute in the average any packet that arrives significantly later than others. Plot what you see on a graph. Ideally, packets should arrive such that a histogram of those packets would look like a normal distribution. Over time, you might see shifts in the median and it's those shift in the median that would trigger a change in the jitter buffer size. There is a bit of math involved in this exercise, but I think this is your assignment :-) Your task is to figure how how to mimimize delay while also minimizing the number of discarded packets due to lateness. If you create the perfect minimization function given playout delay and discard rate, then you have the answer to your question.

Re: H323 Simulation

Posted: Mon Feb 25, 2013 8:35 am
by durani_01
paulej wrote:
durani01 wrote: Q 5. At the max kbps i.e. 23.85kbps, if I found the same problem that is delay is due to the high bit rate traffic and not the congestion, What would be my strategy?

5) Delay is OK. Too much delay is a problem. Another thing you might consider is increasing the frames per packet. There are pros and cons: larger packets means that if a packet is lost, it's more destructive to the audio flow. However, larger packets means routers have to buffer fewer packets. That can be a good thing. so, consider finding the optimal framing, reduce transmission rate in the face of packet loss, and increasing the jitter buffer in the face of buffer underrun. To make the media flow more tolerant of Internet conditions, consider also using some FEC mechanism.
Sir as we are using UDP for the voice communication in which no acknowledgement from the receiver to sender for the packet loss, then how the sender will know that packets are loss and now reduce the transmission rate. if we reduce the transmission rate in the face of packet loss. Kindly explain with example if possible.

Re: H323 Simulation

Posted: Mon Feb 25, 2013 5:54 pm
by paulej
That would be done via RTCP. If you're not using RTP, then I can appreciate that you are unable to get feedback. However, you would need something like RTCP is you are not using RTP. Given the wide deployment of RTP, I would suggest use of RTP exclusively. That, of course, also means use of RTCP.

The RTP/RTCP spec is in RFC 3550.