Re: Remarks on H.450.x and H.225.0
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:
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@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516
Dear Sir/Madam, First of all, if you don't have interest in this matter, please accept my apologies and just ignore this message. I would like to invite all of you to visit a Client/Server version of my 3rd prize winner (in the ACM Quest for Java'97) H.263 Video Decoder Entirely written in Java. The client applet can be found at http://www2.mcrlab.uottawa.ca/~jauvane/H263Decoder where I have a VideoServer that waits for clients. The clients can request videos and the Server send them to be shown in real-time. The applet allows the use of play/pause, Rewind, Quit and Slow Motion buttons to watch the video. The server uses a Sliding Window flow control algorithm, and I would like to receive, if possible, some feedback from you to make the fine tunning of the Sliding Window (I think It might be needed to increase the size of the window). The decoding is entirely done by the applet client in an 100% pure Java code. To see the applet running you must use a JDK 1.1 enabled browser. I strongly recoment Netscape 4.03 or 4.04 under WinNT or Win95, due to the good performance of their JIT compiler (It is possible to achieve up to 25fps in a PPro 200 [video grandma.263]). You will find a link to the Netscape JDK 1.1 patch at the same page above. I also received some positive feedback form MS Internet Explorer 4 users. Have a look at it and, please, send me some feedback. Best regards, ----------------------------------------------------------------------- _/ _/ _/ Jauvane Cavalcante de Oliveira _/ _/ _/ University of Ottawa _/ _/ _/ _/_/ School of Information Technology & Engineering _/ _/ _/ _/ Multimedia Communications Research Laboratory _/ _/ _/_/ _/ Phone:1(613)562-5800 Ext.6243/6248 FAX:562-5175 _/_/_/ _/ _/_/ Canada http://www2.mcrlab.uottawa.ca/~jauvane ----------------------------------------------------------------------- | Bolsista da CAPES - Brasilia/Brasil | -----------------------------------------------------------------------
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:
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@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516
participants (3)
-
Ami Amir -
Jauvane Cavalcante de Oliveira -
Pete Cordell