H.323 Mobility: New MTD's

[Edgar Martinez [1]]

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 at 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 at vocaltec.com
Boaz Michaely     boaz at vocaltec.com