fastStart element in all Q.931 messages up to andincludingConnect

[Pete Cordell]

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

----- Original Message -----
From: Callaghan, Robert <Robert.Callaghan at ICN.SIEMENS.COM>
To: <ITU-SG16 at 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 at ICN.Siemens.com
> -----------------------------------------------------------------
>
>  -----Original Message-----
> From:   Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent:   Saturday, November 04, 2000 9:06 PM
> To:     ITU-SG16 at 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 at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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