[sg16-avd] Upcoming Rapporteur meeting in Geneva (10-14 March 2014)
patrick.luthi at tandberg.com
Mon Jan 13 14:42:32 EST 2014
I get it since an Application will be registered with a SN with its own
URI as you said.
"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
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.
h325-design-bounces at lists.packetizer.com 写于 2014-01-07 上午 10:17:04:
> 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:
> 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...
More information about the sg16-avd