Have them write a program based on Benford's Law. The task combines statistics and programming. The results are interesting, too. Have them find a real dataset online and run it through their program to determine how likely fraud was involved in producing it. I wrote just such a program--it should be tiny--and evaluated population per county in Texas. Was legit! Also have them create their own fraudulent dataset and show that it is fraudulent via their Benford's-Law program.
"FLIF... is not encumbered by software patents." I wonder what they mean by this. Maybe that the authors have not applied for patents or, as far as they know, FLIF does not infringe on any patents? Regardless, anyone at any time can make a patent claim. Unless someone with big pockets provides patent indemnification, there is no guaranteed that FLIF won't be challenged in the future.
Re facial recognition. I worked in the video-surveillance industry for a few years, and video analytics, especially facial recognition, is a big joke. False positives render it near useless.
Actually, if the design is robust and complete, coding is trivial. For example, I once developed a client for a proprietary FTP server. It took two months to design but just two weeks to code and test. Plus, the design included FSMs that were exploited to develop a test suite for full code coverage. In the end, there were just two coding bugs and one design bug. People are so used to designing on the fly these days while they code. I shake my head in disbelief. Software development has regressed considerably in the last decade or so.
I implemented a floating-point package years ago on a system whose integer CPU did not support floating point. I returned as close to infinity as I could--the largest floating-point number. Mathematically incorrect, but for its purpose, this worked just fine.
Why do you say SCCP is awful? I've developed stacks for SIP, H.323, MGCP, and H.248, and SCCP is no nastier than those. They all have problems, especially SIP. SCCP is proprietary to Cisco and is basically just C structs transmitted on the line, but it is quite flexible. BTW, SIP and H.323 are high-level, smart-device protocols, whereas MGCP, H.248, and SCCP are stimulus/response, or primtive, protocols. Different beasts. I personally think that stimulus/response protocols are the way to go.
Someone else already gave the right answer, but I also heard that there once was a project within Cisco called "Skippy." I was told not to refer to SCCP as Skippy around some Cisco folks because there is some sort of bad vibe about the Skippy project. Can you say, "failed project?"
It shouldn't effect you at all. BT is replacing their network, not the local loop ("The switch-over will be seamless from the customer's perspective..."). IOW, you will still use your old analogue phone, and the copper wires will still connect your phone to the End Office, but from there on it will be all VoIP. A truly "end to end IP (Internet Protocol) based network," where you have VoIP phones everywhere, will take many decades to implement.
VoIP isn't as exotic as people may think--you've been using it for several years on most long-distance calls for at least part of the circuit. And all of this traffic is H.323 and not SIP.
H.323 is horribly difficult, expensive to implement
The is the wishful mantra of SIPfolk, but it's not true. H.323 is no more expensive or difficult to implement than SIP....it requires ASN.1 encoding...
So? SIP requires ABNF and SDP encoding. An H.323 ASN.1 codec can be smaller (first-hand experience) and faster (there is a benchmark comparing text and binary encodings similar to SIP and H.323) than a SIP ABNF/SDP codec, and it always results in much smaller messages. SIP painted itself into a corner with text encoding. Because of its rather large messages, entities have to transmit messages via TCP or UDP on a message-by-message basis. Geez, what a hack!...and multiple complex channels and layers of protocol...
Like what? H.323 sets up the call on a call-signaling channel, which is the part that is equivalent to SIP. Call control (sort of like SDP) is done on another channel or tunneled within the call-signaling channel, ala SDP encapsulated within SIP. Media uses RTP/RTCP, just like SIP. If you want alias resolution, you use RAS to talk to a gatekeeper the same way that SIP resolves URLs with a location server. And what do you mean by "layers of protocol?"
...and while it may not be dead, it has very little momentum compared to SIP.
H.323 provides many many more billable call minutes than SIP and will continue to do so for the foreseeable future. Check out these lists of H.323 service providers and products.
Even Microsofts latest MSN messenger does SIP!
It's not SIP, it's SIP-based like the way they support every other standard.
It's not old. SIP and H.323 are the same age--circa 1996--and are based on the same underlying packet-switched technology. H.323 grew up faster, although SIP is catching up.
I've developed two commercial SIP stacks, each about one man year. While I haven't developed an H.323 stack, I've worked with both the OpenH323 [openh323.org] and RadVision [161.58.151.216] H.323 stacks, and SIP is much, much simpler.
Well, I've developed H.323, SIP, MGCP, and H.248/Megaco from the ground up--third-party stacks are for wimps;-)--and I have found that a full SIP and H.323 implementation are about the same complexity, take about the same amount of mandays to implement, and occupy about the same executable footprint. SIP tends to churn the heap more than H.323, though, due to all of the text that is typically carried around. SIP messages tend to be rather large, too, making TCP look awfully attractive despite the SIPfolk's earlier decrying of H.323 for using TCP. In what way, exactly, do you believe that SIP is simpler?
I don't have a copy of the H.323 Recommendation because I'm not willing to buy it.
There is no need to buy it. For a few years now, the ITU has allowed three free spec downloads per year per email address. Need more than three specs per year? Use another email address--hey, they're free, too!!!:-) Even if you had to buy a few specs, they're only like $13 each. For maybe $100, you could have all the Recommendations you'd ever need for H.323. If you don't want to invest a tiny amount of $$ for the specs and don't want the free downloads, you could also get the final, pre-publication drafts from http://www.packetizer.com/iptel/h323/.
However, the ITU's H.323 download page [itu.int] shows that the H.323 spec is 2,112,158 bytes in pdf format, while the latest SIP spec is 1,231,871 bytes. This non-conclusive evidence suggests that the H.323 spec is in fact twice as large as the SIP spec.
That's unfair. The H.323 spec contains lots of space-consuming diagrams, whereas the SIP spec contains lots of corresponding yet more space efficient ASCII art.:-) The SIP RFC is 269 pages long (http://www.ietf.org/rfc/rfc3261.txt), whereas the H.323 Recommendation is 237 pages long (http://standard.pictel.com/ftp/avc-site/till_0012/0011_Gen/H323v4-final_010206.zip), and that's probably A4-size pages.
H.323 has numerous annexes as well.
Granted. My point, though, is that whether or not one counts their respective annexes, SIP and H.323 are about the same complexity. SIPfolk thought long ago that H.323 was way too complicated but have found out through a long learning process that it is no more complicated than it needs to be to solve the problem.
Most SIP developers speak highly of the protocol, and while there are problems, I certainly wouldn't call it "a mess".
The same goes for H.323.
I have not seen these kinds of interoperability issues at the interops.
To be fair, I have not attended one, so I must depend on the observations of neutral colleagues.
The only reason H.323 is just now achieving interoperability...
Yeah, right, "just now." H.323 is no less interoperable than SIP, and I say that with first-hand experience of having to assure interoperability with various vendors for both protocols. Hey, these are very complex protocols. Plus, vendors do stupid things with both protocols, but H.323 is not prone to more interop problems than SIP. Why do you think that it is?...is because of the consolidation of the video conferencing industry into a single dominate vendor: Polycom.
H.323 is still the dominant choice of both videoconferencing and VoIP services providers (http://www.h323forum.org/products/service_provide rs.asp). It is popular because it works, not because of the supposed dominance of one or even a few vendors out of the many (http://www.h323forum.org/products/).
One difference: H.323 requires support of patened codecs, building in a revenue source for those controlling the standard. SIP has no such codec requirements,...
No difference. This is another one of those H.323 SIP maxims that are either totally false or very misleading. If an endpoint supports video (video is not required), it is required to support H.261. Three comments about this. 1. I know of no patent claims against H.261. 2. There are no other requirements with respect to video codecs. 3. Virtually all video-capable endpoints support H.263 even though they are not required to--a few don't even support H.261.
Regarding audio, an endpoint must support G.711 only if the connection end-to-end is high-bit-rate (>=56kbps). Three comments. 1. I know of no patent claims against G.711. 2. There are no other requirements with respect to audio codecs. 3. G.711 is super simple--just a table lookup--so everybody supports it.
Now, why exactly do you believe that H.323 requires the use of patented codecs?...although I agree that in practice those same codecs are used by many SIP clients.
Thank you.
Interestingly, those filing patents against IETF standards tend to be frozen out of the standards process, which hopefully acts as a deterant.
The same thing is happening in H.323. Right now there is a battle being waged for the intellectual liberty of a particular video codec.
Complexity: I've implemented SIP, H.323, et al., and SIP is just as complex as H.323. To wit, RFC 3261 is the largest RFC ever produced and even larger than the H.323 Recommendation. Add on all of the supporting RFCs and I-Ds, and you have a real mess. Folks even talk about the mess on the SIP reflectors.
Interoperability: SIP is not more interoperable than H.323. Geez, I think their up to 13 or 14 interop events so far, and I've heard from those in attendance that SIP interoperability is getting harder and harder to achieve.
Patents: There are no patents that I am aware of regarding H.323. There are, however, patent claims against some codecs used by H.323, e.g., G.723.1 and G.729, but those same codecs are also used by SIP. Moreover, there are several patent claims against SIP (http://www.aful.org/wws/arc/patents/2003-01/msg00 082.html).
Microsoft: I agree that they will hurt SIP more than help. Note that Messenger is merely SIP-based.
Slashdot Mirror
Have them write a program based on Benford's Law. The task combines statistics and programming. The results are interesting, too. Have them find a real dataset online and run it through their program to determine how likely fraud was involved in producing it. I wrote just such a program--it should be tiny--and evaluated population per county in Texas. Was legit! Also have them create their own fraudulent dataset and show that it is fraudulent via their Benford's-Law program.
"FLIF ... is not encumbered by software patents." I wonder what they mean by this. Maybe that the authors have not applied for patents or, as far as they know, FLIF does not infringe on any patents? Regardless, anyone at any time can make a patent claim. Unless someone with big pockets provides patent indemnification, there is no guaranteed that FLIF won't be challenged in the future.
Re facial recognition. I worked in the video-surveillance industry for a few years, and video analytics, especially facial recognition, is a big joke. False positives render it near useless.
Actually, if the design is robust and complete, coding is trivial. For example, I once developed a client for a proprietary FTP server. It took two months to design but just two weeks to code and test. Plus, the design included FSMs that were exploited to develop a test suite for full code coverage. In the end, there were just two coding bugs and one design bug. People are so used to designing on the fly these days while they code. I shake my head in disbelief. Software development has regressed considerably in the last decade or so.
I implemented a floating-point package years ago on a system whose integer CPU did not support floating point. I returned as close to infinity as I could--the largest floating-point number. Mathematically incorrect, but for its purpose, this worked just fine.
Why do you say SCCP is awful? I've developed stacks for SIP, H.323, MGCP, and H.248, and SCCP is no nastier than those. They all have problems, especially SIP. SCCP is proprietary to Cisco and is basically just C structs transmitted on the line, but it is quite flexible. BTW, SIP and H.323 are high-level, smart-device protocols, whereas MGCP, H.248, and SCCP are stimulus/response, or primtive, protocols. Different beasts. I personally think that stimulus/response protocols are the way to go.
Someone else already gave the right answer, but I also heard that there once was a project within Cisco called "Skippy." I was told not to refer to SCCP as Skippy around some Cisco folks because there is some sort of bad vibe about the Skippy project. Can you say, "failed project?"
BTW, just found out that BT will be using SIP (interoperability be damned) because it wants mobile integration.
VoIP isn't as exotic as people may think--you've been using it for several years on most long-distance calls for at least part of the circuit. And all of this traffic is H.323 and not SIP.
H.323 is horribly difficult, expensive to implement
...it requires ASN.1 encoding...
...and multiple complex channels and layers of protocol...
...and while it may not be dead, it has very little momentum compared to SIP.
The is the wishful mantra of SIPfolk, but it's not true. H.323 is no more expensive or difficult to implement than SIP.
So? SIP requires ABNF and SDP encoding. An H.323 ASN.1 codec can be smaller (first-hand experience) and faster (there is a benchmark comparing text and binary encodings similar to SIP and H.323) than a SIP ABNF/SDP codec, and it always results in much smaller messages. SIP painted itself into a corner with text encoding. Because of its rather large messages, entities have to transmit messages via TCP or UDP on a message-by-message basis. Geez, what a hack!
Like what? H.323 sets up the call on a call-signaling channel, which is the part that is equivalent to SIP. Call control (sort of like SDP) is done on another channel or tunneled within the call-signaling channel, ala SDP encapsulated within SIP. Media uses RTP/RTCP, just like SIP. If you want alias resolution, you use RAS to talk to a gatekeeper the same way that SIP resolves URLs with a location server. And what do you mean by "layers of protocol?"
H.323 provides many many more billable call minutes than SIP and will continue to do so for the foreseeable future. Check out these lists of H.323 service providers and products.
Even Microsofts latest MSN messenger does SIP!
It's not SIP, it's SIP-based like the way they support every other standard.
H323 may be old
It's not old. SIP and H.323 are the same age--circa 1996--and are based on the same underlying packet-switched technology. H.323 grew up faster, although SIP is catching up.
I've developed two commercial SIP stacks, each about one man year. While I haven't developed an H.323 stack, I've worked with both the OpenH323 [openh323.org] and RadVision [161.58.151.216] H.323 stacks, and SIP is much, much simpler.
;-)--and I have found that a full SIP and H.323 implementation are about the same complexity, take about the same amount of mandays to implement, and occupy about the same executable footprint. SIP tends to churn the heap more than H.323, though, due to all of the text that is typically carried around. SIP messages tend to be rather large, too, making TCP look awfully attractive despite the SIPfolk's earlier decrying of H.323 for using TCP. In what way, exactly, do you believe that SIP is simpler?
:-) Even if you had to buy a few specs, they're only like $13 each. For maybe $100, you could have all the Recommendations you'd ever need for H.323. If you don't want to invest a tiny amount of $$ for the specs and don't want the free downloads, you could also get the final, pre-publication drafts from http://www.packetizer.com/iptel/h323/.
:-) The SIP RFC is 269 pages long (http://www.ietf.org/rfc/rfc3261.txt), whereas the H.323 Recommendation is 237 pages long (http://standard.pictel.com/ftp/avc-site/till_0012 /0011_Gen/H323v4-final_010206.zip), and that's probably A4-size pages.
...is because of the consolidation of the video conferencing industry into a single dominate vendor: Polycom.
e rs.asp). It is popular because it works, not because of the supposed dominance of one or even a few vendors out of the many (http://www.h323forum.org/products/).
...
...although I agree that in practice those same codecs are used by many SIP clients.
Well, I've developed H.323, SIP, MGCP, and H.248/Megaco from the ground up--third-party stacks are for wimps
I don't have a copy of the H.323 Recommendation because I'm not willing to buy it.
There is no need to buy it. For a few years now, the ITU has allowed three free spec downloads per year per email address. Need more than three specs per year? Use another email address--hey, they're free, too!!!
However, the ITU's H.323 download page [itu.int] shows that the H.323 spec is 2,112,158 bytes in pdf format, while the latest SIP spec is 1,231,871 bytes. This non-conclusive evidence suggests that the H.323 spec is in fact twice as large as the SIP spec.
That's unfair. The H.323 spec contains lots of space-consuming diagrams, whereas the SIP spec contains lots of corresponding yet more space efficient ASCII art.
H.323 has numerous annexes as well.
Granted. My point, though, is that whether or not one counts their respective annexes, SIP and H.323 are about the same complexity. SIPfolk thought long ago that H.323 was way too complicated but have found out through a long learning process that it is no more complicated than it needs to be to solve the problem.
Most SIP developers speak highly of the protocol, and while there are problems, I certainly wouldn't call it "a mess".
The same goes for H.323.
I have not seen these kinds of interoperability issues at the interops.
To be fair, I have not attended one, so I must depend on the observations of neutral colleagues.
The only reason H.323 is just now achieving interoperability...
Yeah, right, "just now." H.323 is no less interoperable than SIP, and I say that with first-hand experience of having to assure interoperability with various vendors for both protocols. Hey, these are very complex protocols. Plus, vendors do stupid things with both protocols, but H.323 is not prone to more interop problems than SIP. Why do you think that it is?
H.323 is still the dominant choice of both videoconferencing and VoIP services providers (http://www.h323forum.org/products/service_provid
One difference: H.323 requires support of patened codecs, building in a revenue source for those controlling the standard. SIP has no such codec requirements,
No difference. This is another one of those H.323 SIP maxims that are either totally false or very misleading. If an endpoint supports video (video is not required), it is required to support H.261. Three comments about this. 1. I know of no patent claims against H.261. 2. There are no other requirements with respect to video codecs. 3. Virtually all video-capable endpoints support H.263 even though they are not required to--a few don't even support H.261.
Regarding audio, an endpoint must support G.711 only if the connection end-to-end is high-bit-rate (>=56kbps). Three comments. 1. I know of no patent claims against G.711. 2. There are no other requirements with respect to audio codecs. 3. G.711 is super simple--just a table lookup--so everybody supports it.
Now, why exactly do you believe that H.323 requires the use of patented codecs?
Thank you.
Interestingly, those filing patents against IETF standards tend to be frozen out of the standards process, which hopefully acts as a deterant.
The same thing is happening in H.323. Right now there is a battle being waged for the intellectual liberty of a particular video codec.
It will be interesting to see what happens...
Indeed.
Complexity: I've implemented SIP, H.323, et al., and SIP is just as complex as H.323. To wit, RFC 3261 is the largest RFC ever produced and even larger than the H.323 Recommendation. Add on all of the supporting RFCs and I-Ds, and you have a real mess. Folks even talk about the mess on the SIP reflectors.
0 082.html).
Interoperability: SIP is not more interoperable than H.323. Geez, I think their up to 13 or 14 interop events so far, and I've heard from those in attendance that SIP interoperability is getting harder and harder to achieve.
Patents: There are no patents that I am aware of regarding H.323. There are, however, patent claims against some codecs used by H.323, e.g., G.723.1 and G.729, but those same codecs are also used by SIP. Moreover, there are several patent claims against SIP (http://www.aful.org/wws/arc/patents/2003-01/msg0
Microsoft: I agree that they will hurt SIP more than help. Note that Messenger is merely SIP-based.
IMO, the emperor has no clothes.