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 ============================================= ----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 06 November 2000 13:37 Subject: Re: fastStart element in all Q.931 messages up to andincludingCon nect

Paul,

An additional consideration on this subject:

In order to have a working early H.245 tunnel, I would like to make CALL PROCeeding and PROGRESS messages as mandatory understood when received in v4. Otherwise, the user will be forced to use a FACILITY message along with these messages which will increase the used bandwidth.

Bob

-------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan@ICN.Siemens.com -----------------------------------------------------------------

-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, November 04, 2000 9:06 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: fastStart element in all Q.931 messages up to andincludingConnect

Bob,

[snip Annex F section ]

OK.. it seemed pretty clear that fastStart could be sent multiple times to reconfigure the streams.

...

I suppose the rule would be: if you're not a SET, ignore; if you are, react.

(As you know, I'd like to see every endpoint process the subsequent messages - then the SET wouldn't be so special, and the redirection problem would be solved.)

This might be ideal, but we can't even seem to come to an agreement on whether a single reply is required or multiple replies are required for fastStart. Worse, I believe people have implemented it differently, which makes the situation even more difficult.

(I assume you have been observing the "debate" on the H.323 Implementers list.)

Now, what was this about Fast Open again? :-)

Paul

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

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