fastStart element in all Q.931 messages up toandincludingConnect

Pete Cordell pete at TECH-KNOW-WARE.COM
Wed Nov 8 05:53:34 EST 2000


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
=============================================

----- Original Message -----
From: Paul Long <plong at packetizer.com>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 07 November 2000 18:25
Subject: Re: fastStart element in all Q.931 messages up
toandincludingConnect


> Pete,
>
> H.225.0 says that it is optional for an EP to receive and act on these
messages. The message type is encoded in the _Q.931 header_ which has a
corresponding CHOICE in the ASN.1 h323-message-body type. I think you are
confusing the Q.931 message-type field with the ASN.1 CHOICE component. When
an EP encounters an optional Q.931 message which it does not support, it
will discard this message based on the Q.931 message type and not parse all
of the subsequent IEs including the User-User IE, which contains all of the
tunneling stuff we are talking about. IOW, the EP will not even see all of
the supposedly common fields to which you are referring.
>
> Paul Long
> ipDialog
>
>
>
>
> ---------- Original Message ----------------------------------
> From: Pete Cordell <pete at TECH-KNOW-WARE.COM>
> Reply-To: Mailing list for parties associated with ITU-T Study Group 16
> Date:         Tue, 7 Nov 2000 17:50:05 -0000
>
> >I mentioned this on the other list, but this is a different thread.
> >
> >As it happens it is not necessary for an EP to understand all Q.931
messages
> >that might contain tunnelled H.245, early or otherwise.  The tunnelled
H.245
> >is always in the same place for all messages.  All you have to do is find
> >the UUIE, extract the ASN.1, and chuck it to the ASN.1 decoder.  As the
> >H.245 (and H.450) are not in the message specific part of the ASN.1
> >structure it will be interpretable (sp!) in all cases*, even if SETUP
> >ACKNOWLEDGE and NOTIFY are sent.
> >
> >Therefore there is no need to make interpretation of CALL PROCEEDING and
> >PROGRESS in there entirety mandatory.
> >
> >Earlier I suggested the following text (slightly revised) should be added
to
> >the start of the tunnelling section to cover this:
> >
> >"If an entity implements H.245 tunnelling, then it shall extract and act
on
> >H.245 information contained in all received Q.931 messages (including
those
> >that it does not otherwise understand) irrespective of how it decides to
> >handle the other elements of the Q.931 message."
> >
> >Pete.
> >
> >* The ASN.1 does actually require to have knowledge of all messages types
up
> >to the ellipsis in h323-message-body, and up to the corresponding
ellipsis
> >in the sub-types.  However, once decoded it doesn't actually have to do
> >anything with these parts, which is the true burden of making them
> >mandatory.
> >
> >=============================================
> >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
>

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



More information about the sg16-avd mailing list