Hi Archana,

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:

UsageSpecification::= sequence { sendTo ElementIdentifier ..., sendToDomainIdentifier AliasAddress }

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:

UsageSpecification::= sequence { sendTo ElementIdentifier .... }

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