Re: Closing Q.931 TCP connection..
Once a SETUP message comes in, the GK replies with an H.245 address of
Hi Chris, Glad I caught your interest ... Let me clarify some points which seem to have been misunderstood: (I'll try shorthand this time :-) 1. The case is NOT made for the GK not being the point for SETUP to call. Quite the reverse: I propose that the GK *is* the single point to call, and that it executes load balancing logic to distribute the H.245 negotiations elsewhere. 2. Varying the address given in AnnexG defetes no 1. 3. H.450.2 has nothing to do with it as the call is NOT being redirected. It is merely being decomposed. 4. You are NOT required to remove the call signalling at all. I'm afraid my point has been completely missed : I call for ALLOWING the close of the "Q.931" TCP signalling channel, while maintaining only the MEDIA CONTROL (h.245) channel open. 5. I too suspect that this scenario "just works", which is why I find it attractive to continue to allow closing of the Q.931 channel mid-call, WITHOUT killing the call . (again - this is perfectly legal today). We may need to update the standard, though, in order to solve the problems that Paul identified ! Thanks for your thoughts, Boaz -------- On 04/01/2000 06:27 PM GMT Chris Wayman Purvis <cwp@ISDN-COMMS.CO.UK> wrote: Boaz, The beast you describe is very strange and, as Paul says, interesting. Permit me to copy a para from your mail, in order to take issue with it! 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. I'm not convinced the case is made here for the GK not being the point for SETUP to call. As you postulate the use of "SendSetup" Annex G messages, load balancing can be achieved adequately by varying the address given there. I'm hazy about how much information Annex G gives you as to the source of a call, but would hope that the sort of information that will be useful here (such as country of origin of the call) would be available (maybe an Annex G expert can help here?)?
Even given the GK as the destination for the original setup message, H.450.2(? I think it's 2!) would allow the call to be redirected elsewhere once the GK has looked at that message. What I'm saying in general is that I'd hope to be able to achieve your application without requiring the removal of the call signalling channel, and I'm sure there are at least two ways of doing it, depending on precisely what you require, without any new standards needing to be written. In most cases I'm agnostic about Paul's point of a gatekeeper routing call control (H.225.0) but not connection control (H.245). In my view everything just works. BUT I believe that in order for everything to "just work" the assumption has to be there that the call control channel doesn't die mid-call. Regards, Chris "Paul E. Jones" wrote:
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
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),
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
might open this area for study.
Best Regards, Paul
----- Original Message ----- From: "Boaz Michaely" <Boaz_Michaely@vocaltec.com> To: "Paul E. Jones" <paul.jones@ties.itu.int> Cc: <h323implementors@imtc.org>; <itu-sg16@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
(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
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
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
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
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@vocaltec.com http://people.itu.int/~michaely
"Paul E. Jones" <paul.jones@ties.itu.int> on 02/01/2000 12:04:50 AM
Please respond to "Paul E. Jones" <paul.jones@ties.itu.int>
To: "Chris Wayman Purvis" <cwp@isdn-comms.co.uk>, "Satya T" <satyat@MIEL.MOT.COM> cc: h323implementors@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
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@isdn-comms.co.uk> To: "Satya T" <satyat@MIEL.MOT.COM> Cc: <h323implementors@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
of the that protocol the the point the 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@imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------
-
---------------------------------------------------------------------------
------------------------------ Please send E-mail to contact@imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------
--------------------------------------------------------------------------- -- 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
Boaz Michaely wrote:
1. The case is NOT made for the GK not being the point for SETUP to call. Quite the reverse: I propose that the GK *is* the single point to call, and that it executes load balancing logic to distribute the H.245 negotiations elsewhere.
And I propose alternative means for achieving the same end (ie load balancing by other means). Proposing a possible method of achieving something is NOT the same as making a case for it. I still consider the case not to be made.
2. Varying the address given in AnnexG defetes no 1.
You have not (yet) established any advantage in making the GK "the single point to call", and varying addresses given in Annex G is one method of load balancing.
3. H.450.2 has nothing to do with it as the call is NOT being redirected. It is merely being decomposed.
It provides an alternative means to balance loads after using the GK as the single point of contact.
4. You are NOT required to remove the call signalling at all. I'm afraid my point has been completely missed : I call for ALLOWING the close of the "Q.931" TCP signalling channel, while maintaining only the MEDIA CONTROL (h.245) channel open.
You are twisting my words, which were carefully chosen. I said "I'd hope to be able to achieve your application without requiring the removal of the call signalling channel", meaning that I believe your application can be achieved without without closing what you call 'the "Q.931" TCP signalling channel' and I called "the call signalling channel". I am not saying that there is no possible reason for allowing the closure of the call signalling channel: I AM saying that I do not believe your scenario establishes one, as I have given two possible methods of achieving the desired effect of your scenario without doing so.
5. I too suspect that this scenario "just works", which is why I find it attractive to continue to allow closing of the Q.931 channel mid-call, WITHOUT killing the call . (again - this is perfectly legal today). We may need to update the standard, though, in order to solve the problems that Paul identified !
You're misunderstanding me again. My statement was that a gatekeeper routing call control but not connection control "just works" under normal circumstances. The scenario you describe is not "normal circumstances", and may cause problems. Regards, Chris
-------- On 04/01/2000 06:27 PM GMT Chris Wayman Purvis <cwp@ISDN-COMMS.CO.UK> wrote:
Boaz,
The beast you describe is very strange and, as Paul says, interesting.
Permit me to copy a para from your mail, in order to take issue with it!
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. I'm not convinced the case is made here for the GK not being the point for SETUP to call. As you postulate the use of "SendSetup" Annex G messages, load balancing can be achieved adequately by varying the address given there. I'm hazy about how much information Annex G gives you as to the source of a call, but would hope that the sort of information that will be useful here (such as country of origin of the call) would be available (maybe an Annex G expert can help here?)?
Even given the GK as the destination for the original setup message, H.450.2(? I think it's 2!) would allow the call to be redirected elsewhere once the GK has looked at that message.
What I'm saying in general is that I'd hope to be able to achieve your application without requiring the removal of the call signalling channel, and I'm sure there are at least two ways of doing it, depending on precisely what you require, without any new standards needing to be written.
In most cases I'm agnostic about Paul's point of a gatekeeper routing call control (H.225.0) but not connection control (H.245). In my view everything just works. BUT I believe that in order for everything to "just work" the assumption has to be there that the call control channel doesn't die mid-call.
Regards, Chris
"Paul E. Jones" wrote:
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
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),
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
might open this area for study.
Best Regards, Paul
----- Original Message ----- From: "Boaz Michaely" <Boaz_Michaely@vocaltec.com> To: "Paul E. Jones" <paul.jones@ties.itu.int> Cc: <h323implementors@imtc.org>; <itu-sg16@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
(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
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
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
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
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@vocaltec.com http://people.itu.int/~michaely
"Paul E. Jones" <paul.jones@ties.itu.int> on 02/01/2000 12:04:50 AM
Please respond to "Paul E. Jones" <paul.jones@ties.itu.int>
To: "Chris Wayman Purvis" <cwp@isdn-comms.co.uk>, "Satya T" <satyat@MIEL.MOT.COM> cc: h323implementors@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
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@isdn-comms.co.uk> To: "Satya T" <satyat@MIEL.MOT.COM> Cc: <h323implementors@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
of the that protocol the the point the 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@imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------
-
---------------------------------------------------------------------------
------------------------------ Please send E-mail to contact@imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------
---------------------------------------------------------------------------
-- 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
-- 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
participants (2)
-
Boaz Michaely -
Chris Wayman Purvis