Packetizer Forums

Re: What does H.323 and SIP do?

2010-08-30T03:15:23Z

H.323 and SIP are protocols to allow voice and video communications over the Internet. They are widely used in various products from manufacturers, including Cisco, Polycom, Lifesize, etc. There are also used by many service providers, including AT&T, Verizon, France Telecom, China Unicom, NTT, etc.

What does H.323 and SIP do?

2010-08-30T00:52:01Z

What does H.323 ans SIP do? Those things are essential in my computer. I have no background on that so please can you elaborate and explain further about H.323 and SIP?

Cloud Computing at India's Best Business Conference

2010-07-08T08:34:30Z

Business Technology Summit 2010 – India's First, Largest and Single-most Inspirational Technology Show

Bangalore, July 7, 2010: Cloud is the Correct Answer to all Zen Koans! And Indian enterprises are at the forefront of a fundamental shift in the way they are obtaining software and computing capacity. Cloud Computing is in focus on the first day of the 2010 edition of Business Technology Summit. The summit will be held 11-12 November 2010 at the NIMHANS Convention Centre in Bangalore.

Centered on the theme Shaping Your Enterprise for New Business Realities, the third edition of India's annual summit for business technologies features some of the most important and relevant tracks that will empower you with all the necessary know-how required for your applications and your company to prosper in this climate, now and into the future. The following tracks are covered in the Cloud Conference on 11 Nobvember:

• Cloud Development: This track focuses on development patterns and best practices, looking at what's different about clouds and what computing paradigms work best. You will not only learn key lessons from seasoned cloud computing developers, but also hear from leading cloud platform vendors.
• Cloud Workshops: Expert speakers from the leading cloud computing platforms will hold forth on building different type of cloud applications for different clouds. Intensive, Interactive and Inspirational, these workshops are all you need to build exciting apps on the cloud.
• Cloud Case Studies: This track is flush with case studies and real world lessons from experts who have been there, done it. You will find out real world reasons for why companies decided to move to the cloud or stay back with on-premise IT. You will discover what worked best, how the costs stacked up, how they secured their piece of the cloud, whether performance got better or worse, and much more.
• Cloud Governance: You will learn about the risks, the regulations, the unknowns. You will also learn about compliance and mitigating Risks to hedge Against uncertainty. The tradeoffs, challenges, security issues, and all that you need to effectively govern your cloud.

For detail on the topics, visit the summit home: http://bit.ly/cloudconference. To gain a better understanding of the type of topics and speakers at Business Technology Summit, please look up the agenda for the 2009 and 2008 editions. To register with 85% discounts at Rs. 499, visit: http://bit.ly/btsregister

About Business Technology Summit
Business Technology Summit is the single most inspirational, informative and valuable event of the year for those recognise that the overall business network benefits when business technologies are made integral to the overall value equation. It offer the best chance to refresh, pick up new tips and techniques, and network with your peers to find solutions to the most pressing business technology issues today. Each year, the summit is attended by a serious audience of over thousand lively and thought-provoking IT practitioners and business leaders.

With outstanding education sessions, powerhouse speakers, and demand-driven content BTS 2010 offers cloud and SOA vendors a great way to maximize their company's visibility and maintain a heightened profile, before during and after the summit. For details on attendee demographics, products and services invited for participation, and expo floor plan, please visit www.btsummit.com/sponsorship.html. Follow the summit on Twitter, here: http://twitter.com/btsummit.

A Saltmarch Media Press Release
E: info@saltmarch.com
Ph: +91 80 4005 1000

Re: Some general questions about H.323 and SIP

2010-06-09T07:14:16Z

plong wrote:

Send us the capture file. You can upload it to the forum as an attachment.

this could be difficult because the file is about 138 MB.

But I looked at the file and saw that there is only one registration Confirm after two registration Requests. So there should be no problem. The Confirm is a reponse on both of the Requests
I also saw that the device deregister itself because the Keep-Alive Failed. Maybe the keep-alive timer isn't working well.

Re: Some general questions about H.323 and SIP

2010-06-08T17:22:04Z

Stefan,

Stefan wrote:
2. SIP nowadays is the most used VoIP protocol because it has the ability to add services and extensions easily .

False. One can also extend H.323, both through the standards process and unilaterally for proprietary features. Not sure what "add services" means.

Stefan wrote:
It's easier for programmers to learn it and create new applications.

False. H.323 and SIP are both nasty, complex, fragile protocols. SIP isn't any easier than H.323, and I've written stacks for both.

Stefan wrote:
If you just need a voice capable ip-phone a vendor has less programming efford because they only need to add the voice extensions.

False. SIP is just as hard to implement or extend as H.323.

Stefan wrote:
H.323 has to be compatible to every other H.323 application.

Not sure what is meant by "compatible." Every device using protocol X must be compatible, or interoperable, with every other device using protocol X. That's how reality works.

Stefan wrote:
I read this somewhere in the internet and there were no references so I'm not sure if this really is true.

It's false.

One thing you ought to understand is how the different standards bodies work (IETF:SIP as ITU-T:H.323). The ITU-T rigorously and with great forethought defines a standard and then folks implement it. The IETF looks for successful implementations of technologies first and then standardizes the pieces, often leaving the combination of those pieces up to vendors and ultimately the marketplace. The flexibility inherent in this bottom-up approach causes more interoperability problems than the ITU-T's top-down approach.

Paul

