AVC-1798 and AVC-1799 - H.248 Annex F uploaded

[Gunnar Hellstrom]

Tim,

Do you not believe that by adding a sequence number to various H.245
messages will unnecessarily increase the complexity of the H.323
application?  If you look at what you have proposed, it puts a much heaver
burden on the application logic-- new timers, "re-tries" (possibly), etc.
The application will have to handle connection tear-down and
re-establishment-- and the procedure for re-establishment is not clear.

What happens if a routing entity in the network re-routes the call and now
there is no longer end-to-end robustness?  Do you care or do you just
continue thinking that such robustness is in place?

What about re-transmission of H.225.0 messages that might be used for
tunneling or performing some other type of service (e.g., Annex L services)?
Do those not also need acknowledgement?

Would it not be cleaner to have a separate layer between the application and
the transport to handle these issues?  I've suggested that before--
essentially, we could have a robustness wrapper around H.323 messages, which
isolates the application from the underlying complexity.  I realize that one
concern with such a "generic" approach is that there may be more messages on
the wire.  However, I believe we have to give somewhere and reach a
compromise between application complexity and signaling noise.

Of course, I say that and then you can immediate say that "we're only
requiring ACKs to a small set of messages", so the complexity is minimized.
That's true, but it does require additional state and timers, re-tries, and
connection re-establishment logic in the application layer.

Some were arguing for a "bulletin board" approach.  I missed the last
meeting, so I missed much of that discussion.  From the e-mail, I gather
that the intent is that for every message that arrives at a signaling point,
it will send that message to a peer before forwarding in on.  I need some of
the gaps filled in, but it seems like that scheme will result in no fewer
messages, but I can see some benefits, because the communication between the
two signaling points could done in such ways as to prevent "flooding" the
network with excess signaling-- there are several proprietary communication
mechanisms that can be employed for this task.

I don't know if the "bulletin board" approach is better or worse, but
hopefully we can try to cover all of these issues tomorrow.

BTW, thanks for writing this document-- this was very much needed as a
starting point for discussion.  I know that my e-mail doesn't seem to be
terribly friendly to the idea, but that was not my intent.  My e-mails are
often terse and it's getting late (or early?) ;-)

Paul

----- Original Message -----
From: "Tim Chen" <scc at trillium.com>
To: "'Mailing list for parties associated with ITU-T Study Group 16'"
<ITU-SG16 at mailbag.cps.intel.com>
Cc: "Chinmay Padhye" <chinmay at trillium.com>; "Srini Beereddy"
<srini at trillium.com>; "Mahesh Bhan" <mbhan at trillium.com>; "Archana Nehru"
<archie at trillium.com>; "Manoj Paul" <mpaul at trillium.com>; "'Paul E. Jones'"
<paul.jones at ties.itu.ch>
Sent: Monday, May 08, 2000 11:37 PM
Subject: [Robustness] End to End Acknowledgement Contribution


> Hi,
>
> Please find attached our write-up on end to end acknowledgement.
> As discussed in our last Robustness Group Conference Call,
> adding these acknowledgements at H.323 level to messages which
> invoke no responses will prevent call state mismatch should
> these messages be lost.
>
> We hope the group will give some response during Tuesday's conference
> call.  The list of messages that need to be acknowledged shown
> in the document is preliminary and we would welcome comments
> and suggestions.
>
> Regards,
> Tim Chen
>
> ------------------------------------------------------------
>   Tim Chen                    Trillium Digital Systems, Inc.
>   Phone: +1 310 442 9222      Fax:   +1 310 442 1162
>   email: tim at trillium.com     http://www.trillium.com
>
>

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