H323 Simulation

Discussion related to the ITU-T Recommendation H.323
durani01
Posts: 7
Joined: Sun Sep 09, 2012 7:37 pm

H323 Simulation

Post by durani01 »

Hi every one

My name is Jawad Durrani. I am doing my MS in communication engineering. I want to simulate H323 in C-Sharp. Please guide me that is it possible in C-sharp.
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: H323 Simulation

Post by paulej »

It's certainly possible, but it will be considerable work starting from scratch. The best place to start is with understanding the protocol itself. If you've not seen the overview presentations of H.323, I would suggest you start with those: http://www.packetizer.com/ipmc/h323/papers/

Look at the Overview slides and then the "H.323 Protocol Overview (technical)" slides.

We can then go further in understanding the protocol details. You might also want to look at the h323plus.org site to look at the C++ source code.

Now, that brings us to the more difficult challenge: much of H.323 is encoded in binary using ASN.1 PER encoding. Doing ASN.1 PER is a challenge all unto itself. This is perhaps the #1 reason why folks view H.323 as a "complex" protocol. H.323 actually isn't that complicated, but that's not the view of those who want to do H.323 and don't have an ASN.1 PER encoder in hand. If you love fiddling with bits, you'll love ASN.1 PER. A good compiler is wonderful and many do not appreciate how wonderful ASN.1 is when it comes to developing protocols. Without an ASN.1 encoder, you could spend a semester just learning how to do ASN.1.

I would strongly suggest you contact OSS and see if you can get an educational / research license to use their C# ASN.1 compiler: http://www.oss.com/asn1/products/asn1-c ... sharp.html

Objective Systems also has a means of generating C# code:
http://www.obj-sys.com/asn1-compiler.shtml#JavaCompiler

Try both and see which works best for you.

Paul
durani01
Posts: 7
Joined: Sun Sep 09, 2012 7:37 pm

Re: H323 Simulation

Post by durani01 »

Dear Paul

Thank you very much for your guidance and reply.
My research topic is "Simulate an adaptive jitter buffer and study the behavior of AMR-WB in VoIP envoirnment"

One of my friend has good programming skills in C# that's why I asked about it.

I am totally confused from where I should start. If you guide me in this regard, it would be worth for me. I will oblige.

I hope you can understand.

Waiting for your positive reply.
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: H323 Simulation

Post by paulej »

From that description, I don't think you'll need to implement any call signaling at all. The only thing you'll need to do is implement a media transmission mechanism. You could use RTP (which would be reasonable, since that is what all VoIP systems use). That is documented in RFC 3550 and RFC 3551. There are other RFCs that document different payload formats. The payload format for AMR-WB is documented in RFC 4867.

Your focus will be on the jitter buffer. The jitter buffer is the area where you hold packets for a period of time wihle you wait for the right time to play them to the user on the receiving side. This accommodates late-arriving packets and allows for smooth audio play without apparent disruption.

Consider an application with no jitter buffer... packets would be sent by user A to user B. User B would play the audio as soon as it arrives. However, if there is congestion in the network the audio will cut out for a moment while endpoint B waits for a new audio packet. Thus, you have a buffer underrun problem. When that packet does arrive, it would probably be too late to play it given the assumption one is running on a fixed clock.

Using a jitter buffer, you can help to smooth the audio. A sends audio to B and B inserts a certain amount of delay (e.g., 20ms or 40ms) before playing that audio. So while these initial packets arrive at B, they are merely inserted into a jitter buffer. After the defined delay period, B starts playing the buffered packets in sequential order to reproduce the original audio. Suppose a new packet experiences 15ms more delay than the previous packet. It does not matter: the packet is put into the queue and will be played when it's time. If packets arrive out of order, no big deal: they are ordered as they are inserted into the jitter buffer. (RTP defines a sequence number to aid with this.)

There are times when a packet arrives substantially later than expected. Suppose you assume that a "safe" jitter buffer size is 40ms, but you find out that the network has a 100ms end-to-end delay. That might present problems where you have underrun constantly. In that case, you will need to grow the jitter buffer to allow for more packets before playout. Again, the objective is to not run out of audio packets to play.

