I have been looking at the source and destination address information in
H.323 version 2, and am feeling a little confused.
Perhaps someone can point me to something that will clarify the position.
Version 1 had a number of addressing fields, for both the source and
destination. Version 2 extends that in a number of areas, both as
additional fields for what I'll call the primary address, but also as
sequences of source and destination alternatives. It also introduces the
Endpoint IE, which …
[View More]contains a number of OPTIONAL address structures.
Referring to the Endpoint first, I notice that it contains both an
aliasAddress, and a destinationInfo. The descriptions for these elements do
not seem convincingly right. If the Endpoint refers to a destination,
presumably both (this endpoint and destination) are the same.
I also notice that Endpoint does not contain the new element
remoteExtensionAddress which has been added, as destination address
information, to both ACF and SETUP messages. If this is the number to be
dialled from a remote gateway, may it not be different for different
destination gateways? I think it could be, and so should also appear in the
Endpoint IE. I think that it should be an optional element in the ARQ as
well, if the source endpoint knows this information.
I also see that remoteExtensionAddress is a SEQUENCE OF in the ACF, but
only a single AliasAddress in the SETUP message. Why?
I assume that alternateEndpoints, in the ACF message, are alternates to be
tried in the event that the endpoint specified in the dest* elements
(priority 0) is not successful.
It gets more difficult when I look at the ARQ message. Can someone please
tell me what is the intention of the srcAlternatives and destAlternatives
elements?
If the purpose of srcAlternatives, in ARQ, is to allow for an endpoint that
has multiple possible identities, shouldn't ACF specify which identity is
confirmed, and which alternative to use in the SETUP message? To include an
OPTIONAL sourceAddress Endpoint in the ACF, would also allow a gatekeeper
to override or add source address information for the call.
On the subject of where authorisation tokens between source and destination
could be included in call setup, has anything been discussed or decided? By
that I mean a token of some kind, generated by the source gatekeeper and to
be relayed through the setup process to the destination gatekeeper, as
input to the destination admission determination.
Regards,
Douglas
[View Less]
Dear Q.11-14/16 experts,
Mr. Harasaki wrote:
>I have put a delayed contribution to September SG16 meeting as
>ftp://standard.pictel.com/avc-site/Incoming/Delayed_H323_ISDN.zip
This document has been moved to
ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/Delayed_H323_ISDN.zip
with the following two delayed contributions:
ATT_nh_gkx2.zip from Mr. Roy
H323_Annex_E.zip from Mr. Gurle
(I hope my understanding is correct that this is a delayed
contribution)
Best regards,
Sakae …
[View More]OKUBO (Mr.)
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
[View Less]
There will be another conference call to discuss H.225.0 Annex G:
date: 27 August (Thursday)
time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc)
bridge number: +1 630-224-4444
code: 911202
duration: 1 hour
Tentative agenda:
- next call 4 September (Friday)? more than 1 hour?
- closure on Santo Wiryaman's proposal
- review of Pete Cordell's proposal
- review of Radhika Roy's proposal
Attendees on last call:
(I'm …
[View More]sorry if I didn't get your name on the list. Please email me after
a call so that I can build a roster.)
Kaynam Hedayat - PictureTel
Kerwin Yuu - PictureTel
Markku Korpi - Siemens
Pete Cordell - BT
Radhika Roy - AT&T
Hal Purdy - AT&T
Jim Toga - Intel
Dieter Rencken - Siemens
Chris Purvis - Madge Networks
Andrew Draper - Madge Networks
Michele Bozier - Madge Networks
Santo Wiryaman - VideoServer
Sree Peyyety - ITXC
Glen Freundlich - Lucent
Notes from last call:
We spent about 40 minutes discussing Santo Wiryaman's document. The
proposal for an addressing hierarchy seems to help scaling, however
there are concerns about roaming, portability, and applicability to
private networks. There are concerns about defining a numbering or
addressing plan, which include political issues as well as technical.
However, we probably need some way to assure that an alias is unique. We
could leave definition of the address space to bodies such as Tiphon.
Annex G might specify that support for E.164 addressing is required,
email addresses optional. Annex G or H.225 should stress that email
addresses should use the email alias address, not the h323-id. There is
also some concern about signaling through the domains in the hierarchy
(e.g., going through domains B and C when domain A attempts to signal
domain D) - whether this is efficient, what happens when a node is out
of service, whether this makes sense in packet networks, and what the
net benefit is.
This led into a discussion of some of the points in Radhika Roy's
proposal. It is difficult for a GK to control transport level QoS since
a GK does not know about other (non-H.323) traffic on the network, and
media may take a different path than the signaling between GKs.
For those who were on the last call, please correct me if I've missed
something.
Glen
--
Glen Freundlich ggf(a)lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos fax: +1 303 538 3907
Westminster, Colorado 80234 USA
[View Less]
I'm forwarding this for Andy Woollett.
Hi All,
At Andy's request I have posted VRDCrevA.doc and TRDCrevB.doc,
they are at ftp://ftp.imtc-files.org/imtc-site/T120-top/geneva98-2/
Chuck
------- Forwarded Message Follows -------
From: Andy Woollett <a_woollett(a)imagecom.co.uk>
To: Chuck Grandgent <k1om(a)world.std.com>
Subject: V.RDC and T.RDC Draft Documents
Date sent: Mon, 24 Aug 1998 15:54:21 +0100
Hi Chuck,
Could you …
[View More]please place these documents into the Geneva98-2 directory at
the IMTC site directory
and then forward the following message to the Q3 and Q14 reflectors.
Thanks
Andy Woollett
---------------------------------------------
All:
The following draft documents have been placed in the Geneva98-2
directory at the IMTC site.
/pub/imtc-site/T.120-top/Geneva98-2/VRDCrevA.doc
/pub/imtc-site/T.120-top/Geneva98-2/TRDCrevB.doc
VRDCrevA - Remote Device Control Protocol for Multimedia Applications
(Q3/16, Q14/16)
TRDCrevB - Remote Device Control Application Protocol (Q3/16)
It is anticipated that these documents will be submitted for
determination at the Geneva SG16 meeting in September. A list of the
main changes is on page 2 of each document. Further work is in progress
updating the ASN.1 in VRDCrevA.doc. Please could interested parties
review these documents and send any questions or comments to me at
a_woollett(a)imagecom.co.uk.
Thanks
Andy Woollett
ImageCom Ltd
[View Less]
Dear Q.11-14 Experts,
I have put a delayed contribution to September SG16 meeting as
ftp://standard.pictel.com/avc-site/Incoming/Delayed_H323_ISDN.zip.
The title is "Comments on the projected Annex/Appendix for H.323 over N-ISDN".
The contribution is prepared to discuss interworking of the projected
H.323/I terminal with other type of terminals, comparing with a similar
case of Annex C to H.323 (H.323 over ATM). It provides some analysis
for possible interworking combinations with respect …
[View More]to audiovisual
transport and suggests some directions to facilitate the conclusion of
this topic.
I will submit this contribution to ITU-T in a few days.
Best regards,
Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp
Manager, Research C&C Media Research Labs., NEC Corporation
Phone: +81 44 856 8083 Fax: +81 44 856 2232
[View Less]
Some follow-on comments inserted below :
> >simplest ways to do it was that the roaming terminal would send the ARQ,
> >...
> >to the visited network GK (discovered my broadcast/multicast). This GK
> would
>
> If you are visiting another IP network, are you asking the GK for more
> than
> bandwidth and address resolution (absent BES-based AR).
--- Yes, for instance if I dial an E164 number, or if I use a high level of
QoS, I will be billed, probably based on …
[View More]the GK info. Maybe I also have a
set of short numbers programmed in your home GK, and you would like to use
them ...
> >recognize from the calling party alias that the terminal si from an
> external
> >administation having an agreement with the visited administration.
> >It would then forward the xRQs to the home gatekeeper of the terminal and
> >get the xCFs in reply.
>
> This proposition requires the calling party alias to identify the "home"
> administration, and the gatekeeper to be able to resolve the "home"
> gatekeeper.
--- Yes, this would be based on the domain name of an email alias. When
completing a roaming agrement, each party would pass the other party a list
of domains to include in the agreement. That could be *.francetelecom.fr,
*.myprefferredcustomer.com, ...
Then to identify the GK, the usual DNS TXT record lookup could be used, or
the parties in agreement could also store some IP addresses.
The home GK can find who is the visited domain GK from a token inserted in
the relayed xRQs, or another comvention such as name mangling (source alias
toto(a)francetelecom.com modified as
toto(a)francetelecom.com!deutschetelecom.com )
This doesn't have to be standardized, it is just added value programming on
top of the GK.
> >This has many benefits :
> >- The home GK knows where is the roaming teminal and can forward calls.
> >- Any policy implemented at the home gatekeeper (restricted phone usage,
> etc
> >...) is still enforced in any visited domain
>
> So, bandwidth restrictions in the home zone would be enforced in a visited
> zone?.
--- Yes, and many more services. for instance you could be using a
prepaid account that allows only to call some numbers (your company ...).
This restriction would be enforced as well in the visited domain.
Of course the visited domain can also enforce its own policy,
because it relays the xCFs. For instance if the home GK allow to call a
premium rate number, but the local policy does not allow this, then the
visited GK would simply change the ACF into an ARJ.
> >- It is simple
>
> I think we should be looking at Back-End Services, at least so we know
> what
> to expect of them, and don't make GK-GK break later, or make GK-BES
> difficult/impossible.
--- We are looking into this. So far the main restriction we see in existing
toolkits for this type of GK/GK services is that they are sometimes unable
to initiate RAS/Q931 messages (no API to send an xRQ). Hopefully this will
be improved in future versions.
We plan to bring this work to ITU/ETSI as soon as we have something that
seems flexible enough to build most services.
> >So roaming might be a good reason to forward xRQs ... just my FF.02.
> >
> > Best regards,
> >
> > Olivier HERSENT
> >
> >--
> >France Telecom CNET
> >IP Telephony Technical Proj. Manager - TULIP
>
>
[View Less]
From: David Gurle@VOCALTEC on 08/22/98 03:46 PM
Dear All,
You can find the latest version (3.3) of the H.323 version 3 annex E at the
following directory:
ftp://standards.pictel.com/avc-site/Incoming/H.323%20Annex%20E.zip
Good reading and Best regards
David.
David Gurle
Mobile: +972 53 870 464
ISDN: +972 99 525 802
Fax: +972 99 561 867
1 Maskit street
Herzeliya, 46733 Israel
mailto:david_gurle@vocaltec.com
My comments below.
vineet
> -----Original Message-----
> From: WanJiun Liao [SMTP:wjliao@EEE.HKU.HK]
> Sent: Thursday, August 20, 1998 9:13 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Q. about master/slave determination in H.245
>
> Hi..
> I have some questions about master/slave determination in H.245.
> Perhpas these questions are stupid... but could you please kindly give me
> some help?
>
> With H.245, we need to do master/slave …
[View More]determination to resolve
> conflicts between two endpoints which can be the MC in a conference.
>
> (1) If there is no MC is active and all entities are of different types,
> the priority to win the master/slave determination is MCU > Gatkeeper >
> Gateway > terminal. THis means. e.g., with Gatekeeper and terminal,
> Gatekeeper always wins the determination? then why bothering to
> set "statusDeterminationNumber" to be a random no. in that certain range?
[Kumar, Vineet] At the time of master/slave determination, the
entities do not know the "terminalType" of each other.
> or only when those entities are all in the same type, then such setting
> just makes sense? i.e., "terminalType" overrules
> "statusDeterminationNumber" ??
>
> (2) An MC that is already acting as an MC shall always remian the active
> MC. However, assume that there are only terminals participating in a
> conference, what if a terminal that won the determination already
> decides to leave the conference at some time during the call? Should we
> need to perform such master/slave determination again?, or the terminal
> can assign the other to be an active MC?, or the terminal by no means can
> not leave the conference in the middle of the call?
[Kumar, Vineet] It is assumed that the MC will not leave the
conference. It is does, then the conference ends.
> Please advise... thanks a lot..
>
> Best regards,
>
> Wanjiun Liao
[View Less]
> The problem is the the visited GK might (and probably) control firewalls
> and other QoS and security devices. Therefore it needs to know what my
> terminal is doing, and may disagree with the replies of my home GK.
If the visited network is behind a firewall then the
register-directly-with-home-gatekeeper model can be made to work without
protocol changes. There are two cases to consider:
If the policy of the visited networks is to not allow roaming endpoints to
connect to their …
[View More]home system then it doesn't matter whether this policy is
enforced by the gatekeeper or firewall. Thus the register-directly- model is
valid.
If the visited network would like to allow roaming endpoints to connect to their
home gatekeeper in order to make calls then this can be handled by using IP
masquerading techniques on the firewall. This doesn't require any changes to
the protocol.
IP masquerading is implemented by application proxy or stateful inspection type
firewalls and is a means of passing a complex protocol containing embedded
addresses between two disconnected IP networks. NAT (network address
translation) uses a similar technique. The basic mechanism is that since all
traffic between an organisation and the internet passes through their firewall
the firewall can intercept any packets it wants to and modify them as necessary
(most firewalls are configured to block any packets which have not been
intercepted and inspected).
A masquerading H.323 proxy (running on the firewall) contains gatekeeper like
functionality which intercepts, decodes and validates H.323 packets passing
through it. This proxy needs to keep a list of which roaming endpoints are
within the network it is protecting so that it can pass call setups on to them
from their home gatekeepers. The proxy is invisible to roaming endpoints within
the firewall because it pretends to be the home agent they are communicating
with.
Since the masquerading H.323 proxy has intercepted all traffic going out of the
network it can impose QoS requirements on calls by roaming endpoints as easily
as the administrative domain's gatekeeper can for local endpoints.
Alternatively the lower layer QoS management could be used to do it.
I suppose you could claim that a masquerading H.323 proxy is the same as
registering with the visited gatekeeper in terms of which messages flow where.
It differs in two important ways: 1) it requires no changes to the format of
messages and 2) the roaming user does not need to configure or discover the
visited gatekeeper (particularly important if the visited network doesn't
support multicast).
> Also for security reasons my home GK may be restricted to receiving xRQs
> from the local zone and from specific GKs, and may reject xRQs sent from
> the open internet.
If my home gatekeeper is restricted to receiving xRQs from the local zone then
why will it respond to those messages when they come from a foreign gatekeeper?
Surely a reasonable gatekeeper will only accept RAS messages from
endpoints/gatekeepers which are either on a physical network which it trusts or
which have provided some sort of strong authentication.
Regards,
Andy.
--
Andrew Draper - Principal Development Engineer - WAVE Software
Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.
mailto:adraper@dev.madge.com phone:+44 1753 661329
pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F
[View Less]