Issue in H.323 robustness not addressed by SCTP/DDP

Paul E. Jones paul.jones at ties.itu.ch
Thu Apr 27 02:46:40 EDT 2000


Qiaobing,

It sounds like DDP might serve most of the functions we need.  However, as
Archana has pointed out, an ACK is needed end to end for certain messages
and I believe an issue still exists with DDP.

Also, I was not proposing that endpoints have to share call state
information with other endpoints-- I have not been at all concerned with
checkpointing.  This might be quite valuable between alternate gatekeepers
(or other redundant entities), but I see this as a different issue to
"keeping a call alive".

Specifically, I see two issues we need to solve with robustness:
  1) Preventing the loss of a call-- even when a signaling point fails
  2) Preventing the loss of call billing information

(1) is my primary focus and I believe that (2) can either be considered as a
secondary issue or even an "implementation" issue.  Actually, V4 introduces
much of the information we need in order to bill for calls, as it can convey
the start/end time of a call in the DRQ.  If additional information is
necessary, the DRQ might be the logical place to put that to address (2).

(Personally, I'd be more than happy to have some call details lost--
especially after I got my last AT&T bill where I was billed at 80.6 cents
per minute to call from home to Canada on one of our conference calls.  I
thought I was going to fall over dead when I saw that bill!  And there was
no hope arguing with the AT&T customer service rep over it, either.  I
actually asked for a published list of rates so I can make sure I don't do
something like that again.  There is no published list, I was told!
Hmmm....)

Paul

----- Original Message -----
From: "Qiaobing Xie" <xieqb at CIG.MOT.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Wednesday, April 26, 2000 4:12 PM
Subject: Re: Issue in H.323 robustness not addressed by SCTP/DDP


> See my comments below...
>
> -Qiaobing
>
> "Paul E. Jones" wrote:
> >
> > Archana,
> >
> > The ACK packet certainly follows the line of thinking that I had.
However,
> > one issue with implementing this approach is that there are no fields in
> > H.323 to provide a "sequence number".  I suppose this could easily be
> > overcome.
> >
> > I want to change direction just a bit.  I have been pushing for Annex E,
but
> > I got resistance: people want to be able to use TCP or another
transport.  I
> > understand that desire.  People have also expressed concerns that we're
not
> > clearly separating the transport and application layers.  To some
extent,
> > that is true.  However, I believe that with Annex E, we can draw that
line a
> > little clear-- but it means modifications to Annex E.  Another issue is
that
> > some people have disagreed with modifying Annex E :-)
>
> I'd count myself as one of those disagreeing with modifying Annex E.
> With the proposed end-to-end ack and Annex E level keeping call state
> changes as we discussed in the last two robustness conf. calls, the line
> btw transport and application will be further blurred.
>
> > Here's a thought: how about introducing a new session layer between the
> > transport and below the H.323 application?  This session layer would
> > actually encode messages in a special format for transmission on the
wire.
> > For example, for TCP, we could modify the TPKT header and the payload to
> > carry not only the H.323 message, but also sequencing data and other
> > information.  We can allow fail-over addresses to be carried in this
layer
> > and allow this layer to completely handle connection recovery.
> >
> > When robustness is not available end-to-end, this layer in the middle
would
> > send and receive messages as normal.  However, when robustness is
available
> > end to end, it would "get in the middle" and transparently handle
robustness
> > issues for the H.323 application.
> >
> > The goal, of course, is to minimize the application changes and to
minimize
> > changes to the transports below.
>
> DDP is exactly a session layer protocol btw the transport and the
> application. It is designed to perform all the functions you just
> described and more. You get network level redundancy with SCTP replacing
> TCP (multi-homing and fast fail-over) and node level redundancy from DDP
> (transparent server pooling at GKs). All this can be achieved with
> little change to H.323 protocol. Randy Stewart and myself at Motorola
> are going to have a contribution to details this architecture at the
> coming Osaka SG16 meeting this May.
>
> >
> > Certainly, this is a shift from my previous thinking, but it represents
an
> > attempt to address all of the concerns people have raised.  What is your
> > opinion on this type of approach?
> >
> > 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



More information about the sg16-avd mailing list