Remarks on H.450.x and H.225.0

Tue Dec 9 12:42:58 EST 1997

Ami,

I fully agree with you.  I saw nothing that could not be done using
H.224.0 and H.450.  However, I do agree that this does not align with
"lite".

The trade-off between "rich and fully featured" and "lite" is very
important.  An open discussion might lead to an understanding.

Bob

--------------------------------------
Robert Callaghan
Siemens Business Communication Systems
Email:  Robert.Callaghan at Siemenscom.com
Tel:    +1.561.997.3756

>-----Original Message-----
>From:  Ami Amir [SMTP:amir at RADVISION.RAD.CO.IL]
>Sent:  Tuesday, December 09, 1997 4:42 AM
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Remarks on H.450.x and H.225.0
>
>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
>> >>
>> >