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

ye.xiaoyang at zte.com.cn ye.xiaoyang at zte.com.cn
Tue Jan 7 21:55:49 EST 2014


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 at packetizer.com> 
2014-01-08 上午 08:44
请答复 给
"Paul E. Jones" <paulej at packetizer.com>


收件人
ye.xiaoyang at zte.com.cn
抄送
h325-design at lists.packetizer.com, 
h325-design-bounces at lists.packetizer.com, "sg16-avd at lists.packetizer.com" 
<sg16-avd at 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 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 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 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/3f2d9ab1/attachment-0002.html>


More information about the sg16-avd mailing list