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