[sg16-avd] [h325-design] Update on the work related to H.325 / AMS

Paul E. Jones paulej at packetizer.com
Tue Jan 7 19:44:13 EST 2014


>This updated Overview is very helpful for me to understand the AMS 
>project. Thanks alot. I'v still two questions:
>Q1: Page 28,  Interface E (Container/Application to SN), but in the 
>figure of interfaces there is no direct line between Application and 

Applications would normally register with the Service Node.  So, the 
description is correct, but the diagram needs to be revised.  the 
challenge is that drawing so many lines gets messy very quickly.

>       Page 32 saies, a Container or application must register with a SN 
>before it can do anything,
>       My question is, if an application does not associate with any 
>Container can register with a SN? If yes, how does the SN manage and 
>identify such applications?

We have an existing requirement that says applications should be able to 
register to a Container directly.  This is OK for applications that do 
not send media (e.g., a flashing lamp to indicate to a deaf person that 
a call is incoming).  However, it's likely going to be very important 
for applications to register with a service node in order to do NAT/FW 
traversal properly.  We have procedures defined for that already, which 
requires a STUN server in the public Internet.  Following either the ICE 
procedures or the existing H.323 NAT/FW traversal approach (which is 
very predictable and efficient, I'll add), there would need to be a 
media proxy function in the public Internet.

The service node is something comparable to an H.323 GK or SIP 
registrar.  It handles registrations, balances registration load, 
resolves addresses, and forward messages from endpoints into the network 
and vice versa.  The applications will register with the service node 
using some credentials (e.g., username/password, signed credentials, 

The registration with a service node is entirely separate from two 
applications associating with each other.  And I think this gets to the 
point of your question.

Let's suppose you have an electronic whiteboard in a meeting room.  The 
whiteboard will be registered with a service node, perhaps with the URI 
"whiteboard at conf888.zte.com.cn".  If you wish to associate your mobile 
phone with the whiteboard, you could enter that URI into your phone.  It 
would then send a request to the whiteboard to associate.  The 
whiteboard might prompt you to accept the request, at which point the 
"engaged" message goes across the wire.  Now, you have the whiteboard as 
an application you can use in a call.  (It should also be possible to 
automate the associating using NFC, for example.)

>       BTW, the lines of Interface A/E/K are not easily distinguished 
>for the nearest color.

This is true.  I think as we write the specification, it might be best 
to use a solid color and break the diagram into parts so that no one 
part looks so confusing.  The model is actually fairly simple, but these 
diagrams make it look more complicated than it really is.

>Q2: Page 34, the last two steps in this flow, communication between the 
>applications might be A1 to A1, and A2 to A2?  I think it means the 
>same type applications with the same number just like in the next 

Indeed, that's a mistake.  I'll update the presentation to show 
communication between A1/A1 and A2/A2.


>BR, Xiaoyang
>h325-design-bounces at lists.packetizer.com 写于 2014-01-07 上午 10:17:04:
> > Folks,
> >
> > I have been asked by a number of people for an update on the
> > Advanced Multimedia System (AMS) / H.325.  The mailing lists have
> > been pretty quiet, but work is steadily progressing.  I was also
> > asked to refresh the AMS project page at the ITU.  I produced a
> > draft, but it still needs some work, as we're trying to present it
> > simply and concisely; I have a tendency for verbosity.
> >
> > However, an update was definitely in order since it has been several
> > years, in fact, since I updated my "overview" slides.  Since that
> > time, there has been a lot of progress in terms of defining the
> > message flows, the relationship between entities, and the signaling
> > syntax of the new system.
> >
> > The presentation is available in several formats, so please use
> > whichever format you prefer:
> > http://hive.packetizer.
> > com/users/packetizer/papers/h325/ams_overview_and_update.pptx
> > http://hive.packetizer.
> > com/users/packetizer/papers/h325/ams_overview_and_update.pdf
> > http://hive.packetizer.
> > com/users/packetizer/papers/h325/ams_overview_and_update.xps
> >
> > Feel free to direct questions to me or the the h325-design at lists.
> > packetizer.com mailing list.
> >
> > Best regards and I wish everyone a happy new year!
> > Paul E. Jones
> > Rapporteur, ITU-T Q2/16
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20140108/5af16cb1/attachment-0001.htm>

More information about the sg16-avd mailing list