Re: Pete Cordell's FastStart issues
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:
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.
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.
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
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.
I assume the GK is doing some fancy footwork in order to do endpoint 'hunting' in any case.
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.
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).
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.
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,
[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*** *************************************************************************
participants (1)
-
Jim Toga