Evan, you asked,
>>Could you expound a bit on the Backwards compatibility, as I have not heard it really mentioned before.<<
You already know this, but the name may have thrown you. Nothing exotic, although hard to achieve sometimes, backwards compatibility exists when a new version of any generic object, be it hardware or software, is able to properly work in substitution of (or with) existing or even previous versions of that same generic which was in place before it. Difficulties arise when orchestration must be maintained in a larger environment among many different devices working together in a rev-defined set of processes.
My 5.0 version of Visio Software, for example, backwards compatibly reads the files of the drawings I created earlier with Version 4.5. Version 4.5 software, however, is not able to read 5.o. You are familiar with this joy of automation, aren't you? <g>
Often times a vendor will have proprietary code in a "standards based" application in a line of hardware, software, whatever, and they will release new products that will work backwards with their previous versions, as well as forwards. Potential problems sometimes occur between different vendor lines when a new release from Brand X does not backwards compat with the environment in which its predecessor was placed, or with a previous release of Brand Y's in that environment. It is said to be backwards incompatible then, and the vendors need to duke it out, often resulting in a temporary <cough> patch or fix, or a new version release.
>>On a somewhat related tangent, I read in a recent issue of IP Telephony on some of the issues, outside of the existing codec standards, that affect interoperability. They expressed that there was a need for standards in Bandwidth management, call setup and signaling, among other issues before true compatibility would be capable between the different vendors.If perhaps you or Mr Pulver, and it is great to see him post here, could discuss some of these aspects and if they are being addressed by the ITU or similar..<<
Guess Jeff is off to some show somewhere...
Bandwidth management. Vague concept based on the misuse of a term, often. I'd have to read the actual article, but from what I infer, they are talking about reserving channel resources in some way, perhaps through Resource reSerVation Protocol, or RSVP; real time protocol, or RTP; and real time control protocol, RTCP.
Sometimes altering packet lengths is performed by auto-sensing and compensation capabilities like AGC, to properly compensate for longer-term latency trending. This could result in noticeable differences in quality at the extreme conditions, consequently.
Since VoIP will prevail in a number of diverse environments characterized by varying levels of hostility, i.e., the Public Internet, VPNs, Intranets/Extranets, LANs, you name it, it sometimes will reside in ideal conditions [where traffic management and shaping could be easily controlled and bandwidth is allocated with predictability ], and sometimes not, as in the case of the Public sector.
These dissimilar environments must be negotiated dynamically and the protocol must be able to sense (or set to defaults in the more controlled nets) in order to properly compensate for the adverse effects of variable packet delays and lost UDP packets.
That's an over-simplification to a relatively complex problem. I hope that it adequately addresses your question.
[Curtis, I would be honored if you jumped in here added to this, if you would...]
Call setup and signaling is effectively the equivalent of the same basic sequences that exist when you dial an ordinary telephone number using a black phone. Whereas the PSTN uses SS7 to do look-ahead surveillance and link reservations prior to the connection being made, which could either be prior to or after the determination of the status of the called party's line (if it is busy you get a locally generated busy signal, if it is not, the link is created), on the Internet the hand-shake is done using TCP/IP in combination with the signals of "other origins." The latter is dependent on the nature of the type of interfacing taking place and what it interfaces to.
When you go beyond the simple call setup, other database lookups are required that are beyond a simplified response here.
If you are interested, I could give you the titles and ISBNs of some TCP/IP, ITU-IMTC, CTI and SS7 textbooks that will drive you to distraction and beyond with explanations. <g>
Keep in mind that all of the above, with the possible exception of the backwards compatibility issue, are gross over-simplifications. If things were as simple as I stated, there'd be no stock play over the technology.
Best Regards, Frank Coluccio
|