That said, if there happens to be a single network event that causes one or a few packets to be significantly delayed, you may not want to increase the size of the jitter buffer (and, thus, end-to-end delay). It would be unfortunate to keep 100ms of packets in the buffer all of the time when you could get by with having only 20ms of audio queued.

So, there's your assignment. What is the best approach to growing and shrinking this buffer such that you do not experience a buffer underrun or introduce unnecessary delay such that it becomes noticeable to the user?
durani01
Posts: 7
Joined: Sun Sep 09, 2012 7:37 pm

Re: H323 Simulation

Post by durani01 »

Dear Paul

I am very glad from your such a detailed replies. I am satisfied internally that now Inshallah I will complete this research. And also I am very hopeful that you will guide me from start till end in this journey.
Sir I have read your reply with concentration. I am writing my understandings and questions.

"Consider an application with no jitter buffer... packets would be sent by user A to user B. User B would play the audio as soon as it arrives. However, if there is congestion in the network the audio will cut out for a moment while endpoint B waits for a new audio packet. Thus, you have a buffer underrun problem. When that packet does arrive, it would probably be too late to play it given the assumption one is running on a fixed clock."

Means after fixed clock duration, received audio packets will be drop.

"Suppose a new packet experiences 15ms more delay than the previous packet. It does not matter: the packet is put into the queue and will be played when it's time"
Means last packet received after e.g. with 20ms delay and very next packet received after 35ms delay.Why it does not matter?

"If packets arrive out of order, no big deal: they are ordered as they are inserted into the jitter buffer. (RTP defines a sequence number to aid with this.)"
Means before entering in to the jitter buffer the RTP will sequence all the packets.

"Suppose you assume that a "safe" jitter buffer size is 40ms"
Means 20ms duration 2 packets can be accommodated in 40ms buffer (OR) The packet which is 40ms delay can be accommodate in buffer.

"the objective is to not run out of audio packets to play."
Means too much late packets cannot be play.

Questions:
Q 1. If the late packets are not going to be played how we will accommodate empty space?
Q 2. How the B will know after how much time the first packet or later will be played?
Q 3. My assignment: To find the best approach for growing and shrinking this buffer such that you do not experience a buffer underrun. Means use different buffer algorithms e.g. Exponential Average, Fast exponential average, Minimum delay, Spike detection, Window, Gap Based. and compare the result?
Should I limit myself the above mentioned algorithms or what?


Please find the attached proposal. This is the one which I wrote before our conversations. Kindly review it for necessary correction if possible.

Waiting for your swift and positive reply.

Regards
Attachments
4th Final Jawad Durrani Proposal.docx
Research Proposal
(89.05 KiB) Downloaded 721 times
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: H323 Simulation

Post by paulej »

durani01 wrote:"Consider an application with no jitter buffer... packets would be sent by user A to user B. User B would play the audio as soon as it arrives. However, if there is congestion in the network the audio will cut out for a moment while endpoint B waits for a new audio packet. Thus, you have a buffer underrun problem. When that packet does arrive, it would probably be too late to play it given the assumption one is running on a fixed clock."

Means after fixed clock duration, received audio packets will be drop.
When playing audio, there is a clock. The clock is always running and the media layer in a VoIP system must ensure that there is audio playing at all times. If the media layer plays audio packets immediately upon receipt and without introducing some delay to accommodate network jitter, then audio will drop out. Anytime you don't have audio to play, that's a problem.
durani01 wrote:"Suppose a new packet experiences 15ms more delay than the previous packet. It does not matter: the packet is put into the queue and will be played when it's time"

