About APC-2014 and APC-2015

[SG Kim]

Paul,

I now see where your coming from.  I was taking the view that the thing was
broken and there consequently was not much to be backwards compatible
with!!!

I think it should be a shall for V4 devices to extract and act on tunnelled
information for all messages received.  And I now believe it's worth
recommending that they restrict sending tunnelled information to pre-V4
endpoints to SETUP, FACILITY, ALERTING and CONNECT.  (Good point about
FACILITY).

For v4 implementations that do not want to implement version specific
behaviour (very sensible really) they can restrict sending tunnelled
information to the designated messages all the time.

I agree that's still a bit ugly, but it is still one code fits all.  As
implementations get more mature the restrictions to use certain messages can
be lifted.

Some revised text to what I have suggested earlier could go in the second
paragraph of section 8.2.1:

Existing text:
"When tunneling is active, one or more H.245 messages can be encapsulated in
any Q.931 message ***. "

Insert text:
"Consequently, if an entity implements H.245 tunneling, then it shall
extract and act on the encapsulated H.245 messages in all received Q.931
messages (including those that it does not otherwise understand)
irrespective of how it decides to handle the other elements in the Q.931
message.  (To enhance interoperability entities communicating with
pre-version 4 entities may  restrict the sending of encapsulated information
to the SETUP, FACILITY, ALERTING and CONNECT messages.)"

{Editor's note - I've made the latter part weak so that new implementers
don't feel that they can rely on the tunnelling being used only in certain
messages.}

Back to existing text:
"If tunneling is being utilized and there is no need for transmission of a
Q.931 message at the time an H.245 message must be transmitted, then a
Facility message shall be sent with h323-message-body set to empty."

(BTW - it could be argued that *** above implies that tunnelled information
can also be received in any Q.931 message.  So maybe we are not as badly off
on this subject as we previously thought we were.  Even if this argument
holds up I still think the extra clarifying text is worth adding.)

It would be nice if this could go in V4 and the implementers guide, but I
feel time is against us.  Maybe those people partying on down in Geneva can
comment!!!!

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: 08 November 2000 18:17
Subject: Re: fastStart element in all Q.931 messages up to and including
Connect


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

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