<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: AMS to the rescue</title>
	<atom:link href="http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/</link>
	<description>IMS &#38; V²oIP industry insights</description>
	<pubDate>Thu, 20 Nov 2008 10:50:30 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Paul E. Jones</title>
		<link>http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/#comment-119</link>
		<dc:creator>Paul E. Jones</dc:creator>
		<pubDate>Sun, 25 May 2008 00:27:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/#comment-119</guid>
		<description>It has now been more than 12 years since "SIP Happened" and SIP still has not really happened.  IMS, for the most part, tries to formalize the usage of SIP so as to enable carriers to use the SIP protocol within their networks.  In reality, many carriers just create solutions of their own design and/or use various SIP profile documents created by various standards bodies around the world.  Most importantly, though, is that, with the exception of video, there has not been a substantial change in the way users communicate.

Given that it has been so many years since work started on SIP and H.323 in 1995, the folks working on multimedia systems decided that it was about time to look to the future at what the next major communication system would look like.

With the new H.325 system (aka, “Advanced Multimedia System”), it was decided to focus on the user experience.  We want to enable users to use a variety of applications and a plurality of devices all within the context of a "call".  Most importantly, we want to create open interfaces that enable any application developer to create an application (e.g., voice, app sharing, a video game, a flashing lamp, or anything one might imagine) that and AMS user could then use.  While the "voice app" is likely to be available with every AMS terminal device, it does not have to be.  In fact, voice is just another application like any other.  With this decomposed architecture that enables direct application-to-application communication, it would not be necessary to spend years trying to figure out how to get IM working or more years trying to figure out how to get the next application working.  AMS is all about "applications" and will be designed to enable any kind of application to work through a consistent set of interfaces without the need to upgrade user or network components.

The user-centered design view and "openness" that we want to enable through AMS is the most significant difference between AMS and legacy systems like SIP and H.323.</description>
		<content:encoded><![CDATA[<p>It has now been more than 12 years since &#8220;SIP Happened&#8221; and SIP still has not really happened.  IMS, for the most part, tries to formalize the usage of SIP so as to enable carriers to use the SIP protocol within their networks.  In reality, many carriers just create solutions of their own design and/or use various SIP profile documents created by various standards bodies around the world.  Most importantly, though, is that, with the exception of video, there has not been a substantial change in the way users communicate.</p>
<p>Given that it has been so many years since work started on SIP and H.323 in 1995, the folks working on multimedia systems decided that it was about time to look to the future at what the next major communication system would look like.</p>
<p>With the new H.325 system (aka, “Advanced Multimedia System”), it was decided to focus on the user experience.  We want to enable users to use a variety of applications and a plurality of devices all within the context of a &#8220;call&#8221;.  Most importantly, we want to create open interfaces that enable any application developer to create an application (e.g., voice, app sharing, a video game, a flashing lamp, or anything one might imagine) that and AMS user could then use.  While the &#8220;voice app&#8221; is likely to be available with every AMS terminal device, it does not have to be.  In fact, voice is just another application like any other.  With this decomposed architecture that enables direct application-to-application communication, it would not be necessary to spend years trying to figure out how to get IM working or more years trying to figure out how to get the next application working.  AMS is all about &#8220;applications&#8221; and will be designed to enable any kind of application to work through a consistent set of interfaces without the need to upgrade user or network components.</p>
<p>The user-centered design view and &#8220;openness&#8221; that we want to enable through AMS is the most significant difference between AMS and legacy systems like SIP and H.323.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AMS to the rescue? : TelCAB</title>
		<link>http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/#comment-110</link>
		<dc:creator>AMS to the rescue? : TelCAB</dc:creator>
		<pubDate>Fri, 23 May 2008 07:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://blog.radvision.com/voipsurvivor/2008/05/22/ams-to-the-rescue/#comment-110</guid>
		<description>[...] 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 [...]</description>
		<content:encoded><![CDATA[<p>[...] 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 [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