Re: Some general questions about H.323 and SIP

2010-06-08T16:41:43Z

Stefan wrote:
Hi Paul,
<snip>
There is no call sign because the phones can only be called from phones inside the network. I have a screenshot of a trace from last night. You can see 0:38 ; 0:40 ; 0:48 are different Disengage Requests
http://img685.imageshack.us/f/neuesbild2d.png

Send us the capture file. You can upload it to the forum as an attachment.

Re: Some general questions about H.323 and SIP

2010-06-08T15:35:39Z

In the screen shot, I also see ARQs. It appears that calls are starting and stopping. It also appears that packets are getting dropped. Note that a few times, Wireshark reported that a TCP packet was a re-transmission. If TCP is being re-transmitted, I'd bet a few UDP packets are getting lost. Packet 636924 seems odd. I see an ACF, but I don't see the ARQ. Are there overlapping calls here?

Paul

Re: Some general questions about H.323 and SIP

2010-06-08T14:58:57Z

Hi Paul,

paulej wrote:

If a device sends an RRQ to the GK and then sends another RRQ, it's OK if it gets two RCF messages, because they should essentially be the same thing. The two RRQs should be re-tries and the GK should recognize those as such. In the RRQ, do you see the same or different request sequence numbers? In the RCF messages, do you see the same or different endpoint identifier values?

my colleague has got the traces so I have to ask him tomorrow about the register requests. But if I remember right, they have the same sequence numbers.
about the RCF messages I give you feedback tommorow morning.

paulej wrote:

Is signaling getting mangled by a NAT/FW device in any way?

It's all within our corporate network, same subnet, no firewall or NAT between the devices. Only the connection to the internet is protected by a firewall.

paulej wrote:

The steps you describe for disconnecting the call seem right. One can do it that way, or one can just send a Release Complete. In later versions of H.323, we simplified the call termination procedures, since that's what many vendors were doing, anyway. (Standards sometimes dictate behavior, but implementation should also weigh in on standards.)

As for why there is a DRQ every two minutes, that makes no sense. Does it place and drop calls every two minutes? Or is it just sending DRQs every two minutes with no impact on the call? That sounds like the endpoint is in error, in any case.

There is no call sign because the phones can only be called from phones inside the network. I have a screenshot of a trace from last night. You can see 0:38 ; 0:40 ; 0:48 are different Disengage Requests
http://img685.imageshack.us/f/neuesbild2d.png

Re: Some general questions about H.323 and SIP

2010-06-08T13:37:21Z

Stefan,

If a device sends an RRQ to the GK and then sends another RRQ, it's OK if it gets two RCF messages, because they should essentially be the same thing. The two RRQs should be re-tries and the GK should recognize those as such. In the RRQ, do you see the same or different request sequence numbers? In the RCF messages, do you see the same or different endpoint identifier values?

Is signaling getting mangled by a NAT/FW device in any way?

The steps you describe for disconnecting the call seem right. One can do it that way, or one can just send a Release Complete. In later versions of H.323, we simplified the call termination procedures, since that's what many vendors were doing, anyway. (Standards sometimes dictate behavior, but implementation should also weigh in on standards.)

As for why there is a DRQ every two minutes, that makes no sense. Does it place and drop calls every two minutes? Or is it just sending DRQs every two minutes with no impact on the call? That sounds like the endpoint is in error, in any case.

Re: Some general questions about H.323 and SIP

2010-06-08T09:34:24Z

Hi Paul

today we discoverd some weird behavior of our WLAN-VoIP problem.
The mobile device does a registration request. After some time with no answer it does the registration request again. Shortly after this there are two registration confirm messages to the device. But the device answers with a deregistration request and then is deregistrated.
I think the problem is that the device gets this two registration confirms and then says: Hey I don't want to be registered to two of you. So it sends a deregistration request.

I hope you understand what I mean
Do you have any clou why this happens? Is it a WLAN problem or is the problem within the communication with the gatekeeper?

Another behavior we have seen is that the mobile device often sends disengage requests and gets disengage confirm messages. Every two minutes. I thought disengage requests are send if a telephone wants to end a call?

Let's now have a look at what happens when the call is over:

1. The two endpoints stop sending the RTP streams. They announce the closing of logical channels (H.245 Request CloseLogicalChannel).
2. The H.245 signalling channel is closed (H.245 command message EndSessionCommand followed by closing of the TCP connection).
3. The main signalling connection is also closed — the endpoints exchange Q.931/H.225.0 messages ReleaseComplete and the TCP connection is closed.
4. Each of the two endpoints informs the gatekeeper about the completed call with the H.225.0-RAS message Disengage Request (DRQ) and the gatekeeper confirms with Disengage Confirm (DCF).
5. And now the call is really over!

Re: Some general questions about H.323 and SIP

2010-06-02T14:22:57Z

Stefan wrote:
Hi Paul

if found this statement in an other forum

SIP itself isn't really workable behind NAT routers, and that has led to some kludges that have helped it along. Not easily, and not as well as if it had been designed to handle being handed out a private IP in the first place, but so far the kludges hold up.

would you agree with that? Or do you think this is not true?

Stefan
Yeah, that's true. There's nothing in SIP itself that facilitates being behind a NAT device. But, using "kludges" (which I suspect are some of the things I mentioned above), it's workable. This does assume that the SBC-type device in the public network and the endpoints behind the NAT make the same kinds of assumptions (e.g., symmetric port usage).

