From juceda at peoplecall.com Tue May 9 05:57:22 2017 From: juceda at peoplecall.com (Jose Uceda) Date: Tue, 9 May 2017 11:57:22 +0200 Subject: [h323plus] Lockup problems Message-ID: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> Hi all, In one of our softwares which uses the H323+ library, we are recently suffering from lockups when the calls are disconnecting. It's currently running with H323+ from CVS and PTLib 2.12.8. As far as we have been able to trace, it seems to be that the RTP UDP socket or signalling channel sometimes remains in a loop and they don't close as expected (log says Broken Pipe errors, eg). That issue causes the call is not finished correctly, and it seems to leave the cleaner thread in a stuck state so subsequent calls are no longer hanged up (at least we don't receive OnCleared event anymore). When we were trying to debug the problem, we saw that the issue became worse with PTLib 2.12.9, and we also suffered from many more locks with the 1,175 h323.cxx file revision, which was reverted about a month later. The comment from the commit that reverts 1,175 revision reads as follows: "Always calling Wait (0) on mutex can cause issues with lock nesting, move fix to PTLib fork" Is there any fork of PTLib in some repository that we haven't noticed about it, that is the official one to use with H323+? Thanks in advance. Regards, Jose Uceda From jan at willamowius.de Tue May 9 11:41:18 2017 From: jan at willamowius.de (Jan Willamowius) Date: Tue, 9 May 2017 17:41:18 +0200 Subject: [h323plus] Lockup problems In-Reply-To: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> References: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> Message-ID: <20170509174118.4cfbc87b.jan@willamowius.de> Hi Jose, I maintain a PTLib fork that I use for GnuGk and all my other H323Plus projects in the GnuGk CVS. Its a fork based on PTLib 2.10.9. http://openh323gk.cvs.sourceforge.net/viewvc/openh323gk/ptlib/ But the locking issue H323Plus commit refers to is a PTimedMutex locking issue on a H323Connection object, not on UDP sockets. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan at willamowius.de Website: https://www.gnugk.org Support: https://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Gesch?ftsf?hrer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Jose Uceda wrote: > Hi all, > > In one of our softwares which uses the H323+ library, we are > recently suffering from lockups when the calls are disconnecting. It's > currently running with H323+ from CVS and PTLib 2.12.8. > > As far as we have been able to trace, it seems to be that the RTP > UDP socket or signalling channel sometimes remains in a loop and they > don't close as expected (log says Broken Pipe errors, eg). That issue > causes the call is not finished correctly, and it seems to leave the > cleaner thread in a stuck state so subsequent calls are no longer hanged > up (at least we don't receive OnCleared event anymore). > > When we were trying to debug the problem, we saw that the issue > became worse with PTLib 2.12.9, and we also suffered from many more > locks with the 1,175 h323.cxx file revision, which was reverted about a > month later. > > The comment from the commit that reverts 1,175 revision reads as > follows: > "Always calling Wait (0) on mutex can cause issues with lock nesting, > move fix to PTLib fork" > > Is there any fork of PTLib in some repository that we haven't > noticed about it, that is the official one to use with H323+? > > Thanks in advance. > > Regards, > > Jose Uceda > > From ddomingos at daitangroup.com Fri May 26 14:46:28 2017 From: ddomingos at daitangroup.com (Diego Carvalho Domingos) Date: Fri, 26 May 2017 18:46:28 +0000 Subject: [h323plus] H235 on extended video channel (H239) Message-ID: Hi, all I'm successfully using both h239 and h235 (for audio and video channels) in my application. Now I also would like to encrypt the content video (extended video channel). It seems that the security capability is not being added to the H.239(H.264{sw} <1>) capability. Is there some way to enable it? Thanks in advance. Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From juceda at peoplecall.com Mon May 29 06:47:21 2017 From: juceda at peoplecall.com (Jose Uceda) Date: Mon, 29 May 2017 12:47:21 +0200 Subject: [h323plus] Possible misassumption in HandleFirstSignallingChannelPDU Message-ID: In our software that we mentioned a few days ago, in addition to the lockups, we observed a problem when we apparently received an incoming call, but CreateConnection is called with a valid PDU that is not a Setup Message one. It happens when the incoming call comes from a Cisco gateway, and the call hangs up at a point where the gateway has sent the Admission Request to the gatekeeper, receives its corresponding admission confirm, but has not sent yet the setup message to our software / destination endpoint. In these circumstances we saw that the gateway has opened the signaling socket with our endpoint, but the first packet it sends is a Release Complete because the call was hung before sending the setup. PDU trace from our Gatekeeper: 2017-05-27 14:46:28.853 5d37 INFO pdu.call.a.ARQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.855 5d37 INFO pdu.call.a.ACF.send : Sending to ip$x.x.x.x:54432. 2017-05-27 14:46:28.865 5d37 INFO pdu.call.d.DRQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.866 5d37 INFO pdu.call.d.DCF.send : Sending to ip$x.x.x.x:54432. See the time-stamps, showing that the ACF and DRQ are closely followed. We receive the call at our endpoint, in the CreateConnection function at the same time point as the DRQ / DCF. In our software, in some cases we return NULL if we cannot handle the incoming connection (not enough setup data, e.g.), and if we are running an executable compiled in Debug mode, an assert fails on the following operator: H225_H323_UU_PDU_h323_message_body :: operator const H225_Setup_UUIE & () const #endif { #ifndef PASN_LEANANDMEAN PAssert (PIsDescendant (PAssertNULL (choice), H225_Setup_UUIE), PInvalidCast); #endif Return * (H225_Setup_UUIE *) choice; } It is caused by the following line (transports.cxx: 1126): H225_Setup_UUIE & setup = pdu.m_h323_uu_pdu.m_h323_message_body; This code assumes that the initial PDU is a Setup one without checking it, when it may not necessarily be. That can cause a DoS in a software that has core dump enabled when an assert occurs, or if there is some code in HandleFirstSignallingChannelPDU / OnIncomingConnection and sub-calls that trust and handles the PDU object assuming it is a Setup message. I've made the following patch on the HandleFirstSignallingChannelPDU function, which verifies that the PDU is a Setup message, otherwise it returns FALSE (same behavior as if it had not been able to read a valid q931 pdu), since we think it does not make much sense to call OnIncomingConnection if the initial PDU is not a Setup one: -------------------------------------------------------------------------------- --- src/transports.cxx.orig 2015-11-24 18:51:06.385755223 +0100 +++ src/transports.cxx 2017-05-29 11:15:20.777411444 +0200 @@ -1106,7 +1106,13 @@ return FALSE; } - unsigned callReference = pdu.GetQ931().GetCallReference(); + const Q931 &firstQ931PDU = pdu.GetQ931(); + if (firstQ931PDU.GetMessageType() != Q931::SetupMsg) { + PTRACE(1, "H225\tFirst pdu is not a setup one, connection not started."); + return FALSE; + } + + unsigned callReference = firstQ931PDU.GetCallReference(); PTRACE(3, "H225\tIncoming call, first PDU: callReference=" << callReference); // Get a new (or old) connection from the endpoint -------------------------------------------------------------------------------- A place where we could also put the patch is in the HandleSignallingSocket function, which apparently is only used from HandleFirstSignallingChannelPDU, but as it has a more generic name and may give rise to doubts of its behavior. Regards, Jose Uceda From jan at willamowius.de Tue May 30 04:34:29 2017 From: jan at willamowius.de (Jan Willamowius) Date: Tue, 30 May 2017 10:34:29 +0200 Subject: [h323plus] Possible misassumption in HandleFirstSignallingChannelPDU In-Reply-To: References: Message-ID: <20170530103429.07948b78.jan@willamowius.de> Hi Jose, thanks for finding that bug! I have committed your patch with minor changes to the CVS. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan at willamowius.de H.323 Support: https://www.willamowius.com/ Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Gesch?ftsf?hrer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Jose Uceda wrote: > In our software that we mentioned a few days ago, in addition to the > lockups, we observed a problem when we apparently received an incoming > call, but CreateConnection is called with a valid PDU that is not a > Setup Message one. > > It happens when the incoming call comes from a Cisco gateway, and the > call hangs up at a point where the gateway has sent the Admission > Request to the gatekeeper, receives its corresponding admission confirm, > but has not sent yet the setup message to our software / destination > endpoint. > > In these circumstances we saw that the gateway has opened the signaling > socket with our endpoint, but the first packet it sends is a Release > Complete because the call was hung before sending the setup. > > > PDU trace from our Gatekeeper: > > 2017-05-27 14:46:28.853 5d37 INFO pdu.call.a.ARQ.recv : Received from ip$x.x.x.x:54432. > 2017-05-27 14:46:28.855 5d37 INFO pdu.call.a.ACF.send : Sending to ip$x.x.x.x:54432. > 2017-05-27 14:46:28.865 5d37 INFO pdu.call.d.DRQ.recv : Received from ip$x.x.x.x:54432. > 2017-05-27 14:46:28.866 5d37 INFO pdu.call.d.DCF.send : Sending to ip$x.x.x.x:54432. > > See the time-stamps, showing that the ACF and DRQ are closely followed. > We receive the call at our endpoint, in the CreateConnection function at > the same time point as the DRQ / DCF. > > In our software, in some cases we return NULL if we cannot handle the > incoming connection (not enough setup data, e.g.), and if we are running > an executable compiled in Debug mode, an assert fails on the following > operator: > > H225_H323_UU_PDU_h323_message_body :: operator const H225_Setup_UUIE > & () const > #endif > { > #ifndef PASN_LEANANDMEAN > PAssert (PIsDescendant (PAssertNULL (choice), H225_Setup_UUIE), > PInvalidCast); > #endif > Return * (H225_Setup_UUIE *) choice; > } > > > It is caused by the following line (transports.cxx: 1126): > > H225_Setup_UUIE & setup = pdu.m_h323_uu_pdu.m_h323_message_body; > > This code assumes that the initial PDU is a Setup one without checking > it, when it may not necessarily be. That can cause a DoS in a software > that has core dump enabled when an assert occurs, or if there is some > code in HandleFirstSignallingChannelPDU / OnIncomingConnection and > sub-calls that trust and handles the PDU object assuming it is a Setup > message. > > I've made the following patch on the HandleFirstSignallingChannelPDU > function, which verifies that the PDU is a Setup message, otherwise it > returns FALSE (same behavior as if it had not been able to read a valid > q931 pdu), since we think it does not make much sense to call > OnIncomingConnection if the initial PDU is not a Setup one: > > -------------------------------------------------------------------------------- > > --- src/transports.cxx.orig 2015-11-24 18:51:06.385755223 +0100 > +++ src/transports.cxx 2017-05-29 11:15:20.777411444 +0200 > @@ -1106,7 +1106,13 @@ > return FALSE; > } > > - unsigned callReference = pdu.GetQ931().GetCallReference(); > + const Q931 &firstQ931PDU = pdu.GetQ931(); > + if (firstQ931PDU.GetMessageType() != Q931::SetupMsg) { > + PTRACE(1, "H225\tFirst pdu is not a setup one, connection not > started."); > + return FALSE; > + } > + > + unsigned callReference = firstQ931PDU.GetCallReference(); > PTRACE(3, "H225\tIncoming call, first PDU: callReference=" << > callReference); > > // Get a new (or old) connection from the endpoint > > -------------------------------------------------------------------------------- > > A place where we could also put the patch is in the > HandleSignallingSocket function, which apparently is only used from > HandleFirstSignallingChannelPDU, but as it has a more generic name and > may give rise to doubts of its behavior. > > > Regards, > > Jose Uceda > From juceda at peoplecall.com Tue May 9 05:57:22 2017 From: juceda at peoplecall.com (Jose Uceda) Date: Tue, 9 May 2017 11:57:22 +0200 Subject: [h323plus] Lockup problems Message-ID: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> Hi all, In one of our softwares which uses the H323+ library, we are recently suffering from lockups when the calls are disconnecting. It's currently running with H323+ from CVS and PTLib 2.12.8. As far as we have been able to trace, it seems to be that the RTP UDP socket or signalling channel sometimes remains in a loop and they don't close as expected (log says Broken Pipe errors, eg). That issue causes the call is not finished correctly, and it seems to leave the cleaner thread in a stuck state so subsequent calls are no longer hanged up (at least we don't receive OnCleared event anymore). When we were trying to debug the problem, we saw that the issue became worse with PTLib 2.12.9, and we also suffered from many more locks with the 1,175 h323.cxx file revision, which was reverted about a month later. The comment from the commit that reverts 1,175 revision reads as follows: "Always calling Wait (0) on mutex can cause issues with lock nesting, move fix to PTLib fork" Is there any fork of PTLib in some repository that we haven't noticed about it, that is the official one to use with H323+? Thanks in advance. Regards, Jose Uceda From jan at willamowius.de Tue May 9 11:41:18 2017 From: jan at willamowius.de (Jan Willamowius) Date: Tue, 9 May 2017 17:41:18 +0200 Subject: [h323plus] Lockup problems In-Reply-To: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> References: <0b9e2523-0a5a-7fd6-058d-401c1d9a99fd@peoplecall.com> Message-ID: <20170509174118.4cfbc87b.jan@willamowius.de> Hi Jose, I maintain a PTLib fork that I use for GnuGk and all my other H323Plus projects in the GnuGk CVS. Its a fork based on PTLib 2.10.9. http://openh323gk.cvs.sourceforge.net/viewvc/openh323gk/ptlib/ But the locking issue H323Plus commit refers to is a PTimedMutex locking issue on a H323Connection object, not on UDP sockets. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan at willamowius.de Website: https://www.gnugk.org Support: https://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Gesch?ftsf?hrer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Jose Uceda wrote: > Hi all, > > In one of our softwares which uses the H323+ library, we are > recently suffering from lockups when the calls are disconnecting. It's > currently running with H323+ from CVS and PTLib 2.12.8. > > As far as we have been able to trace, it seems to be that the RTP > UDP socket or signalling channel sometimes remains in a loop and they > don't close as expected (log says Broken Pipe errors, eg). That issue > causes the call is not finished correctly, and it seems to leave the > cleaner thread in a stuck state so subsequent calls are no longer hanged > up (at least we don't receive OnCleared event anymore). > > When we were trying to debug the problem, we saw that the issue > became worse with PTLib 2.12.9, and we also suffered from many more > locks with the 1,175 h323.cxx file revision, which was reverted about a > month later. > > The comment from the commit that reverts 1,175 revision reads as > follows: > "Always calling Wait (0) on mutex can cause issues with lock nesting, > move fix to PTLib fork" > > Is there any fork of PTLib in some repository that we haven't > noticed about it, that is the official one to use with H323+? > > Thanks in advance. > > Regards, > > Jose Uceda > > From ddomingos at daitangroup.com Fri May 26 14:46:28 2017 From: ddomingos at daitangroup.com (Diego Carvalho Domingos) Date: Fri, 26 May 2017 18:46:28 +0000 Subject: [h323plus] H235 on extended video channel (H239) Message-ID: Hi, all I'm successfully using both h239 and h235 (for audio and video channels) in my application. Now I also would like to encrypt the content video (extended video channel). It seems that the security capability is not being added to the H.239(H.264{sw} <1>) capability. Is there some way to enable it? Thanks in advance. Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From juceda at peoplecall.com Mon May 29 06:47:21 2017 From: juceda at peoplecall.com (Jose Uceda) Date: Mon, 29 May 2017 12:47:21 +0200 Subject: [h323plus] Possible misassumption in HandleFirstSignallingChannelPDU Message-ID: In our software that we mentioned a few days ago, in addition to the lockups, we observed a problem when we apparently received an incoming call, but CreateConnection is called with a valid PDU that is not a Setup Message one. It happens when the incoming call comes from a Cisco gateway, and the call hangs up at a point where the gateway has sent the Admission Request to the gatekeeper, receives its corresponding admission confirm, but has not sent yet the setup message to our software / destination endpoint. In these circumstances we saw that the gateway has opened the signaling socket with our endpoint, but the first packet it sends is a Release Complete because the call was hung before sending the setup. PDU trace from our Gatekeeper: 2017-05-27 14:46:28.853 5d37 INFO pdu.call.a.ARQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.855 5d37 INFO pdu.call.a.ACF.send : Sending to ip$x.x.x.x:54432. 2017-05-27 14:46:28.865 5d37 INFO pdu.call.d.DRQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.866 5d37 INFO pdu.call.d.DCF.send : Sending to ip$x.x.x.x:54432. See the time-stamps, showing that the ACF and DRQ are closely followed. We receive the call at our endpoint, in the CreateConnection function at the same time point as the DRQ / DCF. In our software, in some cases we return NULL if we cannot handle the incoming connection (not enough setup data, e.g.), and if we are running an executable compiled in Debug mode, an assert fails on the following operator: H225_H323_UU_PDU_h323_message_body :: operator const H225_Setup_UUIE & () const #endif { #ifndef PASN_LEANANDMEAN PAssert (PIsDescendant (PAssertNULL (choice), H225_Setup_UUIE), PInvalidCast); #endif Return * (H225_Setup_UUIE *) choice; } It is caused by the following line (transports.cxx: 1126): H225_Setup_UUIE & setup = pdu.m_h323_uu_pdu.m_h323_message_body; This code assumes that the initial PDU is a Setup one without checking it, when it may not necessarily be. That can cause a DoS in a software that has core dump enabled when an assert occurs, or if there is some code in HandleFirstSignallingChannelPDU / OnIncomingConnection and sub-calls that trust and handles the PDU object assuming it is a Setup message. I've made the following patch on the HandleFirstSignallingChannelPDU function, which verifies that the PDU is a Setup message, otherwise it returns FALSE (same behavior as if it had not been able to read a valid q931 pdu), since we think it does not make much sense to call OnIncomingConnection if the initial PDU is not a Setup one: -------------------------------------------------------------------------------- --- src/transports.cxx.orig 2015-11-24 18:51:06.385755223 +0100 +++ src/transports.cxx 2017-05-29 11:15:20.777411444 +0200 @@ -1106,7 +1106,13 @@ return FALSE; } - unsigned callReference = pdu.GetQ931().GetCallReference(); + const Q931 &firstQ931PDU = pdu.GetQ931(); + if (firstQ931PDU.GetMessageType() != Q931::SetupMsg) { + PTRACE(1, "H225\tFirst pdu is not a setup one, connection not started."); + return FALSE; + } + + unsigned callReference = firstQ931PDU.GetCallReference(); PTRACE(3, "H225\tIncoming call, first PDU: callReference=" << callReference); // Get a new (or old) connection from the endpoint -------------------------------------------------------------------------------- A place where we could also put the patch is in the HandleSignallingSocket function, which apparently is only used from HandleFirstSignallingChannelPDU, but as it has a more generic name and may give rise to doubts of its behavior. Regards, Jose Uceda From jan at willamowius.de Tue May 30 04:34:29 2017 From: jan at willamowius.de (Jan Willamowius) Date: Tue, 30 May 2017 10:34:29 +0200 Subject: [h323plus] Possible misassumption in HandleFirstSignallingChannelPDU In-Reply-To: References: Message-ID: <20170530103429.07948b78.jan@willamowius.de> Hi Jose, thanks for finding that bug! I have committed your patch with minor changes to the CVS. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan at willamowius.de H.323 Support: https://www.willamowius.com/ Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Gesch?ftsf?hrer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Jose Uceda wrote: > In our software that we mentioned a few days ago, in addition to the > lockups, we observed a problem when we apparently received an incoming > call, but CreateConnection is called with a valid PDU that is not a > Setup Message one. > > It happens when the incoming call comes from a Cisco gateway, and the > call hangs up at a point where the gateway has sent the Admission > Request to the gatekeeper, receives its corresponding admission confirm, > but has not sent yet the setup message to our software / destination > endpoint. > > In these circumstances we saw that the gateway has opened the signaling > socket with our endpoint, but the first packet it sends is a Release > Complete because the call was hung before sending the setup. > > > PDU trace from our Gatekeeper: > > 2017-05-27 14:46:28.853 5d37 INFO pdu.call.a.ARQ.recv : Received from ip$x.x.x.x:54432. > 2017-05-27 14:46:28.855 5d37 INFO pdu.call.a.ACF.send : Sending to ip$x.x.x.x:54432. > 2017-05-27 14:46:28.865 5d37 INFO pdu.call.d.DRQ.recv : Received from ip$x.x.x.x:54432. > 2017-05-27 14:46:28.866 5d37 INFO pdu.call.d.DCF.send : Sending to ip$x.x.x.x:54432. > > See the time-stamps, showing that the ACF and DRQ are closely followed. > We receive the call at our endpoint, in the CreateConnection function at > the same time point as the DRQ / DCF. > > In our software, in some cases we return NULL if we cannot handle the > incoming connection (not enough setup data, e.g.), and if we are running > an executable compiled in Debug mode, an assert fails on the following > operator: > > H225_H323_UU_PDU_h323_message_body :: operator const H225_Setup_UUIE > & () const > #endif > { > #ifndef PASN_LEANANDMEAN > PAssert (PIsDescendant (PAssertNULL (choice), H225_Setup_UUIE), > PInvalidCast); > #endif > Return * (H225_Setup_UUIE *) choice; > } > > > It is caused by the following line (transports.cxx: 1126): > > H225_Setup_UUIE & setup = pdu.m_h323_uu_pdu.m_h323_message_body; > > This code assumes that the initial PDU is a Setup one without checking > it, when it may not necessarily be. That can cause a DoS in a software > that has core dump enabled when an assert occurs, or if there is some > code in HandleFirstSignallingChannelPDU / OnIncomingConnection and > sub-calls that trust and handles the PDU object assuming it is a Setup > message. > > I've made the following patch on the HandleFirstSignallingChannelPDU > function, which verifies that the PDU is a Setup message, otherwise it > returns FALSE (same behavior as if it had not been able to read a valid > q931 pdu), since we think it does not make much sense to call > OnIncomingConnection if the initial PDU is not a Setup one: > > -------------------------------------------------------------------------------- > > --- src/transports.cxx.orig 2015-11-24 18:51:06.385755223 +0100 > +++ src/transports.cxx 2017-05-29 11:15:20.777411444 +0200 > @@ -1106,7 +1106,13 @@ > return FALSE; > } > > - unsigned callReference = pdu.GetQ931().GetCallReference(); > + const Q931 &firstQ931PDU = pdu.GetQ931(); > + if (firstQ931PDU.GetMessageType() != Q931::SetupMsg) { > + PTRACE(1, "H225\tFirst pdu is not a setup one, connection not > started."); > + return FALSE; > + } > + > + unsigned callReference = firstQ931PDU.GetCallReference(); > PTRACE(3, "H225\tIncoming call, first PDU: callReference=" << > callReference); > > // Get a new (or old) connection from the endpoint > > -------------------------------------------------------------------------------- > > A place where we could also put the patch is in the > HandleSignallingSocket function, which apparently is only used from > HandleFirstSignallingChannelPDU, but as it has a more generic name and > may give rise to doubts of its behavior. > > > Regards, > > Jose Uceda >