Means last packet received after e.g. with 20ms delay and very next packet received after 35ms delay.Why it does not matter?
What I meant was that it does not matter if a packet is late if you have a good jitter buffer, because it will be placed in the buffer and played at the right time. With AMR-WB, I think, all packets represent 20ms of audio. (If that's not true, feel free to correct me.)

So, let's assume you have this buffer:

[0][1][2]

Each position in the buffer represents 20ms of audio, so we have 60ms of audio buffered. We then start playing the audio in [0]. Is that is playing a new packet arrives, so the buffer contains:

[1][2][3][4]

We pulled [0] out since it's being played. Immediately when done, we start playing [1]. So, the buffer looks like this:

[2][3][4]

Now, suppose there is network congestion and things are backed up for 30 ms. We finish playing [1] and start playing [2]. So, the buffer has this:

[3][4]

We no longer have 60ms of audio buffered, only 40ms buffered.

If there is severe congestion, perhaps there might be even more delay and we start playing [3]. The buffer might have a single frame inside:

[4]

At some point, the late-arriving packets that should have been sent will arrive and be placed into the buffer:

[4][5][6]

So, what I meant was that it does not matter if packets are a little late. They will be inserted into the buffer once they arrive. Now, we're back to a 60ms buffer.

If a packet is lost entirely *or* if the packet arrives so late that it should have been played already, those packets must be discarded and the audio needs to be smoothed from one 20ms frame to another. This technique is called "packet loss concealment" (PLC). That's a whole other topic, though. Still, you might want to explore concealment techniques for AMR-WB.
durani01 wrote:"If packets arrive out of order, no big deal: they are ordered as they are inserted into the jitter buffer. (RTP defines a sequence number to aid with this.)"

Means before entering in to the jitter buffer the RTP will sequence all the packets.
Correct. As with the example above where [5] and [6] arrived late, they could have arrived in the order [6] [5]. These need to be re-ordered before inserting them into the jitter buffer.
durani01 wrote:"Suppose you assume that a "safe" jitter buffer size is 40ms"
Means 20ms duration 2 packets can be accommodated in 40ms buffer (OR) The packet which is 40ms delay can be accommodate in buffer.
This is the number of 20ms frames you feel you need to buffer in order to ensure that you do not run out of packets to play.
durani01 wrote:"the objective is to not run out of audio packets to play."
Means too much late packets cannot be play.
Right. If the packets come too late and you did not introduce local delay via the jitter buffer, then late-arriving packets cannot be played and will just be discarded. It's better to introduce a little delay than to throw away good audio.
durani01 wrote:Questions:
Q 1. If the late packets are not going to be played how we will accommodate empty space?
Try to maintain a buffer long enough to handle late packets. However, if a packet is significantly delayed such that it is too late to play the packet, then you have to discard it. If this is a statistical anomaly, you don't worry about it. If this happens frequently, it suggests that you need to increase your buffer size.

If you end up where you have no audio to play, you need to employ some kind of PLC algorithm. Or, you have silence for a period of less than 20ms.
durani01 wrote:Q 2. How the B will know after how much time the first packet or later will be played?
Every packet will be played sequentially, with each being 20ms from the next. So, B knows when a packet should be played. B should create a buffer that can buffer enough audio.
durani01 wrote:Q 3. My assignment: To find the best approach for growing and shrinking this buffer such that you do not experience a buffer underrun. Means use different buffer algorithms e.g. Exponential Average, Fast exponential average, Minimum delay, Spike detection, Window, Gap Based. and compare the result?
Should I limit myself the above mentioned algorithms or what?
The approach you take is your own. Using AMR-WB, you also have the opportunity to reduce the bit-rate from 23.85Kbps down to 6.6Kbps, I think. So, an element of your work should probably be to consider not only resizing the jitter buffer, but reducing the transmission rate. Would it be better to get a 6.6Kbps flow with 40ms of delay and no packet loss or a 23.85Kbps flow with 120ms of delay and 3% packet loss?

These are the kinds of things you have to consider. I would personally try to take a relatively simply approach that would look at the inter-packet delay. Perhaps measure the delay between each packet, maintaining a history of the last 10 packets or so. On a perfect, non-existent network (where there is 0 delay) , the delay between each packet should be a constant 20ms. If you see 21ms or even 25 ms, that's no big deal. If you see 60ms, that suggests you need a longer jitter buffer. If the delay varies considerably, like 30ms, 60ms, 90ms, 45ms, etc., that really suggests you need a sizable jitter buffer. However, if you happen to see just one single packet with a much larger delay (e.g., 400ms), I would consider that a statistical outlier and would not adjust the buffer for that.

In any case, the mechanism is for you to come up with. I can only provide you some thoughts, but I cannot provide the best solution :-)
durani01 wrote:Please find the attached proposal. This is the one which I wrote before our conversations. Kindly review it for necessary correction if possible.

