Remarks on H.450.x and H.225.0

[Pete Cordell]

Orit,

Sorry for the delay in this mail.

On your topic 4, I would be worried about adding another call model.  We
already have the direct model, VocalTec's model (I couldn't think of a
better way to describe it!) and the gatekeeper routed model.  Adding a
half gatekeeper routed model would further complicate things.
Efficiency is good, but in general I think that generality is better.
It's rare that you get a optimal general solution and I think that this
is a case in point.  I am also worried about bringing the other call
model back into play because I can't remember why we disallowed it.  I'm
sure it must have been for a good reason, and just because I can't
remember why doesn't mean the problem has gone away!!!

One reason for reducing the number of models is so that modelling the
way new features will act is much easier.

Another issue is that the FACILITY-UUIE method of re-directing calls is
already in use.  Adding the H245Address to the FACILITY-UUIE seems to
imply that the handling of the message should be different if you get
one with an H.245 address in (i.e. if there is an H.245 address in it
you simply connect using H.245 rather than the H.225 SETUP etc).  This
would produce backwards compatibility problems.  Even if it weren't a
backwards compatibility issue I think the simpler case of always using
the H.225 SETUP is a better way of going because the signalling is
simpler and cleaner.

I hope this helps,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Orit Levin[SMTP:orit at RADVISION.COM]
>Sent:  02 December 1997 21:18
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       FW: Remarks on H.450.x and H.225.0
>
>Dear Pete and all others !
>My additional comments are below:
>
>>3. H.225.0 Annex H - ASN.1
>>All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field.
>
>------------------------------------------------------------------------
>-------------
>We agree with Pete's proposal. It is more general but requires more
>changes in the standard. Let fix it one way or another, but till
>Geneva!
>------------------------------------------------------------------------
>-------------
>>
>>4. H.450.2 Clause 10.6.1.1
>>This clause is talking about Call Transferring in case of GK Call
>>Routed model and both Q.931 Signaling and H.245 protocol are "routed"
>>by the GK. According to H.323V.2 GK's Call Routed model where Q.931
>>Signaling is routed by the GK, but H.245 messages flow directly is
>>legal and more efficient. It seems that the clause above doesn't cover
>>this case. In order to provide a working solution for this case, an
>>additional OPTIOANAL field "h245Address" should be added to
>>Facility-UUIE message ...
>
>------------------------------------------------------------------------
>-------------
>Three things on this:
>Firstly, Pete, you are right about the "future study". Still this mode
>is more efficient and we shouldn't cancel it without serious
>considerations. In this case (of H.450.2) with this optional  field we
>could support it. Do we want  to cancel the possibility of using this
>mode without even studying it ?
>Secondly, the facility message, described in H.450.2 section, may
>contain Facility-UUIE as a part of it. Currently this Facility-UUIE is
>empty, but it can be used and have a new h245Address field.
>Thirdly, I will try to explain the relevant scenario using H.450.2
>terminology.  Suppose, A and B are in the GK routed call, while H.245
>and UDP streams flow directly between them. All "transferring logic" is
>performed by the GK on behalf of B. None of the mentioned messages
>(specifically CONNECT message) reaches B. Still, when the call is
>transferred from A to C, B has to receive (a new) H.245 address of C.
>The proposed way to receive it, is by means of  FACILITY message
>containing Facility-UUIE. Pay attention that B, who doesn't perform the
>"transferring logic" itself, upon arrival of the FACILITY message
>containing a new H.245 address, has to close the old H.245 channel and
>open a new one (towards C).
>------------------------------------------------------------------------
>-------------
>
>(I am starting to enjoy it, but I am serious.)
>
>>>Thanks,
>>
>>Orit Levin
>>RADVision Inc.                          E Mail: orit at radvision.com
>>575 Corporate Dr., Suite 420            Tel:    201-529-4300 ext. 230
>>Mahwah, NJ 07430                        Fax:    201-529-3516
>>
>