Jim,
Hope you had a good Christmas break...
Comments below...
Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@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...