Chih-Wei,
I didn't mean to provide you with a tutorial, I know you understand
what is in a cause, I was being verbose for the greater audience.
My point being that there are tried and true methods for doing things
that have been done for many years in the telco world. We should
follow these examples unless there is a very good reason not to.
-Vance
On Thu, Nov 07, 2002 at 01:52:18PM -0500, Vance Shipley wrote:
}
} The Q.931 messages carry information from the originating or
} terminating networks which give valuable information about why the
} call has ended. Reasons include "Unallocated number", "No route
} to destination", "No circuit/channel available" and "Invalid number".
} This information tells you exactly why your calls aren't going
} through and may come from within the H.323 world or the PSTN.
}
} -Vance

Chih-Wei,
Cause is a very useful peice of information and a common field in
switch based CDRs. The source for the cause value should be the
Q.931 message which initiated the teardown of the call. If the
teardown was initiated from another protocol layer there needs to
be some reasoning about how to represent that in the CDR. The
Q.931 case is straight forward though.
The Q.931 messages carry information from the originating or
terminating networks which give valuable information about why the
call has ended. Reasons include "Unallocated number", "No route
to destination", "No circuit/channel available" and "Invalid number".
This information tells you exactly why your calls aren't going
through and may come from within the H.323 world or the PSTN.
-Vance
On Thu, Nov 07, 2002 at 10:17:48AM +0800, Chih-Wei Huang wrote:
}
} Besides that, I am still confused what the definition
} of 'disconnect cause' is?
} Indeed I can get the 'disconnect cause' from at least six ways.
} They are: CauseIE of Release Complete PDU of the calling party,
} reason field of Release Complete UUIE of the calling party,
} terminationCause field of DisengageRequest of the calling party,
} and counterpart of those in the called party.
} You may think they should be the same, but they may be not.
} In this case which one should you choose?
} Moreover, all of these fields are optional.
} How can you define the 'disconnect cause' if all of these are missed?
}
} To my point of view, 'disconnect cause' is an unreliable info,
} so I don't think it is a useful feature.
} My conclusion is, if you are writing an AP depends on the 'disconnect cause',
} you're on your own risk...
}
}
} --
} ~ Chih-Wei Huang (cwhuang@...)
} 'v' CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
} // \\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
} /( )\ I18N Project : http://i18n.linux.org.tw/ (Translator)
} ^`~'^ HomePage : http://www.cwhuang.idv.tw/

Hi,
I try to run openH323gk v2.0b8 (according to changes.txt). Standard things
like connecting to the gatekeeper with OpenPhone work fine in general.
My setup requires the gatekeeper to act as a proxy:
I'm connected to the internet via DSL. This shows up on my linux (Redhat
7.2) box as ppp0 with a dynamic IP. On the box I run openh323gk. The box is
also connected to an internal network eth0 (192.168.0.0/24) that is NATed to
the internet.
What I want is openh323gk to run multi-homed (bound to all interfaces) and
take connections from the internet as well as from internal PCs. It should
handle all the traffic in any direction.
According to docs multi-homed operation requires leaving out the "Home="
parameter in the Main section of configuration file: "By default, the
gatekeeper listens on all interfaces of your host."
If I do that (remove it from configuration) and I try to connect from the
internet, I get the following log entry: (-ttt option)
2002/11/07 17:19:22.308 3 RasSrv.cxx(1823) GK Send to 131.234.xxx.xxx:2446
gatekeeperConfirm {
requestSeqNum = 6788
protocolIdentifier = 0.0.8.2250.0.4
gatekeeperIdentifier = 7 characters {
0047 004b 002d 0050 0041 0050 0042 GK-PAPB
}
rasAddress = ipAddress {
ip = 4 octets {
7f 00 00 01 ....
}
port = 1719
}
}
Note the rasAddress is 127.0.0.1. Although I don't have deeper knowledge
about how H.323 works in detail, I think that is bad. In fact, it makes
OpenPhone fail when connecting to the gatekeeper. (it shows "Unregistering
from gatekeeper "GK-PAPB@...")
netstat shows, that tcp/1721 is correctly bound to 0.0.0.0:
tcp 0 0 0.0.0.0:1721 0.0.0.0:* LISTEN
I can "solve" the problem by specifying the current Internet IP in the
configuration:
Home=217.238.xxx.xxx
This leads to OpenPhone successfully registering. The corresponding log
entry now looks like this:
2002/11/07 17:46:21.659 3 RasSrv.cxx(1823) GK Send to
131.234.xxx.xxx:1097
gatekeeperConfirm {
requestSeqNum = 58824
protocolIdentifier = 0.0.8.2250.0.4
gatekeeperIdentifier = 7 characters {
0047 004b 002d 0050 0041 0050 0042 GK-PAPB
}
rasAddress = ipAddress {
ip = 4 octets {
d9 ee xxx xxx ....
}
port = 1719
}
}
Now "netstat -a -n | grep 1721" shows:
tcp 0 0 217.238.54.229:1721 0.0.0.0:* LISTEN
This "solution" is more than ugly: I can't connect to my gatekeeper from
"inside" and I have to change the IP address whenever my connection is
dropped.
Listing more than one interface address after "Home" doesn't seem to work
(docs don't talk about this either).
I'm not good enough in C++ to look at this myself, but the wild guess would
be the address sent out in the mentioned message should be the target
address of the socket of the connection that the endpoint initiated.
Is there a known solution for this or a hint how to patch it?
Thanks A LOT for your work done so far, it makes H.323 interesting for
smaller companies (that is what I am evaluating) and single people!
Best regards,
Philipp
===================================================
Philipp Adelt - http://www.padelt.de - ICQ#46517808

> I have to ask you again. I tried to compile them (ohphone, gnugk)with the
cvs versions
> of pwlib und openh323. It still not working. GK cvs does not compile
(error see below).
Hi !
Do you see my answer to this problem ?
Letter with subject: Re: [Openh323gk-users] compile troubles?
Date 02-dec-2002

Here the scenary:
EP1 ->GK1 ->GK2 ->GK3 ->EP2(PSTN) report called party no registered
EP1 ->GK2 -> GK3 ->EP2(PSTN) runs fine
EP1 ->GK1 -> GK2 -> EP3 runs fine
Where:
EP1 = ohphone
GK1 = gnugk where GK2 is a neighbog
GK2 = gnugk , where GK1 is neighborg and GK3 is parent
GK2 has GK3 at [Endpoint] section
GK3 = This is a Clarent GK, who uses a Clarent GW to reach
EP2 at the PSTN
Relations:
GK1-GK2 are neighborgs
GK2-GK3 are children-parent
The problem is that a gnugk who has as neighborg another gnugk,
and this second gnugk is registered as "endpoint" to thrird party
gk, is unable to send "up" to the final parent the LRQ.
But if endpoint is registered directly with the "children" GK2 ,
all runs ok, and LRQ are ok, and calls are done to the GK3.
GK1 is able to call to any user registered at GK1 OR GK2.
But if you want to send the call to GK3, you need to be registered
on GK2, and doesn't work from GK1.
I need this scenary, due to redundancy ( like alternative Gatekeepers )
where I will setup something like this.
GK2A -> GK3A ---->> PSTN
EP1 ---- \ /
EP2 ---- \ GK1
EPn ---- / \ \ GK2B -> GK3B ----->> PSTN
\
\GK2C -> GK3C ----->Mobiles
Where in normal working, all GK2X to GK3X are working, but
if one goes down, I will be able to route ussing alternatives at
GK1.
This will allow to use alternatives and prefixed routes even
if GK2 is a children of GK3 gatekeepers.
RESUME:
I need a neighborg will be able to find an endpoint who is
behing a children->parent configuration.
Regards
Joaquin Franco
iris@...
--
[Image] INTEREC is a member of http://www.euro.cauce.org the anti-spam
coallition.
INTEREC . Almajarra 1-11. Tomares. 41940 Sevilla. SPAIN
Phone: +34 95 4159030 FAX: +34 954151819 iris@...

Jakub Klausa =B4=A3=A8=EC:
> As the work over 2.0 progress, i've heard it for several times, and
> i think it's really needed feature, so the developers may consider addi=
ng it
> even to the stable tree - the CDRs should have a field to show the
> cause of the disconnect. We already have configurable CDR format (in a =
way),
> so that would be not that much of a hassle when keeping backward
> compatibility, which i understand is the only reason for not putting it=
in
> the CDR right away.
No, we don't have a configurable CDR format in 2.0 branch.
Besides that, I am still confused what the definition
of 'disconnect cause' is?
Indeed I can get the 'disconnect cause' from at least six ways.
They are: CauseIE of Release Complete PDU of the calling party,
reason field of Release Complete UUIE of the calling party,
terminationCause field of DisengageRequest of the calling party,
and counterpart of those in the called party.
You may think they should be the same, but they may be not.
In this case which one should you choose?
Moreover, all of these fields are optional.
How can you define the 'disconnect cause' if all of these are missed?
To my point of view, 'disconnect cause' is an unreliable info,
so I don't think it is a useful feature.
My conclusion is, if you are writing an AP depends on the 'disconnect cau=
se',
you're on your own risk...
--=20
~ Chih-Wei Huang (cwhuang@...)
'v' CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
// \\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
/( )\ I18N Project : http://i18n.linux.org.tw/ (Translator)
^`~'^ HomePage : http://www.cwhuang.idv.tw/