Hi Ellen,

I am leading the Annex G implementation in VocalTec - working closely with Boaz Michaely who is the editor of H.225 Annex G. We think that your questions may be interesting to the mailing lists, so we are posting our answers. This will hopefully encourage further discussions - we need to decide whether we need a new version of AnnexG for the upcoming SG16 meeting in February.

---

From: SRD Zhang Xiao Sent: Tuesday, December 14, 1999 11:24 AM To: 'Boaz_Michaely@vocaltec.com' Subject: Some questions

Hi Boaz,

1. Cache mechanism. 1.7.1.2 Receiving Descriptors says using

DescriptorUpdate message to update the descriptor. 1.7.1.3 Receiving Response to Specific Queries says template can also be cached when using AccessRequest. The problem is: AcessRequest only caches partial descriptor, I mean some templates. When one template is updated, I can't assign the template with its desciptor, I don't know who's its desciptor, So I can't send DescriptorUpdate message to other BEs who cached this template. What can I do for this case?

There are two kinds of templates that can be maintained as part of a descriptor: (a) those that contain sendAccessRequest (b) those that contain sendSetup

Let's use Section 1.9.1 (Figures 9 and 10) as an example that illustrates how we understand the situation. (The same applies to the clearing house example in 1.9.2).

In the example, BE(A) sends an accessRequest to BE(B) and receives a template in the accessConfirmation. Presumably, this will be a type-(b) template (one that contains sendSetup). There is no overlap between this template and the templates contained in the list of descriptors (if there was, BE(A) would not have sent the accessRequest in the first place).

This response may be cached - in the example it is. It is correct that there is no mechanism to update this. It is the responsibility of the border element that issued the template to ensure that the template remains valid for the duration of the ttl.

2. 1.7.1.3 Receiving Response to Specific Queries describe a BE coupled

with the firewall. When an AccessRequest arrives, it shall respond two templates: one with a short lifetime owning Setup type, others with AccessRequest type for other AliasAddress. Could you give me a bit more detailed explanation about that?

This is a good question - maybe somebody (Glen?) can enlighten us?

3. I found something conflict in 1.9.2.1 Exchange of Zone Information.

In

Figure 14, why shall BED request BECH d1 and d2, BEE request BECH d3 and d4 ? I consider BED's capability is d1 and d2, BEE 's capability is d3 and d4, they're staticlly configured when initializing. Why need they send DescripotrRequest?

You're right - there seem to be a few mistakes in the table and the flow diagram in section 1.9.2. We would recommend (to the editor :-) to introduce the following corrections:

In the Table: - the template definition for Administrative Domain E should read "d3" and "d4"

In Figure 14: - the DescriptorRequests from BE(D) should be for "d3" and "d4" - the DescriptorRequests from BE(E) should be for "d1" and "d2"

In addition, the following editorial change should be made to Figures 8 and 14: - change "DescriptorIDReqConf" to "descriptorIDConfirmation" - change "DescriptorRequestConfirmation" to "descriptorConfirmation"

4. I aslo found some conflicts in 1.9.2.2 Placing a Call.In Figure

15,16,and 17, after initialization, BECH owns all Descriptors

information,

when resolving a telephone number, an AccessRequest to BECH can finish this procedure.Why need BECH send AccessRequest to BED,or BEE send AccessRequest to BED?

According to descriptor "d1", an accessRequest must be sent to BE(D) - regardless of who knows about "d1". Actually, in this example we think there is a different mistake. In this case, BE(E) would send an accessRequest directly to BE(D) and bypass the clearing house. We think the intent of the example was to show how the clearing house can control call setup (e.g., for billing purposes). To correct this, the clearing house would need to publish its own set of descriptors (which indicate that sendAccessRequest should always go back to itself).

===> Unless anyone disagrees, we will recommend that the editor change this too.

5. About AccessRequest definition. is AccessRequest->SourceInfo caller

info

or access requester info? Could you give me some explanation?

This is a good question. Annex G left this unspecified and clearly service providers will need to decide if they want to use this information and how. For example, the iNow! interdomain profile states that the SourceInfo should include the domainInfo and endpointType (presumably of the calling party). This works well in a distributed or full mesh configuration (section 1.5.2 of Annex G), but in the clearing house model, it is not specified what the clearing house should fill in for these fields in the accessRequest that it sends.

The iNow! interdomain profile may be found at:

ftp://ftp.imtc-files.org/imtc-site/inow-ag/iNOW_Interdomain_Profile_V2.1-AG -Approved.doc

6. Why need Annex G? RAS is good, why introduce Annex G?

RAS was not designed with interdomain communications in mind. For example, there is no discussion of how dialing plans or billing-related information can be transferred between domains. Annex G fills in many of these holes (for example, via AddressTemplates and UsageIndications).

We hope this helps.

Michael Fortinsky mike@vocaltec.com Boaz Michaely boaz@vocaltec.com