I agree that you have found a problem with the current definition of the "sendTo" field.
There are actually two problems:
(1) "sendTo" is defined as an elementIdentifier, and there is no guarantee
that it is unique (this you mentioned)
(2) there is no guarantee that the border element that receives the "sendTo" within a usageSpec
will even understand it - an elementIdentifier is not defined to be a resolvable address;
it is just a string (it can contain a resolvable string, but currently the standard does
not enforce this)
Here is a simple example that illustrates problem (2).
Assume three border elements: BE(a), BE(b), and BE(CH) (CH=clearinghouse)
Each resides in a separate domain.
BE(a) sends an AccessRequest to BE(CH).
BE(CH) sends an AccessConfirmation, which tells BE(a) to route the call to a gatekeeper in domain b,
and which contains a usageSpec that has "sendTo" = "BE(b)".
BE(a) has no idea where "BE(b)" is (since BE(a) has never sent any messages to BE(a) before)
so BE(a) does not know where to send usageIndications.
So, I agree that something needs to be added to Annex G.
I think that if we add a "domainIdentifier" field (which is defined as an aliasAddress) to the usageSpec,
we can solve the problem. The new definition of the usageSpec will look like:
The domainIdentifier field will provide the following:
(a) an indication of which domain is to receive the usageIndications
(b) a resolvable address (either an explicit IP address, or something like a URL or email address that can
be resolved to one or more border element addresses within the target domain)
Any comments?
Michael Fortinsky
-----------------------------------------------------------------
Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd.
Email: mike@vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867
Archana Nehru <archie@TRILLIUM.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@mailbag.cps.intel.com>
07/25/00 01:30 AM
Please respond to Mailing list for parties associated with ITU-T Study Group 16
To: ITU-SG16@mailbag.cps.intel.com
cc:
Subject: H.225-Annex G clarification
hi everyone,
I need a clarification on the following issue for H.225 -Annex G used for
communication between two border elements(BE). I would appreciate any help
on this.
1. In the current Annex G specfications, border elements exchange
"usageIndication" messages with each other to inform each about "call
usages" etc for billing purposes. The
usage Indication message is sent according to a information element called
"usageSpecifcation". This element is exchanged in messages like
ACCESS_CONFIRM etc.
The ASN syntax defined for this "usageSpecification" is:
The "sendTo" field is supposed to identify the destination "border element"
to which the "usage indication" messages for a call must be sent. The issue
here is that "elementidentifier" is not defined as a "unique string", so the
"sendTo" field by itself cannot identify the destination BE of the
"usageIndication" message uniquely?
In other words, to send a usage indication message, a BE needs to know the
logical address of the "destination" BE. This logical address could then be
resolved to a transport address which in turn is used to send
"usageIndication" messages.
So dont we need to add suitable fields to the "usageSpecification" field to
identify the recipient of the "usageindication" message uniquely? If yes,
then we should add a "domainId"(this defines the domain within which the BE
resides) and also a "logical address" to the "usageSpecification" element.
Do we agree that this is required?
Regards
Archana
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com