Paul

Re: Some general questions about H.323 and SIP

2010-06-02T07:57:45Z

Hi Paul

if found this statement in an other forum

SIP itself isn't really workable behind NAT routers, and that has led to some kludges that have helped it along. Not easily, and not as well as if it had been designed to handle being handed out a private IP in the first place, but so far the kludges hold up.

would you agree with that? Or do you think this is not true?

Stefan

H.323 and SIP NAT/FW traversal

2010-06-01T14:48:20Z

Stefan wrote:
I've read some things about NAT and Firewalls and VoIP. Some say with H.323 its more easier others say its easier with SIP becuase of the SIP Proxy. I don't know much about NAT and Firewalls. The only thing I know is that H.323 is working at the university we have installed it and they use NAT and firewalls. But I think it would run there with SIP because we tested a SIP Softphone too and it worked without problems.

Both SIP and H.323 present NAT/FW problems. Some have argued that SIP is easier for a few reasons:
1) UDP is often used for signaling, so devices can send a REGISTER message over that port to keep the port open on the NAT/FW device to enable incoming calls as a bi-product
2) Historically (and even today), the only media flow usually established is a single voice flow
2a) The UDP port advertised in the SDP is often ignored entirely
2b) The UDP port for voice is determined when the endpoint starts sending media to the service provider's allocated voice port
3) Symmetric ports are used for transmitting and receiving audio, so there's nothing special required to get media through the NAT/FW

Some of these properties are also true of H.323, but not all. H.323 devices use both UDP and TCP for signaling (RAS and "call signaling"). This makes it more challenging to get calls through the NAT/FW. This could be addressed using something like H.460.17 or perhaps H.323 Annex E. Another issue for H.323 is that voice is often not the only flows. It is not unusual to have voice, video, far-end camera control (FECC), etc.

We're now starting to see more complexity introduced on the SIP side. Things like MSRP, BFCP, etc. introduce more NAT/FW issues, so what used to work for only voice will not work anymore. This has been a motivator for introducing complex procedures like ICE.

Paul

Re: Some general questions about H.323 and SIP

2010-06-01T07:58:15Z

Hi everybody.

paulej wrote:

Bandwidth is really still a problem. Here in the US, you're lucky to get good 3G coverage and, when you do have it, the jitter and delay are horrible. I ran Skype over 3G once... it wasn't worth it. I have never had such a horrible phone call before. Perhaps the carriers can do better by routing traffic through SBCs under their control, but I don't think they can provide the level of quality people expect, yet.

Here in Germany most regions are covered good. Only a few countrysides the coverage isn't very good. Maybe LTE will change this. (Just two or three weeks ago there was a auction for frequencies for LTE).
But I don't know anything about delay or jitter.

paulej wrote:

Do you have any QoS features enabled on the WLAN? Without that, it seems you would likely have problems when more users are added. Further, you need really good coverage. Even in my own house, the bit-rate drops off significantly from one side of the house to the other due to a drop in signal strength. That said, my wife does voice/video over the wireless network daily in excess of 256Kbps and it works perfectly.

Yes QoS is enabled and the coverage is very good. Meru thinks its too good for 802.11 b/g. ( The APs are only 5-10 meters away from each other).
The last few days we are testing the whole scenario here at our office. We just use one AP and two mobile devices and the problem is still there. The WLAN coverage iss good (the phones are just 2 or 3 meters away from the AP) and nobody is logged in to the network except for the two phones. It seems there is a problem with the communication between access point and phone. There is a packet loss rate of 20% and the whole amount of failures cause the registration problems.

paulej wrote:

See the chart on the front of http://www.h323forum.org. That graph was correct as of 2006. SIP had very little traction at that time and, where it did, interconnection was always through the PSTN.

Since then, more emphasis has been put on SIP (people going along with the hype). Skype has continued to gain momentum. I mis-spoke about the 14%: it's actually 12%. Here's a reference: http://www.channelweb.co.uk/crn/comment ... ass-market.

As written in my Email some hours ago you have to pay for the new charts so I have to take the old ones

I've found a website with a lot of carriers listed. There is also written which protocols they use. Maybe you are interested in that.

http://www.voip-catalog.com/voip_protocols.html

It seems SIP and H.323 approximately have the same usage by carriers. You can see that there's a little more usage of SIP.

paulej wrote:

If video is the primary concern, then H.323 might be the better choice. Another advantage of H.323 now that we have NAT/FW specs approved is that H.323 can more easily get through NAT/FW devices without pushing media into a media relay device (see H.460.23/H.460.24). Those do require well-behaved NAT devices and they do not work with symmetric NAT, but it's still possible to build large-scale H.323 systems. Check out h323.net: that is operational and people can use it today to use H.323 devices that implement those standards. Presently, only http://www.pacphone.com supports the new specs, since they're so new.

I've read some things about NAT and Firewalls and VoIP. Some say with H.323 its more easier others say its easier with SIP becuase of the SIP Proxy. I don't know much about NAT and Firewalls. The only thing I know is that H.323 is working at the university we have installed it and they use NAT and firewalls. But I think it would run there with SIP because we tested a SIP Softphone too and it worked without problems.

Have a nice day

Stefan

Re: Some general questions about H.323 and SIP

2010-05-31T22:21:46Z

d.kochmashev wrote:

