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 =============================================
----- Original Message ----- From: Paul Long plong@packetizer.com To: ITU-SG16@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@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@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