Update draft of H.bmultipoint

Hidenobu Harasaki harasaki at CCM.CL.NEC.CO.JP
Tue Dec 9 08:49:05 EST 1997


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 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
> >>
> >



More information about the sg16-avd mailing list