Hi Pete and Friends
A few points
1. Granted that the "semi indirect" routed model (H.245 direct and Q.931 indirect) was defered for further study - but this should not prclude this mode. There are obvious advantages (in large networks) for such a model. My recollection is that we never had the time or inclination to look seriously at this model.
2. H.323 seems to be too heavy for some applications (re- the IETF SIP effort) , and not rich enough for others. We are constantly hearing comments (e.g from chip manufacturers) that the code is too big, and from others (e.g. PBX manufacturers) that essential features are missing.
I am proposing that we schedule time - say 1 day - (either at Geneva or the folllowing Experts Group meeting) to discuss general directions for future work. This would require some preliminary papers and presentations from interested parties.
What is the Group's feeling about this?
Ami
Pete Cordell wrote:
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@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
From: Orit Levin[SMTP:orit@RADVISION.COM] Sent: 02 December 1997 21:18 To: ITU-SG16@MAILBAG.INTEL.COM Subject: FW: Remarks on H.450.x and H.225.0
Dear Pete and all others ! My additional comments are below:
- 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!
- 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@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext.
230
Mahwah, NJ 07430 Fax: 201-529-3516