Test

[Theresa Mackenhauer]

Boaz,

I do consistently argue against closing the call signaling channel.  But
there are good reasons for this:
1) Many devices out there clear the call when the channel is closed (yes,
this is wrong, but it's a fact of life :-)
2) Closing the call signaling channel prohibits (or complicates) the use of
supplementary services and other in-band signaling.

The text to which Chris Purvis refers is section 6.1.  Here is an extraction
of that text:
``For the gatekeeper mediated call signalling case (see Figure 8/H.323), the
terminals shall keep the reliable port active throughout the call. However,
the gatekeeper may choose to close this signalling channel, but should keep
the channel open for calls that involve gateways. This will allow the
end-to-end transmission of Q.931 information elements such as display
information.''

What you propose below is interesting and may yield a more scalable
solution.  Perhaps this should be explored.  I might note, though, that at
the moment, such a configuration is "undefined".  According to H.323,
routing the call signaling through a Gatekeeper, but not the H.245, is "for
further study".  It might be interesting to read contributions from you that
might open this area for study.

Best Regards,
Paul

----- Original Message -----
From: "Boaz Michaely" <Boaz_Michaely at vocaltec.com>
To: "Paul E. Jones" <paul.jones at ties.itu.int>
Cc: <h323implementors at imtc.org>; <itu-sg16 at mailbag.cps.intel.com>
Sent: Thursday, December 30, 1999 7:40 PM
Subject: Re: Closing Q.931 TCP connection..


> Happy new Y2K !
> Your consistent argueing against closing the Q.931 sig. channel, is
> appreciable, and I share your concern for many service scenarios. (I guess
> we'll talk more about this in February, which is why the ITU-SG16 list is
> copied)
> However, in the following scenario, it seems highly desireable to be able
> to close the sig. channel:
> (if this has been described before, please forgive my ignorance)
>
> Think of a scaleable IVR server farm which is implemented using multiple
> MG's, each capable of H.245, RTP/RTCP, and a very simple control protocol
> (H.248 ?). A single GRC GK, which is also an AnnexG Border Element is used
> as the single entry into this port-dense system.
> This GK may be addressed using LRQ from another domain (e.g. that of an
> ITSP). In addition, it publishes its own address using "SendSetup" type of
> addressing in the AnnexG templates that it publishes.
>
> Once a SETUP message comes in, the GK replies with an H.245 address of the
> applicable MG. Note that the GK has to be the point of call for SETUP,
> since it may use the information in the SETUP message for finding the
> applicable MG
> (i.e. using CLI and/or DNIS), as well as it performs load balancing on the
> MGs.
> Now the audio session is connected and the call takes place, while the MG
> handles the DTMFs and all the logic.
> Let's assume that there are no changes in the call routing from this point
> on (which is typically the case in, say, automatic banking systems etc.)
> GK intervention is not required any more until the call is done.
>
> It would be nice if the GK could get rid of the dangling Q.931 TCP
> connection, while the RTP call continues until it is disconnected by the
> human caller. If I understand correctly, this is a perfectly legitimate
> behaviour using the existing standard. (I trust this is true for all
> versions ?)
>
> Assuming this scenario is valid (have I overlooked anything ?) can we find
> a way to continue to support it while reducing the mess for other services
> ?
> Reinitiating the sig. channel in some way may not be a bad idea ?
>
> Finally, I must admit I do not understand Chris's comment about making
sure
> the other party is not a GW.
> Why is that so?
>
>
> Boaz Michaely
> VocalTec Communications Ltd.
> +972 (9) 970-7869
> email: boaz at vocaltec.com
> http://people.itu.int/~michaely
>
>
>
>
>
>
> "Paul E. Jones" <paul.jones at ties.itu.int> on 02/01/2000 12:04:50 AM
>
> Please respond to "Paul E. Jones" <paul.jones at ties.itu.int>
>
> To:   "Chris Wayman Purvis" <cwp at isdn-comms.co.uk>, "Satya T"
>       <satyat at MIEL.MOT.COM>
> cc:   h323implementors at imtc.org (bcc: Boaz Michaely)
> Subject:  Re: Closing Q.931 TCP connection..
>
>
>
>
> Folks,
>
> I would like to second Chris' comments.  It really is a very bad idea to
> close the call signaling channel.  This might have been important prior to
> H.245 tunneling and Fast Connect, but in my opinion, this just isn't
> necessary any longer.
>
> My chief complaint is that once the channel is closed, there's no
guarantee
> one can re-open it.  This is especially true on the receiving end-- the
> called endpoint may not know the call signaling address to which to try to
> re-establish a socket connection, and it cannot assume 1720.  Reverse call
> setup may not even be possible, given some network arrangements (including
> the usage of devices to traverse firewalls).
>
> There are several reasons to keep the channel open, too.  This gives the
> endpoint the ability to perform supplementary services.  If the channel is
> closed, the endpoints lose that functionality-- unless we can guarantee a
> way of re-establishing that channel.
>
> So, my advise to all implementers: never, never close the call signaling
> channel.
>
> Paul
>
> ----- Original Message -----
> From: "Chris Wayman Purvis" <cwp at isdn-comms.co.uk>
> To: "Satya T" <satyat at MIEL.MOT.COM>
> Cc: <h323implementors at imtc.org>
> Sent: Tuesday, December 21, 1999 8:52 AM
> Subject: Re: Closing Q.931 TCP connection..
>
>
> > Satya,
> >
> > This is the subject of much current discussion, but the group within ITU
> SG16
> > discussing robustness.  Currently:
> > ReleaseComplete closes the call.
> > Closing the Q.931 TCP connection without ReleaseComplete does not close
> the
> > call if there is a separate active H.245 connection.
> > However, consideration is being given to the possibility of changing
this
> rule,
> > if no implementations can be found that deliberately close the Q.931 TCP
> > connection during a call.
> >
> > I strongly advise against deliberately closing the Q.931 TCP connection
> without
> > terminating the call, but as things currently stand
> > a) you are permitted do so as long as there is no gateway involved in
the
> call
> > (which you may or may not be able to know!!!)
> > b) you should cope with other parties in the call doing this (unless you
> or
> > they are a gateway!!!!!).
> >
> > Regards,
> > Chris
> >
> > Satya T wrote:
> > >
> > > Hi all,
> > >     There's a gatekeeper routed call,
> > > and if the GK closes down the Q931 TCP connection,
> > > does it mean the call is closed? Consider the following cases :
> > >
> > >      1. When GK sends RELEASE complete before breaking
> > >          down the TCP
> > >      2. When GK does NOT send RELEASE complete before
> > >          breaking down TCP
> > >
> > > H.245 connection is established & ON directly between the EPs in
> > > both cases when the Q931 TCP is broken down.
> > >
> > > Is it considered closed in both the scenarios? or only in the former?
> > >
> > > regards
> > > Satya T
> > >
> >
> >
> --------------------------------------------------------------------------
> >
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > Phone: +44 1344 899 007
> > Fax:   +44 1344 899 001
> >
> --------------------------------------------------------------------------
> --------------------------------------------------------------------------
-
> ------------------------------
> Please send E-mail to contact at imtc.org <mailto:contact at imtc.org>  to
> subscribe or unsubscribe from this list
> ------------------------------
> --------------------------------------------------------------------------
-
>
>
>
>
>
>