"paulej" wrote:
One issue with the enterprise is that both H.323 and SIP fall a bit short on features needed for enterprise users. As such, a proprietary line-side protocol is probably better where features like park/pick-up, "boss/secretary", and other features are needed.

Paul, do you think that H.450 is not suitable for that? Can you share your point of view with us?
The problem is that each individual H.450 feature requires supporting software. The more features you add to the endpoint, the more complex the endpoint becomes.

For that reason, where features like this are needed and often used, it's simpler to have a device control protocol in use (e.g., H.248 or MGCP).

Paul

Re: Some general questions about H.323 and SIP

2010-05-31T05:38:11Z

paulej wrote:
One issue with the enterprise is that both H.323 and SIP fall a bit short on features needed for enterprise users. As such, a proprietary line-side protocol is probably better where features like park/pick-up, "boss/secretary", and other features are needed.

Paul, do you think that H.450 is not suitable for that? Can you share your point of view with us?

Re: Some general questions about H.323 and SIP

2010-05-28T18:56:26Z

Stefan wrote:
I was searching for an mobile phone which has some VoIP functionality some months ago. In every case I found devices with SIP implemented. This probably regards to the 3GPP. I also read a white paper from nokia where SIP is regarded as smaller and more efficient than H.323 and using other Protocols like MGCP. It's not really comparing SIP and H.323 but talking about how much better SIP is. Maybe you want to have a look at it but its from the year 2003 ( http://www.nokia.com/NOKIA_COM_1/About_ ... r_voip.pdf )

I guy I work with at Nokia also said, "SIP sucks. It really sucks. But, it's what we have."

I think most who work with SIP for any length of time will tell you it has problems. But, for the mobile carrier market, SIP is it, because 3GPP adopted it and that's what the operators are going with. Having said that, I've been told about several RFPs for an H.323-based mobile phone application from carriers and/or companies that want to provide "over the top" mobile video calling services. I think in all cases, people are looking to H.323 for video.

