"TDM can do GÇ£follow meGÇ¥, the cell guys have been dong it for years using TDM and SS-7.) And TDM could easily be modified to provide integrated messaging, computer screen web-based access to information, etc. The reason it has not been done yet is the dominant TDM providers can get as much money without doing it. Why serve the customer when you have a monopoly? "
While I find it interesting to read what COULD be done within a TDM structure, I prefer the reality of what is achievable within a VOIP structure with a little individual initiative.
One of the features that I have been playing around with is a virtual office "cube space" I for one miss the days when I could yell through the wall to one of the team members so that outstanding issues / misunderstandings can be resolved quickly and informally. I think they call it productivity... Well with a VOIP system you or I can create this same experience, like a virtual party line. If you add voice command recognition and use this to enable automatic "dialing" than suddenly the spoken phrase "John have you got the details of that deal......" becomes a command John (look up John's IPaddress ) buffer voice string, send voice note, open channel to recieve John's reply.
I'll be the first to admit that what I'm doing is currently just a game for bored geeks, but I'll guarantee you that if we fix some of the kinks than I'll have a product long before you can even get the powerpoint slides finished for the telco project review. I think what is even more important is that I'll be able to address the whole world as a potential market, which will directly buy my product. In the POTS system either the local Telco or some SI has to develop the product and than market it there are lots of up front expenses meaning lots of reasons to shoot holes in the business plan, furthermore this will probably only ever be a geek product so no telco will ever start the ball rolling meaning dead product!
As MG often says if you just focus on supplying a good quality pipe than the application layer will take care of itself and directly reward those with good ideas and good implementations. That's the VOIP value proposition.
re: Telecom Exec: VOIP Is a Pain"supplying a good quality pipe than the application layer will take care of itself and directly reward those with good ideas and good implementations. That's the VOIP value proposition."
I was involved in a similar application that used SS7 AIN (SCP and SCE) about 10 years ago for ATM and then TDM. It did not include voice recognition (not available at the time) but was initiated by choices on a web page. This service was created using the SCE (Service Creation Environment) and was delivered in about two weeks on an SCP. A conferencing service was also created this way. Both demo'ed at SuperComm numerous times as BBIN using ATM, the hot topic at the time.
The fact it was not a popular application was that it was marketed poorly and as pendelton wrote, "Why serve the customer when you have a monopoly?"
Now if you follow my postings I believe that IP at the edge does offer more flexibility for new services. More diverse open minded programmers/developers. But the services must offer added value, worth the resources (time, effort & $$) of the subscriber.
As a previous bleading edge application developer for enterprises, I have only found a couple of those valuable IP applications that haven't been available yet. Sometimes, if you look, the applications can be found lost, left in an old storage room.
re: Telecom Exec: VOIP Is a PainHi voyce_overipee, Yes, I was afraid I'd used the wrong terminology. Of course in the IP world "protocol" usually refers to one RFC or draft, rather than a complete solution.
OK, it's RTP that's the problem. That's like BMW saying their new car has got great bodywork, suspension, braking systems and steering, but there's a design flaw in the engine. Unless you get the whole thing right you're not going to have a successful solution.
The component-level view of problems taken by the IETF works fine in ad-hoc environments, but when it comes to national-scale carrier voice....
Having said that, did the ITU do a better job? Of course not, because they don't have the authority to make changes in the underlying IP architecture!! Doh!
You said it. Realistically transformations like this are very difficult to predict. The laser was invented in about 1960 and as near as I can remember spent the next 20 years being described as "a technology in search of applications". Today we've probably got a dozen lasers in each one of our homes, and a lot more in our offices. Not to mention the millions of lasers we bury in the ground and under the ocean :-)
I think your utility reference is very apt. The cost model for service providers historically is way too high - especially in highly unionised environments where change is expensive, and slow to push through. It might sound simplistic, but this situation has to change.
re: Telecom Exec: VOIP Is a PainHi alchemy, That's a good point about the SIM. GSM and emerging 3G technologies do benefit from the ability to authenticate via the SIM. As they move to use IP transport the various companies involved want to maintain that capability.
But Fixed Mobile Convergence is all the rage at the moment, so we're seeing the mobile and fixed line worlds collide.
As I understand it there's a lot of kickback from the wireline folks who don't want to have to put SIMs into PCs, VoIP phones etc.
re: Telecom Exec: VOIP Is a Painfgoldstein wrote: Now we have two plausible and non-mutually-exclusive problems with T-W's VoIP. One is the multi-vendor issue: Multi-vendor compatibility is precisely the reason why there are architectural standards.
I believe T-W is end to end Cisco other than the MTAs. Cisco routers. Cisco CMTSs. Cisco PacketCable VoIP core elements like soft switch & media gateways. The MTAs are multi-vendor but there are only a few vendors and CableLabs and, I'm sure, Cisco both test them exhaustively. All MTAs are derived from Broadcom or Texas Instruments reference designs so they all behave similarly.
re: Telecom Exec: VOIP Is a PainGeoff Bennett writes: That's a good point about the SIM. GSM and emerging 3G technologies do benefit from the ability to authenticate via the SIM. As they move to use IP transport the various companies involved want to maintain that capability.
Yep. As a service provider, if you can force all your customers to use SecureCard types of technology, it really cuts down on issues of theft of service and denial of service.
But Fixed Mobile Convergence is all the rage at the moment, so we're seeing the mobile and fixed line worlds collide.
And it's the mobile device attributes that are going to drive the solutions. Since every phone has a SIM card (other than holdouts in North America), that should be the authentication technology for fixed mobile convergence. The issues then become business issues of letting two different networks know about the same SIM card.
As I understand it there's a lot of kickback from the wireline folks who don't want to have to put SIMs into PCs, VoIP phones etc.
Right. And if you're doing primary line services, that means you're going to be stuffing session border controllers all over the place and doing all kinds of deep packet inspection and policing to ensure your network doesn't get taken down by some kid on a Windows PC.
In my point of view, there are 3 kinds of architectures for VoIP:
An architecture where you at least mostly trust the endpoint. 3G IMS cell phones with SIM cards or PacketCable MTAs with manufacturers certificates that are bound to a particular cable HFC upstream and downsteam. You control who is allowed to connect to you and certify endpoints so interoperability problems are minimized.
An architecture where you're trying to provide true primary line service from generic IP devices. The MultiService Forum is an example of this one. It's stuffed full of session border controllers.
An architecture where you're not doing primary line telephony. In that environment, you don't have the availability or CALEA requirements so you can get by with lightweight authentication and a very thin core that's mostly SIP proxies and a database. More or less, this is the IETF reference model for VoIP. Usually, this is for a service that you give away for free or charge next to nothing. You can also build an IP PBX this way since everything sits behind the corporate firewall.
When you get advocates for all 3 kinds of architectures in a room together, they rarely agree on anything since their basic model of an end device and service are completely different.
re: Telecom Exec: VOIP Is a Painre: .17 > If Q.931 is out-of-band, then why not H.323 or SIP? After all the messages could be destined to a point different from where the media traffic is destined.
H.323 is derived from Q.931 (probably not a great choice but it was handy) but AFAIK it is usually used on an inband basis. I'm a bit baffled by your first phrase, though, "IF" Q.931 is out-of-band. When Q.931 was invented, the project was to develop an out-of-band signaling mechanism. That was never argued. It's like saying "if soup is wet".
> Will the signaling protocol of BISDN be an in-band? If not can you please explain?
Aren't we a bit late to discuss that? B-ISDN is a rather dead project. Will the 1999 Studebaker have an independent rear suspension?
Now when we talk VoIP (getting back on topic), there are as noted many variants. MGCP is, essentially, an out-of-band protocol. (Megaco/H.248 is a functional superset, PacketCable NCS a profile, so they're covered by these comments too.) I rather like it, actually, because it can be used in a clean, mixed-bearer (VoIP, VoATM, TDM, etc.) architecture where the Call Agent is nicely centralized.
But MGCP isn't really a subscriber signaling protocol like Q.931 (DSS1). It's a standard for doing neat stuff that isn't generally exposed in the legacy switch world. Not because TDM bearers can't stand it but because the legacy switch vendors wanted control. Two decades ago I was working on CIT (what we at DEC called what became CTI). It exposed some signaling capabilities to non-switch-vendor CPUs, quite different from Bellcore's IN2 (which exposed a different set of capabilities, for different purposes, though they never grokked the difference between CIT's "end user applications" and IN2's "carrier service creation"). MGCP essentially exposes the link between the marker and the crossbar -- digitized 1930s concepts. SIP digitizes the Strowger -- 1890s concepts. That's the nice thing about architecture -- you can see the old in the new. It helps when you don't want to reinvent wheels.
Having enjoyed taking a dig at me for not able to express according to "Wren grammer rules", it would have been also helpful if you had explained when does a protocol become in-band and when one is out-of-band. In my understanding (from the CCITT SG XI days) the chracteristic of out-of-band signaling is that the bearer and signaling travel different paths (logically, not necessarily physically). For people at that time this was in contrast to X.25.
Is this also your definition? If so, I still think H.323 and SIP are also out-of-band signaling schemes.
re: Telecom Exec: VOIP Is a PainAswath, I don't see why you need to get so catty -- I merely pointed out that Q.931 is undisputedly out of band.
H.323 is classically "NetMeeting" which is in band, communicating between two desktop PCs, and then between two Media Gateways. I hardly see out-of-bandedness about it. SS7 is way out of band, and Q.931 rides a separate TDM channel.
SIP is classically phone-to-phone VoIP, wherein there's an IP cloud enabling the phones to call each other. It is rather like H.323 minus the protocol crud. Sure, there are games with proxies and the like, but the pure protocol seems pretty inband to me. Of course that makes it hard for telephony service providers, since it is designed to disintermediate them. So there are proxies and gateways and all that jazz. But it's still based on an inband model. I don't think the IETF types know anything different.
"TDM can do GÇ£follow meGÇ¥, the cell guys have been dong it for years using TDM and SS-7.) And TDM could easily be modified to provide integrated messaging, computer screen web-based access to information, etc. The reason it has not been done yet is the dominant TDM providers can get as much money without doing it. Why serve the customer when you have a monopoly? "
While I find it interesting to read what COULD be done within a TDM structure, I prefer the reality of what is achievable within a VOIP structure with a little individual initiative.
One of the features that I have been playing around with is a virtual office "cube space" I for one miss the days when I could yell through the wall to one of the team members so that outstanding issues / misunderstandings can be resolved quickly and informally. I think they call it productivity...
Well with a VOIP system you or I can create this same experience, like a virtual party line. If you add voice command recognition and use this to enable automatic "dialing" than suddenly the spoken phrase "John have you got the details of that deal......" becomes a command John (look up John's IPaddress ) buffer voice string, send voice note, open channel to recieve John's reply.
I'll be the first to admit that what I'm doing is currently just a game for bored geeks, but I'll guarantee you that if we fix some of the kinks than I'll have a product long before you can even get the powerpoint slides finished for the telco project review. I think what is even more important is that I'll be able to address the whole world as a potential market, which will directly buy my product.
In the POTS system either the local Telco or some SI has to develop the product and than market it there are lots of up front expenses meaning lots of reasons to shoot holes in the business plan, furthermore this will probably only ever be a geek product so no telco will ever start the ball rolling meaning dead product!
As MG often says if you just focus on supplying a good quality pipe than the application layer will take care of itself and directly reward those with good ideas and good implementations. That's the VOIP value proposition.
optoslob