Waiting for your swift and positive reply.

Regards
I really don't have time to read through that in detail. Perhaps others might provide you with feedback.

Paul
durani01
Posts: 7
Joined: Sun Sep 09, 2012 7:37 pm

Re: H323 Simulation

Post by durani01 »

Sir
Thank you so much for your continuous support and time which you are giving to me. I have much clear idea now and will also amend the proposal accordingly.
"The approach you take is your own. Using AMR-WB, you also have the opportunity to reduce the bit-rate from 23.85Kbps down to 6.6Kbps, I think. So, an element of your work should probably be to consider not only resizing the jitter buffer, but reducing the transmission rate. Would it be better to get a 6.6Kbps flow with 40ms of delay and no packet loss or a 23.85Kbps flow with 120ms of delay and 3% packet loss?"
My work is "To consider not only resizing the jitter buffer, but reducing the transmission rate."

Sir kindly guide me from where should I start.

What will be the first step for starting?
What programming language or tool you recommend for this?

Waiting for your positive reply.
Regards
Jawad Durrani
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: H323 Simulation

Post by paulej »

The logic you follow for increasing or decreasing the bit-rate is part of the assignment, not something I can prescribe.

That said,I can discuss things to consider.

I assume that you would normally want to operate at the highest bit-rate. However, that might not be true. Somehow, you must determine what your initial bit-rate should be. This might be a value determined by an enterprise or service provider in practice.

You also need to know what the acceptable min and max bit-rates should be. Again, this is a provisioned value. Perhaps the service provider never wants customers to use more than X Kbps. In that case, your algorithm must keep this max bit-rate in mind.

Once you have selected an operating bit-rate, when do you decide to reduce the bit-rate versus increasing the jitter buffer? If packets are not lost, but merely delayed, you might want to increase the jitter buffer. However, the reason for the increased delay might be due to a lot of media flows operating at a high bit-rate. So, if all devices reduced the bit-rate be 20%, for example, perhaps there would be no need to lengthen the jitter buffer.

Whatever the case, you don't want to have a 400ms jitter buffer if you can avoid it. (Note that communications over a satellite link might require a 400ms buffer, though.) If you believe your jitter buffer is getting too large, you definitely need to reduce the bit-rate. Reducing the bit-rate may not help, though, if the reason for the long delays is not due to congestion or in cases where other traffic does not also slow. In the latter case, your VoIP app might be starved by competing traffic.

Now, after you have made the decision to reduce the transmission rate, you might see over time that you can reduce the jitter buffer. Perhaps it might suggest that network congestion has eased and you may now be able to increase the bit-rate. You can try that, but you might encounter congestion again. You might get into a situation where you are increasing and decreasing the bit-rate somewhat erratically.

So, what is the best algorithm? That's the point of your assignment, I think. It's a challenging problem and one that requires a bit of research, testing, etc. to get right.
durani01
Posts: 7
Joined: Sun Sep 09, 2012 7:37 pm

Re: H323 Simulation

Post by durani01 »

Sir

My understandings
I assume that you would normally want to operate at the highest bit-rate. However, that might not be true. Somehow, you must determine what your initial bit-rate should be. This might be a value determined by an enterprise or service provider in practice.

You also need to know what the acceptable min and max bit-rates should be. Again, this is a provisioned value. Perhaps the service provider never wants customers to use more than X Kbps. In that case, your algorithm must keep this max bit-rate in mind
I will start from high bit rate that is 23.85kbps, and will decrease, depends upon network traffic, congestion and buffer size.The Min would be 6.6kbps and the Max would be 23.85kbps. I want to use the full range of AMR-WB.
Once you have selected an operating bit-rate, when do you decide to reduce the bit-rate versus increasing the jitter buffer? If packets are not lost, but merely delayed, you might want to increase the jitter buffer. However, the reason for the increased delay might be due to a lot of media flows operating at a high bit-rate. So, if all devices reduced the bit-rate be 20%, for example, perhaps there would be no need to lengthen the jitter buffer.
My algorithm will regularly check the network traffic. If overall transmission rate of other devices on the network is similar or near about my transmission, I will not increase the buffer size.

