I read an article yesterday titled AMS to the rescue, posted on VoiP Survivor. And to be honest, I was a bit shocked and puzzled. It talks about the Advanced Multimedia System which is currently being standardised by the ITU (in study group 16).
I was a bit shocked because the advances made by AMS (as described in the article) sounded like it would have a lot of overlap with the IP Multimedia System, which is being standardised for the last 8 years or so? Continuing to read the article I became a bit puzzled, since the article didn’t even mention the IMS, let alone making a comparision or describing their relationship. Furthermore, do we really need rescuing? Is this a signal from the ITU that we’re heading the wrong way with our current developments (e.g. the IMS)? This called for a little digging
Some facts on the Advanced Multimedia System:
- It was formerly referred to as H.325.
- The goal of the AMS project is to create a new multimedia terminal and systems architecture that supports distributed and media rich collaboration environments.
- Presently, the project is in the requirements-gathering phase and is starting to look at possible architectures.
- AMS envisions an environment in which a user has many AMS-enabled devices including portable wireless, home entertainment and computer-based devices and is offered many applications and services that are either peer-to-peer or network-provided.
- AMS is viewed as the successor system to the legacy H.323 and SIP systems.
The objectives of the AMS project are:
- Improve the end user experience
- Enable innovative applications
- Enable mobility
- Enable multimedia
- Make it easy to use
- Improve productivity
- Ease application and service development
Some example applications of the AMS:
- Traditional voice and video
- Whiteboard
- File transfer
- Application sharing
- Text messaging
- Video streaming (e.g., IPTV)
- Gaming
- Multi-user data conferencing
- Streaming audio (e.g., “IP radio”)
The AMS project envisions the following components:
- “container” - This is the device that represents the user to the network (e.g., a desk phone, mobile phone, or softphone application)
- Application Protocol Entities (APEs) - These are the applications that register with the container to provide the user with voice, video, and data collaboration capabilities
- Service Nodes (SNs) - These are the network entities that enable the container to establish communication with a remote entity, facilitate NAT/FW traversal, and provide other network-based services
- Application Servers (AS) - These are elements in the network that provide various services, which might include IPTV,
My n cents on AMS:
- The focus of the AMS is more at the edge of the network then one would suspect when reading things such as ’AMS is viewed as the successor system to legacy H.323 and SIP systems.
- A lot of goals of the AMS project are in line with the goals of the IMS, and IMHO seek to build on the efforts put in the standardisation of the IMS by 3GPP. The project description describes that liasons should be made with IETF, ETSI (TISPAN), 3GPP, 3GPP2 and the IMTC, and that it should draw on the work of OASIS, MPEG, IETF, ISO and IEEE. Lets just hope they do! There’s no point in starting all over again!
- A lot of goals and the vision of the AMS project are in line with the Ambient Networks project, an EU FP6 research program, perhaps the ITU can learn from that research.
- The project specifies a lot of Work Items, but NONE on accounting, charging or billing! This would IMHO mean a big gap in the research performed! Unless of course the ITU envisions a world without money or is getting communistic on us
- I wonder how this relates to DLNA? I’m not an expert on that technology, but I have a hunch that there is a relationship here as well!
For further information ake look at this project overview presentation (pdf) from Packetizer, it provides a nice overview of the project. Or check out the AMS project description (pdf).
Frens Jan Rumph
Posted by Frens Jan Rumph on May 23, 2008
Filed under Standardisation
Tagged with Ambient Networks, AMS, Architecture, H.232, H.325, IMS, ITU, SIP, VoiP
Leave a Reply
May 25th, 2008 at 5:28 pm
Frens makes some great comments. I would like to share a bit of my perspective.
First, I view a primary goal of AMS as creating an open and *simple* environment in which independent developers can create applications and services easily. And by independent developers, I mean that it should be possible to obtain an AMS terminal and connectivity service from a carrier, and then on my own write applications that leverage the terminal and it’s capabilities. This application development would require no coordination with the AMS transport provider. Of course, an application that did coordinate with the service provider may be able to acquire preferred service, but that is a network neutrality issue, not a technology issue.
It seems to me that the way to get real innovation and growth is not for service providers to determine their services and offer them. That model has given us the downloadable ringtone and the 10-cent text message. Rather, we should open the environment and be prepared to be surprised at what the community will bring. Phenomena such as YouTube and social networking developed from the ground up, not from a service-provider perspective.
That is why AMS is focused on the terminal or edge components. There is work going on now to develop the core network components as well. But I think those components will be minimal.
There is a clear requirement to maintain some control in the network for a variety of reasons. Service providers need to ensure that applications don’t overburden their networks. They need to ensure that applications don’t jeopardize security or operational policy. They need to comply with regulatory requirements such as wiretapping. And of course, they need to be able to account for usage in order to charge for their services.
I think an open environment like AMS will grow the market rapidly, because it leverages decentralized application development. How that complements IMS will have to be determined. The two are very different.
I know that at my own University we have deployed both H.323 and SIP. While these protocols work well for VoIP, we don’t see them as particularly extensible to next generation applications. From the perspective of a next-generation VoIP protocol I see AMS as evolutionary rather than evolutionary. That is to say, we can take what we’ve learned from H.323 and SIP and apply those lessons to the fundamental signaling and media processing environment. If we just wanted VoIP, we could probably stop now without ever developing AMS. But AMS is shooting for something much higher. It’s about applications.
I think Frens is right that there are intersections with DLNA and we have to be careful of that. Let’s leverage existing good work.
I’m not familiar with the Ambient Networks project. I’ll have to take a look at that.
May 25th, 2008 at 5:33 pm
Above I meant to say that I see AMS as evolutionary, not revolutionary, from a signaling perspective. It’s power is not in sending audio and video streams, but in how it opens up the environment.
May 26th, 2008 at 1:07 pm
@Tyler
Thanks for providing some further insight on the AMS. Some comments from my side in return:
1) How would this ‘open and *simple* environment’ differ from existing environments such as J2ME or the Android platform for that matter?
2) I completely agree with you that real service innovation usually does not come from tightly operator controlled environment.
3) Although I’m not a subject expert, I tend to disagree with the remark that SIP is not particularly extensible to next generation applications. Of course SIP is often referred to in combination with the SDP protocol, but as an application developer (using for instance an open Sip Servlet container such as Sailfin) already allows me to develop all sorts of applications. I would however need more then just SIP to create something such as a video game.
4) The decoupling of application and device however is probably more difficult with current standards and environments.
Frens - http://www.telcab.nl
May 27th, 2008 at 6:59 pm
Frens asks:
“How would this ‘open and *simple* environment’ differ from existing environments such as J2ME or the Android platform for that matter?”
Because AMS uses a decomposed terminal model. With J2ME or Android you are developing an application that runs on the phone. With AMS your applications don’t run on the phone. Well, some could, but they don’t have to. Applications might run on your PC, your car, your HDTV, your stereo, your home robot, or your home environmental control system. These applications become aware of each other and can interact through the AMS Application Interface.
May 28th, 2008 at 8:21 am
@Tyler
Indeed it is true that the most commonly used application model is ‘application runs on one physical node’. I could argue that it is not completaly imposible to mimic the caracteristics of AMS that you describe, using for instance J2ME, J2SE and bluetooth communication for instance. But an application environment that is specifically or explicitly geared for this task would be a great advance in ‘mobile’ computing. I’m getting a bit of Jini sensation here
I’m looking forward in the research done and the advances made by your group!
June 10th, 2008 at 2:52 am
[...] viewed as the successor system to the 12 year old legacy H.323 and ▲SIP systems, Frens Jan Rumph compared AMS and IMS in terms of charging and billing highlighting that IMS is a network designed to make money and AMS [...]