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

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


Archana,

Putting the list of alternate signaling addresses, indicator that robustness
is supported, sequencing value, and the procedure to handle robustness
issues within the H.323 application is certainly easy to do.  The only
reason for separating the two is that people are increasing concerned with
the complexity of H.323.  Drawing a clear separation between the call
signaling layer, the robustness layer, and the application layer may make
some people feel more comfortable.


On the other hand, it sounds like you would much rather have that complexity
in the application layer.  This is certainly something we could do.  There
are also some advantages to this approach as well.  In particular, by
allowing the application to drive the robustness, we can failover from a
device that supports robustness to a device that does not.  (Of course, once
this fail-over occurs, we can't fail-over any more and there may be issues
with handling what appear to be duplicate messages in such cases, since the
sequencing value will be lost in such a switch-over in most cases.)

I would certainly not oppose this direction if others agreed with adding
this to the application layer.  As far as signaling goes, it's pretty
minimal, although actually re-establishing connections will involve more
work-- regardless of where that happens.  For example, if TCP is the
transport and a message is transmitted, the application layer must now
retain a copy of the transmitted message until an ACK is received.  Some may
prefer to move that into a separate layer, but I am really open to this--
I'll support it wherever we put it.

Paul

----- Original Message -----
From: "Archana Nehru" <archie at trillium.com>
To: "'Paul E. Jones'" <paul.jones at ties.itu.ch>; "Archana Nehru"
<archie at trillium.com>; <ITU-SG16 at mailbag.cps.intel.com>
Cc: "Mahesh Bhan" <mbhan at trillium.com>; "Chinmay Padhye"
<chinmay at trillium.com>; "Archana Nehru" <archie at trillium.com>; "Tim Chen"
<scc at trillium.com>; "Jill Caugherty" <jcaugher at cisco.com>; "Rich K. Bowen"
<rkbowen at cisco.com>
Sent: Wednesday, April 26, 2000 6:33 PM
Subject: RE: Issue in H.323 robustness not addressed by SCTP/DDP


> Paul,
>
> Thanks for replying. Please seem my comments below:
>
> -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.
>
>
> Well, if you are concerned about retransmissions, may be the endpoints
could
> just look at the "callId" in the ACK, look at the "session-state"  and
> conclude that the packet is just a retransmission.
> >
> >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.
>
> Well let me put it this way. What do we gain by doing this?. Wouldnot it
be
> simpler to modify H.323 procedures by introducing an ACK message itself
> (probably use some modified FACILITY?) and do it in a clean manner.
Anyway,
> all we need in H.323 is an  ACK from the peer, if the requester indicates
> that it needs an ACK. This could be decided as part of the connection set
up
> procedure itself..so an endpoint would know before hand  whether "a
> particular" node supports robustness or not. The message we decide to use
> will be optional and existing applications would just have to learn to
> ignore it, if they dont want to support robustness. That is not a big
> change..is it?..
>

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