Hi,Paul,
I get it since an Application will be registered with a SN with its own URI  as you said.
 
BR, Xiaoyang



"Paul E. Jones" <paulej@packetizer.com>

2014-01-08 上午 08:44
请答复 给
"Paul E. Jones" <paulej@packetizer.com>
收件人
ye.xiaoyang@zte.com.cn
抄送
h325-design@lists.packetizer.com, h325-design-bounces@lists.packetizer.com, "sg16-avd@lists.packetizer.com" <sg16-avd@lists.packetizer.com>
主题
Re: [h325-design] Update on the work related to H.325 / AMS





Xiaoyang,
 
Hi,Paul,

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 SN,
 
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, key).
 
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@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 slide.
 
Indeed, that's a mistake.  I'll update the presentation to show communication between A1/A1 and A2/A2.
 
Paul
 
 


BR, Xiaoyang

h325-design-bounces@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@lists.
> packetizer.com mailing list.
>  
> Best regards and I wish everyone a happy new year!
> Paul E. Jones
> Rapporteur, ITU-T Q2/16
>