T.120/H.323 Harmonization problems

Pat Galvin pgalvin at DataBeam.com
Tue Jan 6 16:05:43 EST 1998


Jim,

Hope you had a good Christmas break...

Comments below...

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================

[SNIP]
>>Firstly I'm worried about sending multiple call proceedings/alertings to
>>an endpoint.  Conceivably we could get the case that we receive a call
>>proceeding after alerting for example.  This is definitely not valid
>>Q.931.
>
>Firstly I would like to see _anyone_ indicate that what we do in H.323
>is
>valid Q.931.....
>We certainly borrowed a bunch of message formats, and some of the
>functionality, but I take my had off to anyone that has re-used an
>unmolested Q.931 stack :-)
Hopefully it should be Q.931 modified according to H.225.  Hence, unless
otherwise stated the order of messages should be as in Q.931.  (As Mr.
Interoperability you should probably shot somebody who has used an
unmolested stack!!!  However, a Q.931 stack is a good starting point.)
>
>[SNIP]
>>We could say that any endpoint that accepts fastStart should be
>>able to cope with this case, but this involves multiple modifications to
>>the Q.931/H.225 state machine which I feel is undesirable.
>
>A number of development engineers I have spoken with say this is a
>trivial
>issue, but as I said above I don't think it is a problem.
I guess it depends on your definition of trivial.  I would say it wasn't
difficult, but I certainly wouldn't say it was trivial.  I guess it
depends where you started from with your stack.
>
>>User
>>invitation and media establishment are in many respects orthogonal and
>>so making media negotiation conform to the invitation sequence is tying
>>one arm behind your back.
>
>Hmmm... I'm not sure how you know what media to send (from caller to
>callee) until an invitation has been accepted.  The media from callee
>back
>to caller will have the same universe of choices no matter who the
>callee is.
Hence the phrase "...in many respects...".  The media negotiation can
decide which caller to callee media to use IF an invitation is
eventually accepted.  If the invitation is not accepted, then, in theory
at least, an endpoint can be connected to some other node and a new
media negotiation process initiated, the result of which can be accepted
if the invitation is accepted.
>
>>What would be your comments if I suggested
>>moving the fastCaps stuff to the H323-UU-PDU field?
>
>A couple of things.  I assume you mean that you want to turn the two
>field
>definitions into complete messages themselves.  One problem is that
>this by
>definition increases the roundtrip times (thereby taking the 'fast' out
>of
>FastStart...) due to the fact that for Q.931 there can only be one
>message
>for each RFC1006 packet.  Another issue is that if they are separate
>messages  we run into complex and error prone issues with interactions
>of
>H.245.  This would seem to be creating a 'new' H.245 within H.225.0
No, H323-UU-PDU is the way we pick up nonStandardData and H.450 PDUs.
Except for the CHOICE members, anything in this SEQUENCE is common to
all messages.  Hence any message can make use of fields defined here.
>
>>This would allow us
>>to send the messages at any time (via FACILITY if necessary) without
>>affecting the Q.931 sequence and state.  This should be OK as this is
>>what is being used for supplementary services.
>
>I'm not entirely sure what you mean by this. Supplementary service
>messages
>are indeed piggybacked in Facility messages, but the two that are
>currently
>defined change both the media and call connection state.  If you're
>going
>to use Faciltiy messages to pass FastCaps at some 'later' time in the
>call
>sequence, I don't see how this saves any time over simply using H.245.
H.450 supplementary service messages can also ride in the SETUP message,
and indeed any other message you care to put them in.  As a note, none
of the supplementary service message directly affect the media and call
connection state, although messages that are issued as a result of
processing the H.450 messages will likely affect the media and
connection state.
To use the current H.245 method to open media I have to exchange an
H.245 address, do TCP sync, exchange caps, do MSD, and then OLC
signalling.  Hopefully any fast start scheme improves on that.
>
>> If this approach doesn't
>>work then we have a major problem, so any issues with it need to be
>>raised!!!
>>
>>I'm also thinking about how the gatekeeper will transfer the
>>capabilities through itself.  It will have to decode the messages (e.g.
>>setup) so that it can find the relevant information.
>
>I assume the GK is doing some fancy footwork in order to do endpoint
>'hunting'  in any case.
Even if the GK does not do any fancy footwork there is an issue.  See
below for example...
>
>>It may then have
>>to change some of the fields before passing the message on.  This will
>>mean re-encoding the message.  If there is a mis-match in the version of
>>Capability supported by the endpoint and the gatekeeper then capability
>>information will get lost in this process.
>
>Why is does the GK have any capabilities? It isn't a calleable
>entity...
>Gateways on the other hand will have to do this, but they have always
>been
>in the business of en/decoding the connection messages.
A gatekeeper doesn't have media capabilities, but, due to the way we
have coded the messages at the moment, it still has to be able to
interpret the capability description sent to it from an endpoint.  For
example, if the GK wants to change the h245Address in a SETUP message,
it first has to decode the message change the field, and then re-encode
it.  To decode the message it needs a definition of the H.245 Capability
field.  Hence, in many respects, it does have to know about
capabilities.
>
>
>>This means that endpoints
>>will not be able to achieve end-to-end negotiation of caps, and any new
>>codecs added by vendors will not be usable in this configuration.
>
>I fail to see where you draw this conclusion from.  You seem to want to
>put
>the GK in the middle of all of this, exert great control, and remain
>completely ignorant of any of the signalling that is occuring.   There
>is
>no reason why the endpoints can not exchange their FastCaps end to end
>unless the GK blocks them (as it can for any other exchange in the GK
>routed model).
Hopefully answered above.  (But.... I only want to exert SOME control(!)
and believe me it is far from ignorant of the signalling.  What I want
to do is remain TRANSPARENT to the latest features an endpoint supports
and not be in the situation that I have no option but to erase them.)
>
>>As I
>>envision faster evolution in the endpoint arena this seems a very real
>>proposition.  To get around this problem it may be best to include the
>>capability information as an OCTET STRING.  This allows the gatekeeper
>>to look at it,
>
>So which do you want, to have it be opaque to the GK or to have the GK
>be
>able to interpret it?
By making it an OCTET STRING the GK has the option to transparently pass
it on, analyze it (and even if it doesn't fully understand it) pass it
on, or change it.  If we keep it as it is the GK can not act
transparently.

[SNIP]

>>but also allows it to insert the information into an
>>outgoing message without having to have decoded it and re-encoded it
>>(i.e. it is just a copy operation) and so no information is lost.
>
>The GK can _always_ simply pass/copy the messages if it does not desire
>to
>provide some extended services during the call establishment (whatever
>they
>might be).
Hopefully answered above...



>
>



More information about the sg16-avd mailing list