Stefan wrote:
So have you any link where it's stated that Skype has 14% ownage of the market?
I just found out about H.323: "Today, most of the world's VoIP traffic is carried over H.323 networks, with billions of minutes of traffic being carried every month. " But with no proof or references. The site was updated in 2009 the last time maybe it's true maybe not. ( http://www.voip-info.org/wiki/view/H.323 )
I've found out that in Germany only 9% are VoIP calls but they are increasing in the last few years. It's stated by the Bundesnetzagentur (it's the agency of german government to regulate and supervise the telephone internet and mobile market.) The report is written in german so it's probably useless for you. ;(

See the chart on the front of http://www.h323forum.org. That graph was correct as of 2006. SIP had very little traction at that time and, where it did, interconnection was always through the PSTN.

Since then, more emphasis has been put on SIP (people going along with the hype). Skype has continued to gain momentum. I mis-spoke about the 14%: it's actually 12%. Here's a reference: http://www.channelweb.co.uk/crn/comment ... ass-market.

Stefan wrote:
Ten years ago, I believe the transmission rate wasn't that good as it's nowadays. But 10 years ago, applications don't need as much transmission rate either, I think

Bandwidth is really still a problem. Here in the US, you're lucky to get good 3G coverage and, when you do have it, the jitter and delay are horrible. I ran Skype over 3G once... it wasn't worth it. I have never had such a horrible phone call before. Perhaps the carriers can do better by routing traffic through SBCs under their control, but I don't think they can provide the level of quality people expect, yet.

Stefan wrote:
First I thougt about that, too, in VoIP general. Because SIP messages take more time travelling around a network because of their readable code and H.323 not because of it's binary code. But nowadays in corporate networks there is gigabit ethernet and it's not that critical I think? Maybe in the mobile market it's a different thing.

The size of the messages are not really an issue. People want to send Mbps of video through, so a few KB of signaling is, in my opinion, not an issue. In fact, we plan to use XML in H.325. XML would bring a level of consistency to all signaling and application interfaces. Had XML been around in 1995 when work on SIP got started, perhaps it might have been chosen. Now we have to deal with all kinds of syntax headaches with SIP. Every header line has a different syntax from the next. Then SDP is a whole different syntax, with each of its lines having a unique syntax. It really makes SIP a lot more complex to properly process than some folks think... until they try to do it. (I can build a half-assed implementation pretty quickly, but a robust implementation requires a lot of work.)

Stefan wrote:
I'm writing my diploma thesis about some installation in an university of applied sciences. They use H.323 and VoIP and VoIP over WLAN. The VoIP over WLAn isn't really working. Often there are deregistrations and abortions while people are talking with their handhelds. The WLAN is an Meru Networks installation and the VoIP devices are from Innovaphone. The Wireless devices are originally from Ascom but Innovaphone put their Software on them.

Do you have any QoS features enabled on the WLAN? Without that, it seems you would likely have problems when more users are added. Further, you need really good coverage. Even in my own house, the bit-rate drops off significantly from one side of the house to the other due to a drop in signal strength. That said, my wife does voice/video over the wireless network daily in excess of 256Kbps and it works perfectly.

Stefan wrote:
It seems that there are too much Access Points for 802.11 b/g but for 802.11 n coverage they are probably needed. We tried to reduce the power they send out their b/g signal but it seems there are more problems than just this one. There is 802.11 traffic in almost every channel and we can't locate the sources. Also there are two sorts of AP's installed and Meru thinks their AP's can't work together correctly. So they think we have to deinstall the cheap ones and install the expensive ones

I'm really not an expert in wirless LAN area, so I can't provide good guidance. But, I can say this definitely has focus. There are folks I work with who are focused on this problem. Whether it's a new standard for QoS, deployment guidelines, or something else, I'm really not sure. I can only speculate, myself.

Stefan wrote:
So I've heard there is an business free day on monday. So have a nice 4 day weekend!

Yes, it is. And I might even get away from the computer for a change

Thanks!
Paul

Re: Some general questions about H.323 and SIP

2010-05-28T15:00:54Z

Hey Paul.

Thanks a lot for your detailed answer. Some Points made me think a lot

paulej wrote:

Yeah, most will just argue that SIP is better because they were told so, but have no actual hands-on experience. Truth is, the work required to implement either SIP or H.323 is about the same. Back in 2000, Jeff Pulver called H.323 a dinosaur, yet both H.323 and SIP are about the same age. About the same time, a group of companies (including Nortel) argued that SIP should be adopted by 3GPP, which was fine, but they argued against H.323 using arguments that were not entirely founded. They made the most fundamental mistake of taking the most complex call flow and comparing it against the simplest SIP flow. Now look at the typical IMS flow from 3GPP-- it's complex.

I was searching for an mobile phone which has some VoIP functionality some months ago. In every case I found devices with SIP implemented. This probably regards to the 3GPP. I also read a white paper from nokia where SIP is regarded as smaller and more efficient than H.323 and using other Protocols like MGCP. It's not really comparing SIP and H.323 but talking about how much better SIP is. Maybe you want to have a look at it but its from the year 2003 ( http://www.nokia.com/NOKIA_COM_1/About_ ... r_voip.pdf )

paulej wrote:

I do not know what the percentage is, exactly. I do know that Skype owns 14% of the market.

H.323 definitely dominates the videoconferencing market and has a healthy share of the international long distance market.

So have you any link where it's stated that Skype has 14% ownage of the market?
I just found out about H.323: "Today, most of the world's VoIP traffic is carried over H.323 networks, with billions of minutes of traffic being carried every month. " But with no proof or references. The site was updated in 2009 the last time maybe it's true maybe not. ( http://www.voip-info.org/wiki/view/H.323 )
I've found out that in Germany only 9% are VoIP calls but they are increasing in the last few years. It's stated by the Bundesnetzagentur (it's the agency of german government to regulate and supervise the telephone internet and mobile market.) The report is written in german so it's probably useless for you. ;(

paulej wrote:

SIP is widely used for residential VoIP services and it's gaining momentum in enterprise VoIP as a replacement for the legacy PSTN. It's also gaining share in the mobile market (3GPP/IMS) where it was slated for use 10 years ago. However, end users do not really see that. This is really very much "behind the scenes". End users just get voice on their mobile devices like before. Perhaps it's not actually deployed all the way to the handset, since bandwidth issues have prevented that from being very usable in the past. Since I'm not actively working in this area, I've not followed-up to see. But, I would bet it is still an issue.

Ten years ago, I believe the transmission rate wasn't that good as it's nowadays. But 10 years ago, applications don't need as much transmission rate either, I think

First I thougt about that, too, in VoIP general. Because SIP messages take more time travelling around a network because of their readable code and H.323 not because of it's binary code. But nowadays in corporate networks there is gigabit ethernet and it's not that critical I think? Maybe in the mobile market it's a different thing.

paulej wrote:

This is the big question. Most vendors major vendors tend to support both, just "to be safe". One issue with the enterprise is that both H.323 and SIP fall a bit short on features needed for enterprise users. As such, a proprietary line-side protocol is probably better where features like park/pick-up, "boss/secretary", and other features are needed.

For deployments where phones are fairly autonomous (i.e., no central "iPBX" controlling their every function), then both SIP and H.323 will work. For voice, SIP really does have the "mind share" and so that might make the most sense. It's not really a technical decision, but "following the crowd charging over the cliff" kind of decision

If video is the primary concern, then H.323 might be the better choice. Another advantage of H.323 now that we have NAT/FW specs approved is that H.323 can more easily get through NAT/FW devices without pushing media into a media relay device (see H.460.23/H.460.24). Those do require well-behaved NAT devices and they do not work with symmetric NAT, but it's still possible to build large-scale H.323 systems. Check out h323.net: that is operational and people can use it today to use H.323 devices that implement those standards. Presently, only http://www.pacphone.com supports the new specs, since they're so new.

I'm writing my diploma thesis about some installation in an university of applied sciences. They use H.323 and VoIP and VoIP over WLAN. The VoIP over WLAn isn't really working. Often there are deregistrations and abortions while people are talking with their handhelds. The WLAN is an Meru Networks installation and the VoIP devices are from Innovaphone. The Wireless devices are originally from Ascom but Innovaphone put their Software on them.
It seems that there are too much Access Points for 802.11 b/g but for 802.11 n coverage they are probably needed. We tried to reduce the power they send out their b/g signal but it seems there are more problems than just this one. There is 802.11 traffic in almost every channel and we can't locate the sources. Also there are two sorts of AP's installed and Meru thinks their AP's can't work together correctly. So they think we have to deinstall the cheap ones and install the expensive ones

So I've heard there is an business free day on monday. So have a nice 4 day weekend!
Thanks for your reply.

Stefan

Re: Some general questions about H.323 and SIP

2010-05-27T16:35:02Z

Stefan wrote:
My name is Stefan, I'm from Germany and at the moment I'm writing my diploma thesis about VoIP over WLAN / WiFi. While studying some Websites and Books I found out that most people think SIP is best fitting for VoIP. Finally I found this Website and it made me happy to see some arguments form an other point of view because most of these websites don't explain why SIP is much more better than H.323. I jut wanted to ask some questions and tell you my point of view. Feel free to comment, critcise or correct my theories, questions and statements.

Yeah, most will just argue that SIP is better because they were told so, but have no actual hands-on experience. Truth is, the work required to implement either SIP or H.323 is about the same. Back in 2000, Jeff Pulver called H.323 a dinosaur, yet both H.323 and SIP are about the same age. About the same time, a group of companies (including Nortel) argued that SIP should be adopted by 3GPP, which was fine, but they argued against H.323 using arguments that were not entirely founded. They made the most fundamental mistake of taking the most complex call flow and comparing it against the simplest SIP flow. Now look at the typical IMS flow from 3GPP-- it's complex.

Ten years later, we still don't have very good interoperability between SIP systems. There are about as many flavors of SIP as there are implementations.

There has been a strange "marketing engine" behind SIP forever. There were claims that SIP is so much simpler, it will do all kinds of things that were never possible before, etc. What can it do in practice? It has proven to be nothing more than a replacement for the PSTN with functionality that's virtually the same. It's good that we moved from PSTN to IP, but what new capabilities did end users get? Not much. There is video, but we could have done that with H.323 even better.

Stefan wrote:
1. Nowadays most users (at home or with mobile phones) are using SIP for Voice. H.323 is mostly used in corporative networks and for video conferencing. I've read that SIP is growing in these areas too. But in the HD-video area vendors like Cisco only using H.323. Is this all true or are there any differences what you believe or know?

Cisco uses both protocols. Cisco's Telepresence systems use SIP with "special sauce". The behavior was documented and published for the benefit of other vendors, but the non-standard behavior was necessary for reasons, not the least of which is that SIP does not define how to do video. Sure, one can open a video stream, but there's much more to videoconferencing than just sending a video stream.

Stefan wrote:
2. SIP nowadays is the most used VoIP protocol because it has the ability to add services and extensions easily . It's easier for programmers to learn it and create new applications. If you just need a voice capable ip-phone a vendor has less programming efford because they only need to add the voice extensions. H.323 has to be compatible to every other H.323 application. I read this somewhere in the internet and there were no references so I'm not sure if this really is true.

I do not know what the percentage is, exactly. I do know that Skype owns 14% of the market.

H.323 definitely dominates the videoconferencing market and has a healthy share of the international long distance market.

SIP is widely used for residential VoIP services and it's gaining momentum in enterprise VoIP as a replacement for the legacy PSTN. It's also gaining share in the mobile market (3GPP/IMS) where it was slated for use 10 years ago. However, end users do not really see that. This is really very much "behind the scenes". End users just get voice on their mobile devices like before. Perhaps it's not actually deployed all the way to the handset, since bandwidth issues have prevented that from being very usable in the past. Since I'm not actively working in this area, I've not followed-up to see. But, I would bet it is still an issue.

Stefan wrote:
3. Nowadays SIP and H.323 have a lot of things in common and most SIP/H.323 can do H.323/SIP can do also. So what are the features of SIP and H.323 that stand out the most ? Which advantages and disadvantages are relevant regarding todays usage?

We've tried to capture those in the H.323 vs SIP page. At the end of the day, both protocols do pretty much the same thing. H.323 still has a strength in videoconferencing, whereas SIP does have an advantage in being lighter-weight in simple terminal devices, in theory. (I say that, because in order to build a terminal that does all of the proper signaling to be a robust system, you need to implement a LOT of RFCS and the complexity goes up as a result.)

Stefan wrote:
4. The future is NGN but SIP and H.323 are not fitting perfect into this. So H.325 or an alternative protocol is going to take over the market some day. How long will this take? Maybe 10 15 years or will there a hype about this? What do you think?

I question whether the future is truly NGN. NGN started out with some good ideas, but what I've seen it turn into is an effort by some to more-or-less re-invent the Internet. Why do that? Do users want that? I think NGN introduces some good ideas that might be borrowed, but I'm skeptical that it will replace the Internet.

We are defining H.325 to work with the NGN, but we definitely want it to work on the Internet, too. The concept behind H.325 is to create a very different kind of multimedia system that addresses the shortcomings of both H.323 and SIP. Of particular interest to me, I want a system that enables application developers to build all kinds of multimedia applications that I can use seamlessly in my communication with another person.

Stefan wrote:
5.If I want to implement a VoIP structure for a company with 100 VoIP users. The users will have IP-Phones and WiFi-IP-Phones and maybe some will also have Softphones. The users will call each other in that company and also people located anywhere in the world (whatever they are using VoIP or ISDN or something else). What benefits would H.323 deliver which SIP can't. I think maybe the interoperability with the PSTN would be better with H.323. If the Users want to do video calls this would also be an advantage of H.323. What else could turn the balance to H.323? Maybe there would be more different Vendors/Products for SIP, so maybe the devices would be cheaper (because they haven't got the features of H.323 devices)?

This is the big question. Most vendors major vendors tend to support both, just "to be safe". One issue with the enterprise is that both H.323 and SIP fall a bit short on features needed for enterprise users. As such, a proprietary line-side protocol is probably better where features like park/pick-up, "boss/secretary", and other features are needed.

For deployments where phones are fairly autonomous (i.e., no central "iPBX" controlling their every function), then both SIP and H.323 will work. For voice, SIP really does have the "mind share" and so that might make the most sense. It's not really a technical decision, but "following the crowd charging over the cliff" kind of decision

If video is the primary concern, then H.323 might be the better choice. Another advantage of H.323 now that we have NAT/FW specs approved is that H.323 can more easily get through NAT/FW devices without pushing media into a media relay device (see H.460.23/H.460.24). Those do require well-behaved NAT devices and they do not work with symmetric NAT, but it's still possible to build large-scale H.323 systems. Check out h323.net: that is operational and people can use it today to use H.323 devices that implement those standards. Presently, only http://www.pacphone.com supports the new specs, since they're so new.

Paul

Some general questions about H.323 and SIP

2010-05-27T13:52:36Z

Hi erverybody!

My name is Stefan, I'm from Germany and at the moment I'm writing my diploma thesis about VoIP over WLAN / WiFi. While studying some Websites and Books I found out that most people think SIP is best fitting for VoIP. Finally I found this Website and it made me happy to see some arguments form an other point of view because most of these websites don't explain why SIP is much more better than H.323. I jut wanted to ask some questions and tell you my point of view. Feel free to comment, critcise or correct my theories, questions and statements.

1. Nowadays most users (at home or with mobile phones) are using SIP for Voice. H.323 is mostly used in corporative networks and for video conferencing. I've read that SIP is growing in these areas too. But in the HD-video area vendors like Cisco only using H.323. Is this all true or are there any differences what you believe or know?

2. SIP nowadays is the most used VoIP protocol because it has the ability to add services and extensions easily . It's easier for programmers to learn it and create new applications. If you just need a voice capable ip-phone a vendor has less programming efford because they only need to add the voice extensions. H.323 has to be compatible to every other H.323 application. I read this somewhere in the internet and there were no references so I'm not sure if this really is true.

3. Nowadays SIP and H.323 have a lot of things in common and most SIP/H.323 can do H.323/SIP can do also. So what are the features of SIP and H.323 that stand out the most ? Which advantages and disadvantages are relevant regarding todays usage?

4. The future is NGN but SIP and H.323 are not fitting perfect into this. So H.325 or an alternative protocol is going to take over the market some day. How long will this take? Maybe 10 15 years or will there a hype about this? What do you think?

5.If I want to implement a VoIP structure for a company with 100 VoIP users. The users will have IP-Phones and WiFi-IP-Phones and maybe some will also have Softphones. The users will call each other in that company and also people located anywhere in the world (whatever they are using VoIP or ISDN or something else). What benefits would H.323 deliver which SIP can't. I think maybe the interoperability with the PSTN would be better with H.323. If the Users want to do video calls this would also be an advantage of H.323. What else could turn the balance to H.323? Maybe there would be more different Vendors/Products for SIP, so maybe the devices would be cheaper (because they haven't got the features of H.323 devices)?

Thank you for any response. Even it's only for one Question/Statement. I'm new at this topic so I just want to get in contact with developers and users who have several years of knowledge and practise in VoIP/SIP/H.323 and want to share their experience.

Thanks a lot!

Stefan

Looking for IMS Engineers w Lab Cert/IOT/FOA Test Experience

2010-04-06T21:38:52Z

Must be US Citizen or possess valid Green Card. Unable to sponsor.

Project Start Date: April 15th
Duration: 6 Mos+
Location: Bellevue/Redmond, WA

Project Scope:

IMS Network Elements Validation:

-BGCF
-HSS 7.X
-I-CsCf, S-CsCf, P-CsCf
-mTAS & AoIP
-Movial, support Android stack development
-TAS
-Core Support for MRF
-IMP
-Presence
-All back office IP, systems integration support

Key Activities include,

-Lead lab validation effort of above IMS network nodes software release until they lab exit.
-Lead FOA validation effort of above IMS network nodes software release.
-Lead end to end validation of the above IMS network nodes with existing network nodes in lab and FOA.
-Provide ongoing support for these nodes validation effort in the lab and production until GA.
-Prepare and submit weekly status report.
-Implementation and validation of new IMS design focusing on client requirements for the platforms.
-Complete upgrades of IMS nodes in client lab for validation efforts.
-Create test plans for lab and FOA validation efforts of new IMS related functionality.
-Troubleshoot technical issues reported in client lab related to the IMS.
-Review feasibility of new Validation Requests, and work with Design counterparts to finalize validation requirements and plans.
-Execute test plans in lab and FOA as required.
-Document all test results and findings from validation efforts and lead review of conclusions with project stake holders.
-Interface with client Handset validation and Product Development teams to understand requirements for new handset validation efforts configure required test environments and troubleshoot IOT issues between handsets and IMS infrastructure.
-Perform regressing testing for all sustaining and new releases

Required Skills:

-US Citizens or Possess Valid Green Card. Unable to sponsor
-4-year college degree BS and or MS in Software / Telecommunication/IT engineering or equivalent work experience
-5 year experience in engineering, design and development
-3-5 years experience in IMS development, testing and deployment
-2 years end to end IMS experience in certification of SIP peering, MGCF, BGCF, I/S CSCF

Preferred Skills:
-Earlier experience in IMS Solution Architect and Validation SME role
-Ability to work independently
-CCIE or CCNP with 2-3 years hands on experience
-Knowledge of the Cisco, Nokia, Alcatel Lucent and Ericsson IMS solutions
-Experience of integration of complex systems in operator environments
-Knowledge of IMS Architecture, IMS Common system and related nodes/protocols, IP networking, Linux/Unix, TSP
-Broad knowledge of Telecommunication Networks from Service and Application Layer through to Backbone.

Please send qualified resumes to recruiting.bussolutions@gmail.com

OpenID Support

2010-03-27T00:11:35Z

We've added OpenID support to Packetizer Forums to make it easier to log in and create accounts!

If you run your own phpBB board, you might also want to add OpenID Support to your site:
http://www.zenorsoft.com/community/view ... f=30&t=841

And if you wish to operate your open OpenID server, you might consider downloading software that easily lets you do so:
http://www.packetizer.com/security/openid/

Cheers!
Paul

SIP is not an emerging protocol

2010-03-14T02:01:09Z

Why is it that after 14 years since the first publication of the SIP Internet Draft is it that people continue to refer to SIP as an "emerging" protocol? 14 years!?!?!

I herewith declare that SIP is NOT am emerging protocol.

ITU Initiates Focus Group on Cloud Computing

2010-02-25T16:20:56Z

The ITU is establishing a Focus Group to look at standardization issues related to Cloud Computing. For the Terms of Reference, refer to this document:

http://ftp3.itu.int/av-arch/avc-site/20 ... D-3853.zip

Paul

Welcome!

2010-02-12T22:38:45Z

Folks,

Welcome to the H.323 Global Network discussion area. These forums are open to anybody who wishes to ask questions about how to get involved in the project, configure equipment, etc.

Cheers!
Paul E. Jones
Rapporteur, ITU-T Q2/16

Google's phone has arrived

2010-01-06T05:35:03Z

Folks,

Some might have been hiding under a rock and missed the announcement earlier:
http://www.dailypayload.com/content/3371

This looks like a very impressive device. If you've not had a chance to play with other Android devices, you really ought to visit your local wireless store and do that. I think Google is setting the stage for a significant shift step forward in terms of what we can do with mobile devices.

Apple has had a good run and, quite frankly, I think they're going to be forced to make some changes in order to compete against the forthcoming Android devices. Knowing Apple, I'm sure they've got something planned.

In any case, this device really looks cool.

Paul

(Still using an old Windows Mobile device...)

Re: t38FaxMaxDatagram (H.245)

2009-12-18T19:56:44Z

This parameter represents the largest size of the datagram that can be accepted by the receiving device. This does not count RTP headers, for example. There is debate as to whether this counts redundancy, but I think the general consensus is that it does not consider redundancy. So, if a device that advertises 72 octets also supports redundancy can actually receive larger UDP packets (containing the primary and redundant data), but the intent is that the primary fax data would not consume more than 72 octets.

This and many of the T.38-related parameters have been a source of confusion and, for that reason, there are currently three efforts underway to work to clarify how T.38 is supposed to work. It is expected that a new revision of T.38 will be made available next year with better definitions. And, you're definitely encouraged to contribute. Part of the work is going on in the SIP Forum (where I'm engaged). Some of the work is going on in the ITU (in which I am indirectly involved). I just recently learned that i3 Forum is also doing work in this area.

t38FaxMaxDatagram (H.245)

2009-12-18T07:02:18Z

Paul, please help me to understand the correct meaning of t38FaxMaxDatagram. When using UDP TL does this parameter define the maximum UDP data size which receiver CAN process? If receiver sets t38FaxMaxDatagram = 72 should sender transmit UDP packets with no more than 72 bytes of data?

Re: Help parsing OLC info in H225 messages

2009-12-07T01:52:17Z

Yes the change I made does apparently trick the compiler into thinking it is a different type. When I decode a message with debug printing enabled it calls it an OpenType and then I can decode that as an OpenLogicalChannel_PDU. Without that change it just considers it a sequence of octet stream but then I can't decode it because I have no way of decoding OpenLogicalChannel types. There are a very small (14) number of messages types that are defined as decodable PDUs and that is not one of them. Once it is defined as a new type my compiler also adds the ability to decode OpenLogicalChannel_PDU types.
Again, I'm constrained by the tools we currently use and have to rely on what the compiler will generate from the asn files and then subsequently what it deems as decodable types. I'm not in a position at this time to upgrade our tools although as time goes on that may become necessary.
If this does the trick for now (which it appears it will) I'll probably just got with it. BTW I found that little change to the asn somewhere in my random downloads trying to get around this issue so somebody else must have been having a similar issue. There was another change having to do with h245 tunneling that I didn't grab but may need ultimately.

Diana

Re: Help parsing OLC info in H225 messages

2009-12-05T20:55:27Z

I am sure there is a reason why it was defined that way at the beginning, but I can't say why now. Perhaps it was just to avoid importing types from H.245. Indeed, we did not import types from H.245 until H.323v3.

The change you made I suppose tricks the compiler into thinking the type is a different type, but I've never found that to be necessary with the tools I used. I would decode the message and then pass a pointer to the buffer to the decode() routine. As a parameter to the deocde() function, I could explicitly tell it that it was an OpenLogicalChannel type. All ASN.1 decoders must do that, since it must be told what kind of PDU it is decoding. I've never found it necessary to modify the ASN.1 to accomplish what you want to do.

Paul