Paul,

I now see where your coming from. I was taking the view that the thing was broken and there consequently was not much to be backwards compatible with!!!

I think it should be a shall for V4 devices to extract and act on tunnelled information for all messages received. And I now believe it's worth recommending that they restrict sending tunnelled information to pre-V4 endpoints to SETUP, FACILITY, ALERTING and CONNECT. (Good point about FACILITY).

For v4 implementations that do not want to implement version specific behaviour (very sensible really) they can restrict sending tunnelled information to the designated messages all the time.

I agree that's still a bit ugly, but it is still one code fits all. As implementations get more mature the restrictions to use certain messages can be lifted.

Some revised text to what I have suggested earlier could go in the second paragraph of section 8.2.1:

Existing text: "When tunneling is active, one or more H.245 messages can be encapsulated in any Q.931 message ***. "

Insert text: "Consequently, if an entity implements H.245 tunneling, then it shall extract and act on the encapsulated H.245 messages in all received Q.931 messages (including those that it does not otherwise understand) irrespective of how it decides to handle the other elements in the Q.931 message. (To enhance interoperability entities communicating with pre-version 4 entities may restrict the sending of encapsulated information to the SETUP, FACILITY, ALERTING and CONNECT messages.)"

{Editor's note - I've made the latter part weak so that new implementers don't feel that they can rely on the tunnelling being used only in certain messages.}

Back to existing text: "If tunneling is being utilized and there is no need for transmission of a Q.931 message at the time an H.245 message must be transmitted, then a Facility message shall be sent with h323-message-body set to empty."

(BTW - it could be argued that *** above implies that tunnelled information can also be received in any Q.931 message. So maybe we are not as badly off on this subject as we previously thought we were. Even if this argument holds up I still think the extra clarifying text is worth adding.)

It would be nice if this could go in V4 and the implementers guide, but I feel time is against us. Maybe those people partying on down in Geneva can comment!!!!

Pete.

============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================

----- Original Message ----- From: Paul Long plong@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 08 November 2000 18:17 Subject: Re: fastStart element in all Q.931 messages up to and including Connect

Pete,

I didn't say that what you propose _couldn't_ be done, only that the Recommendation does not currently sanction this. We could add it as a requirement to v4, but this would break backwards compatibility because pre-v4 EPs would of course not know to process these fields. I suppose all EPs could henceforth contain pre-v4 and v4 behavior, e.g., whether to

tunnel

in optional messages, and just use one or the other based on the version

of

the remote EP. Talk about "ugly," though...

Paul Long ipDialog

-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, November 08, 2000 4:54 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: fastStart element in all Q.931 messages up toandincludingConnect

Not really. The various Q.931 messages still remain optional because tunnelling is optional. However, we can state that IFF you support tunnelling, THEN you must extract the tunnelling information even from

those

messages that you choose not to otherwise process. This breaks nothing

that

is said elsewhere in the standard. So the programmatic logic is something like:

switch( Q931 message type - octet 4 ish of message ) {

case SETUP:
    process setup; break;

case CONNCET:
    process connect; break;

case others:
    process ...; break;

default:
    // Not interested in these messages but must extract and handle
    // tunnelled stuff because I have decided to support tunnelling
    Find_UUIE();
    Extract_ASN1();
    Decode_ASN1();
    Process_tunnelled_H245_and_H450_etc();

}

Its also less demanding on EPs than mandating that they must process all

the

various messages. After all, the vast majority of EPs couldn't care less that a PROGRESS messages has been sent. So why should they have to delve into them in detail if they are not interested in their meaning and

content?

We should achieve what we want with the minimum of work load on the

various

software entities, and this is simpler than mandating understanding of the other messages without losing any of the desired functionality.

Pete.

============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com

+44 1473 635863

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com