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@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@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************