I will keep check on my buffer that it would not become too large.
After reducing the bit rate, I will keep check my buffer. With the passage of time I will find that now the congestion is reduced and its time to increase the bit rate and decrease the buffer size.

There are 4- Main phases for any project from start till end.
1. Analysis, 2. Design, 3. Coding, 4. Testing

From the literature which I have will start analysis.And will try to find entities. Will let you know today.
If you have any relevant material kindly do let me know so that I start the analysis. From that will find the entities. In design phase will find the relationship between entities, the data flow, and then the entities behavior against our requests.

Q 1. How I will check on the network the others devices transmission rate?
Q 2. What would be my buffer max limit?
Q 3. How I will find that my buffer is now too long?
Q 4. To smooth the traffic, reducing the bit rate is the only option. What would I do if I find that delay is due to high bit rate of other devices and not the congestion?
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?
Q 6. What do you mean by "your VoIP app might be starved by competing traffic."?
User avatar
paulej
Posts: 595
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: H323 Simulation

Post by paulej »

durani01 wrote:From the literature which I have will start analysis.And will try to find entities. Will let you know today.
If you have any relevant material kindly do let me know so that I start the analysis. From that will find the entities. In design phase will find the relationship between entities, the data flow, and then the entities behavior against our requests.

Q 1. How I will check on the network the others devices transmission rate?
Q 2. What would be my buffer max limit?
Q 3. How I will find that my buffer is now too long?
Q 4. To smooth the traffic, reducing the bit rate is the only option. What would I do if I find that delay is due to high bit rate of other devices and not the congestion?
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?
Q 6. What do you mean by "your VoIP app might be starved by competing traffic."?
I don't have any particular literature to which to refer you, though I'm sure there is a lot on the Internet.

To your questions:
1) You would need some kind of tool, either on the device or listening on the network. The simplest approach is to control all devices in the lab so you know what the transmission rates are. You'll want a controlled environment, anyway.
2) That depends on you acceptable delay tolerance. I believe that the ITU recommends a maximum end-to-end delay of 400ms. That's not preferred, though. The preference is an end-to-end delay of less than 100ms, but often not achievable over the Internet.
3) Just check the length. If you have 20 frames in there, that would represent 400ms. That's too much, as that is the maximum the ITU recommends for end-to-end delay and you must also consider the actual transmission delay and the encoder delay. You have to somehow work out what the right number of frames to store in the buffer to reduce end-to-end delay without frequently experiencing buffer under-runs.
4) Reducing the bit-rate might be the only option if you're truly experiencing delay, yes. However, you have to figure out if it's normal delay or abnormal delay. If the delay is long simply because you are sending packets to the other side of the Earth, that's not a reason to reduce the bit-rate. Observed packet loss certainly would suggest a need to reduce the bit-rate, for example.
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.
6) If you are sending a 23.85Kbps flow and there are 1000 other devices doing the same and none of the devices reduce their bit-rates, packets will get lost when sending over a 1Mbps link :-) That's an extreme example, but that's what I meant. Even if you reduce the bit-rate, you will likely see packet loss. Your flow is being "starved", basically. FEC, again, might help recover from packet loss. But there is really nothing you can do if "unfriendly" traffic is consuming all of the link bandwidth.

TCP, as a counter example to VoIP traffic, is "friendly". When TCP sees congestion, it reduces its flow rate. All TCP implementations do this, which makes TCP an excellent transport for the Internet. TCP is even an ideal solution for VoIP. Now, once might argue that TCP is not good because it dynamically adjusts to available bandwidth. However, that is EXACTLY what you want to do to improve VoIP flows. If you knew that the network was losing packets, you would reduce down from 23.85Kbps to 6.6Kbps, perhaps. If you still lose packets, you might consider disconnecting the VoIP call, since it would indicate that there is not enough bandwidth.

UDP was selected over TCP as a transport for VoIP, but I think the reason was that voice codecs like G.711 are not rate adaptive. For any variable-rate codec, whether it's voice or video, I would believe that TCP might prove to be a better transport, especially if the application could be told about the rate reduction at the TCP layer. That said, if all UDP applications would implement a "TCP-friendly" design, that might work better. The problem is they don't and I doubt they will.
Post Reply