Revised H.248 Annex M (Advanced Audio Server packages)

[Tom-PT Taylor]

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 at TECH-KNOW-WARE.COM]
Sent: Wednesday, November 08, 2000 4:54 AM
To: ITU-SG16 at 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 at tech-know-ware.com
+44 1473 635863
=============================================

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