Pete Cordell's FastStart issues

Jim Toga jtoga at ideal.jf.intel.com
Mon Dec 22 00:34:27 EST 1997


Pete,

After landing back in the office for more than one day straight, here are
my comments... sorry about the delay.

jimt.

At 04:22 PM 12/10/97 -0000, Pete Cordell wrote:
>Jim,
>
>You've definitely captured the core technical functionality required.  I
>was hoping to get you to appreciate the big picture behind the technical
>details so that you can understand why they are so important.  It's at
>this level we are perhaps not agreeing.  But still, maybe that doesn't
>matter so let's get on with looking for a technical solution.
>
>I note your comments below.  Although I don't entirely agree with them
>on all counts, one of the wonders of the English language is that
>different people can get different meanings from the same piece of text.
> So if we can agree that we understood different things from the text,
>we can move on...
>
>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 :-)

In any case, what I meant by passing changing/updated caps in Call
Proceeding/Alerting message was not to have them be shuffled in order.
Presumably the changes would occur during multiple Call Proceedings and
when the final destination was found, maybe then again in conjunction with
the  Alerting message.

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

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

>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

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

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

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


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

>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?  As new codecs are developed (as we all hope they
will be :-)   ) there are the same two choices for FastCaps as with the
standard H.245 negotiation mechanism.  The first is to get a specific
codepoint (and RTP payload format) defined for the codec.  The second
method is to use the nonStandardCap to signal it.  This might be used for a
specific vendor or a group of vendors by agreeement.


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

>I hope this moves us forward and not backwards!!!  I look forward to
>your comments,

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

[Remainder of this message is snipped]

*************************************************************************
***  +1-503-264-8816(voice)             +1-503-264-3485(fax)          ***
***  jtoga at ibeam.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
*************************************************************************



More information about the sg16-avd mailing list