I made the changes to the gatekeeper.ini file in Ottawa, NewYork and Detroit.
The log below is from the gnugk in Detroit. It's still skipping over the
Internal routing and trying to resolve a DNS.
I terminated the gnugk and restarted the process on each server after editing
the gatekeeper.ini.
2011/10/04 15:46:57.773 4 yasocket.cxx(920) TCPSrv Accept request
on 74.199.95.14:1720
2011/10/04 15:46:57.773 5 job.cxx(363) JOB Worker threads:
6 total - 6 busy, 0 idle
2011/10/04 15:46:57.773 5 job.cxx(189) JOB Starting Job
Acceptor at Worker thread 140419354912512
2011/10/04 15:46:57.774 5 ProxyChannel.cxx(684) Q931s Reading from
216.13.45.141:20000
2011/10/04 15:46:57.774 3 ProxyChannel.cxx(1023) Q931s Received: Setup
CRV=22406 from 216.13.45.141:20000
2011/10/04 15:46:57.774 4 ProxyChannel.cxx(966) Q931 Received: {
q931pdu = {
protocolDiscriminator = 8
callReference = 22406
from = originator
messageType = Setup
IE: Bearer-Capability = {
88 18 a0 a5 ....
}
IE: Display = {
66 72 65 64 6c 61 70 74 6f 70 00 fredlaptop.
}
IE: Calling-Party-Number = {
81 36 38 37 37 .6877
}
IE: Called-Party-Number = {
81 35 35 38 30 .5580
}
IE: User-User = {
20 b0 06 00 08 91 4a 00 06 01 01 80 9b aa 22 c0 .....J.......".
09 00 00 3d 0e 54 65 73 74 20 6d 6f 64 5f 68 33 ...=.Test mod_h3
32 33 00 00 1d 31 2e 30 61 6c 70 68 61 31 20 28 23...1.0alpha1 (
48 33 32 33 70 6c 75 73 20 76 31 2e 32 31 2e 30 H323plus v1.21.0
29 00 00 00 01 40 03 00 35 00 35 00 38 00 30 00 )....@..5.5.8.0.
50 90 20 46 2f ed e0 11 9f 48 00 90 f5 99 89 f3 P. F/....H......
00 5d 0f 80 07 00 d8 0d 2d 8d 06 b8 11 00 46 90 .]......-.....F.
20 46 2f ed e0 11 9f 48 00 90 f5 99 89 f3 01 00 F/....H........
01 00 13 10 00 31 00 30 00 34 00 39 00 5f 00 65 .....1.0.4.9._.e
00 6e 00 64 00 70 01 00 01 00 02 80 01 80 .n.d.p........
}
}
h225pdu = {
h323_uu_pdu = {
h323_message_body = setup {
protocolIdentifier = 0.0.8.2250.0.6
sourceAddress = 1 entries {
[0]=dialedDigits "6877"
}
sourceInfo = {
vendor = {
vendor = {
t35CountryCode = 9
t35Extension = 0
manufacturerCode = 61
}
productId = 15 octets {
54 65 73 74 20 6d 6f 64 5f 68 33 32 33 00 00 Test mod_h323..
}
versionId = 30 octets {
31 2e 30 61 6c 70 68 61 31 20 28 48 33 32 33 70 1.0alpha1
(H323p
6c 75 73 20 76 31 2e 32 31 2e 30 29 00 00 lus v1.21.0)..
}
}
terminal = {
}
mc = false
undefinedNode = false
}
destinationAddress = 1 entries {
[0]=h323_ID 4 characters {
0035 0035 0038 0030 5580
}
}
activeMC = false
conferenceID = 16 octets {
50 90 20 46 2f ed e0 11 9f 48 00 90 f5 99 89 f3 P. F/....H......
}
conferenceGoal = create <<null>>
callType = pointToPoint <<null>>
sourceCallSignalAddress = ipAddress {
ip = 4 octets {
d8 0d 2d 8d ..-.
}
port = 1720
}
callIdentifier = {
guid = 16 octets {
46 90 20 46 2f ed e0 11 9f 48 00 90 f5 99 89 f3 F. F/....H......
}
}
mediaWaitForConnect = false
canOverlapSend = false
endpointIdentifier = 9 characters {
0031 0030 0034 0039 005f 0065 006e 0064 1049_end
0070 p
}
multipleCalls = false
maintainConnection = false
}
h245Tunneling = true
}
}
}
2011/10/04 15:46:57.775 4 ProxyChannel.cxx(2017) Q931s GWRewrite
source for 216.13.45.141:20000: setup H323 ID or E164
2011/10/04 15:46:57.775 5 Routing.cxx(196) ROUTING Checking policy
Explicit for request Setup CRV=22406
2011/10/04 15:46:57.775 5 Routing.cxx(196) ROUTING Checking policy
Internal for request Setup CRV=22406
2011/10/04 15:46:57.775 5 Routing.cxx(196) ROUTING Checking policy
SRV for request Setup CRV=22406
2011/10/04 15:46:57.775 5 Routing.cxx(196) ROUTING Checking policy
DNS for request Setup CRV=22406
2011/10/04 15:46:57.775 4 Routing.cxx(604) ROUTING DNS policy
resolves to 5580 @ 0.0.21.204:1720
2011/10/04 15:46:57.775 5 Routing.cxx(202) ROUTING Policy DNS
applied to the request Setup CRV=22406
2011/10/04 15:46:57.775 4 ProxyChannel.cxx(2411) Q931s Unregistered
party is not NATed
2011/10/04 15:46:57.775 2 RasTbl.cxx(3412) CallTable::Insert(CALL)
Call No. 2, total sessions : 1
2011/10/04 15:46:57.775 2 gkacct.cxx(950) GKACCT Successfully
logged event 1 for call no. 2
2011/10/04 15:46:57.775 4 ProxyChannel.cxx(4794) Q931s Set Called
Numbering Plan 1 Type Of Number 0
2011/10/04 15:46:57.775 4 ProxyChannel.cxx(4824) Q931s Set Calling
Numbering Plan 1 Type Of Number 0
2011/10/04 15:46:57.775 3 ProxyChannel.cxx(2862) Q931s Call 2 is NAT
type 0
2011/10/04 15:46:57.776 1 ProxyChannel.cxx(870) Call 2: h245Routed=1
proxy=1
2011/10/04 15:46:57.776 3 ProxyChannel.cxx(887) GK Call 2 proxy
enabled
2011/10/04 15:46:57.776 4 ProxyChannel.cxx(966) Q931 Send to
0.0.21.204:1720 {
The new gatekeeper.ini is listed below:
root@Jim-HDP:/var/log/gnugk# cat /etc/gatekeeper.ini
# Template Proxy GK
#
# WAN: ip dynamic / dial-up
# LAN: IP=192.168.0.1 Network= 192.168.0.0/16
# the gatekeeper is run at the proxy machine
#
# suggested way to run the gatekeeper
# gnugk -rr -l 100 -c /etc/gnugk.ini
[Gatekeeper::Main]
Fourtytwo=42
Name=MagorH323GK
TimeToLive=100
CompareAliasType=0
# Home=your.public.ip.addr
# TotalBandwidth=128000
#
# each G.723.1 call consume 1280 Bps.
[RoutedMode]
GKRouted=1
H245Routed=1
AcceptUnregisteredCalls=1
AcceptNeighborsCalls=1
CallSignalPort=1720
CallSignalHandlerNumber=1
RemoveH245AddressOnTunneling=1
DropCallsByReleaseComplete=1
SupportNATedEndpoints=1
SupportCallingNATedEndpoints=1
Q931PortRange=20000-20099
H245PortRange=30000-30099
SendReleaseCompleteOnDRQ=1
#[Routing::Explicit]
#10.191.20.0=192.168.216.1
[Proxy]
Enable=1
#InternalNetwork=192.168.216.0/24,10.191.20.0/24
InternalNetwork=192.168.1.0/24
T120PortRange=50000-59999
RTPPortRange=50000-59999
ProxyForNAT=1
ProxyForSameNAT=0
ProxyAlways=1
# [ModeSelection]
[RasSrv::LRQFeatures]
NeighborTimeout=6
ForwardHopCount=8
AlwaysForwardLRQ=1
IncludeDestinationInfoInLCF=1
CiscoGKCompatible=1
[RasSrv::Neighbors]
#
# List of some possible neighbors can be downloaded
# from http://www.cic.ac.id/gkregistration
[RoutingPolicy]
default=explicit,internal,srv,dns,parent,neighbor
[GkStatus::Auth]
rule=allow
# your.public.ip.addr=allow
;default=forbid
..FG..
On 2011-10-04, at 3:35 PM, Jan Willamowius wrote:
> Hi Fred,
>
> this is your problem: Your destination isn't sent as an E.164.
>
>> destinationAddress = 1 entries {
>> [0]=h323_ID 4 characters {
>> 0035 0035 0038 0030 5580
>> }
>> }
>
> You are trying to call H323ID "5580", but your endpoint is E164 "5580".
> According to the spec those are 2 different things, even so Tandberg usually
> treats them as the same.
>
> If you want aliases to match regardless of their type, you can set in
> your config
>
> [Gatekeeper::Main]
> CompareAliasType=0
>
> Its still strange that the DNS policy thinks it can resolve it. I'll
> check into that when I rewrite the policy for IPv6 soon.
>
> Regards,
> Jan
>
>
> Fred Gillette wrote:
>> Yup,
>>
>> 2011/10/04 11:32:38.406 4 yasocket.cxx(920) TCPSrv Accept
>> request on 74.199.95.14:1720
>> 2011/10/04 11:32:38.406 5 job.cxx(363) JOB Worker
>> threads: 6 total - 6 busy, 0 idle
>> 2011/10/04 11:32:38.406 5 job.cxx(189) JOB
>> Starting Job Acceptor at Worker thread 139753991223040
>> 2011/10/04 11:32:38.406 5 ProxyChannel.cxx(684) Q931s Reading
>> from 216.13.45.141:20024
>> 2011/10/04 11:32:38.406 3 ProxyChannel.cxx(1023) Q931s
>> Received: Setup CRV=22394 from 216.13.45.141:20024
>> 2011/10/04 11:32:38.407 4 ProxyChannel.cxx(966) Q931
>> Received: {
>> q931pdu = {
>> protocolDiscriminator = 8
>> callReference = 22394
>> from = originator
>> messageType = Setup
>> IE: Bearer-Capability = {
>> 88 18 a0 a5 ....
>> }
>> IE: Display = {
>> 66 72 65 64 6c 61 70 74 6f 70 00 fredlaptop.
>> }
>> IE: Calling-Party-Number = {
>> 81 36 38 37 37 .6877
>> }
>> IE: Called-Party-Number = {
>> 81 35 35 38 30 .5580
>> }
>> IE: User-User = {
>> 20 b0 06 00 08 91 4a 00 06 01 01 80 9b aa 22 c0 .....J.......".
>> 09 00 00 3d 0e 54 65 73 74 20 6d 6f 64 5f 68 33 ...=.Test mod_h3
>> 32 33 00 00 1d 31 2e 30 61 6c 70 68 61 31 20 28 23...1.0alpha1 (
>> 48 33 32 33 70 6c 75 73 20 76 31 2e 32 31 2e 30 H323plus v1.21.0
>> 29 00 00 00 01 40 03 00 35 00 35 00 38 00 30 00 )....@..5.5.8.0.
>> ae 4c 6c c2 0b ed e0 11 9f 45 00 90 f5 99 89 f3 .Ll......E......
>> 00 5d 0f 80 07 00 d8 0d 2d 8d 06 b8 11 00 a4 4c .]......-......L
>> 6c c2 0b ed e0 11 9f 45 00 90 f5 99 89 f3 01 00 l......E........
>> 01 00 13 10 00 31 00 30 00 34 00 39 00 5f 00 65 .....1.0.4.9._.e
>> 00 6e 00 64 00 70 01 00 01 00 02 80 01 80 .n.d.p........
>> }
>> }
>> h225pdu = {
>> h323_uu_pdu = {
>> h323_message_body = setup {
>> protocolIdentifier = 0.0.8.2250.0.6
>> sourceAddress = 1 entries {
>> [0]=dialedDigits "6877"
>> }
>> sourceInfo = {
>> vendor = {
>> vendor = {
>> t35CountryCode = 9
>> t35Extension = 0
>> manufacturerCode = 61
>> }
>> productId = 15 octets {
>> 54 65 73 74 20 6d 6f 64 5f 68 33 32 33 00 00 Test
>> mod_h323..
>> }
>> versionId = 30 octets {
>> 31 2e 30 61 6c 70 68 61 31 20 28 48 33 32 33 70 1.0alpha1
>> (H323p
>> 6c 75 73 20 76 31 2e 32 31 2e 30 29 00 00 lus
>> v1.21.0)..
>> }
>> }
>> terminal = {
>> }
>> mc = false
>> undefinedNode = false
>> }
>> destinationAddress = 1 entries {
>> [0]=h323_ID 4 characters {
>> 0035 0035 0038 0030 5580
>> }
>> }
>> activeMC = false
>> conferenceID = 16 octets {
>> ae 4c 6c c2 0b ed e0 11 9f 45 00 90 f5 99 89 f3 .Ll......E......
>> }
>> conferenceGoal = create <<null>>
>> callType = pointToPoint <<null>>
>> sourceCallSignalAddress = ipAddress {
>> ip = 4 octets {
>> d8 0d 2d 8d ..-.
>> }
>> port = 1720
>> }
>> callIdentifier = {
>> guid = 16 octets {
>> a4 4c 6c c2 0b ed e0 11 9f 45 00 90 f5 99 89 f3
>> .Ll......E......
>> }
>> }
>> mediaWaitForConnect = false
>> canOverlapSend = false
>> endpointIdentifier = 9 characters {
>> 0031 0030 0034 0039 005f 0065 006e 0064 1049_end
>> 0070 p
>> }
>> multipleCalls = false
>> maintainConnection = false
>> }
>> h245Tunneling = true
>> }
>> }
>> }
>> 2011/10/04 11:32:38.407 4 ProxyChannel.cxx(2017) Q931s
>> GWRewrite source for 216.13.45.141:20024: setup H323 ID or E164
>> 2011/10/04 11:32:38.407 5 Routing.cxx(196) ROUTING
>> Checking policy Explicit for request Setup CRV=22394
>> 2011/10/04 11:32:38.407 5 Routing.cxx(196) ROUTING
>> Checking policy Internal for request Setup CRV=22394
>> 2011/10/04 11:32:38.407 5 Routing.cxx(196) ROUTING
>> Checking policy SRV for request Setup CRV=22394
>> 2011/10/04 11:32:38.407 5 Routing.cxx(196) ROUTING
>> Checking policy DNS for request Setup CRV=22394
>> 2011/10/04 11:32:38.408 4 Routing.cxx(604) ROUTING DNS
>> policy resolves to 5580 @ 0.0.21.204:1720
>> 2011/10/04 11:32:38.408 5 Routing.cxx(202) ROUTING Policy
>> DNS applied to the request Setup CRV=22394
>> 2011/10/04 11:32:38.408 4 ProxyChannel.cxx(2411) Q931s
>> Unregistered party is not NATed
>> 2011/10/04 11:32:38.408 2 RasTbl.cxx(3412)
>> CallTable::Insert(CALL) Call No. 9, total sessions : 1
>> 2011/10/04 11:32:38.408 2 gkacct.cxx(950) GKACCT
>> Successfully logged event 1 for call no. 9
>> 2011/10/04 11:32:38.408 4 ProxyChannel.cxx(4794) Q931s Set
>> Called Numbering Plan 1 Type Of Number 0
>> 2011/10/04 11:32:38.408 4 ProxyChannel.cxx(4824) Q931s Set
>> Calling Numbering Plan 1 Type Of Number 0
>> 2011/10/04 11:32:38.408 3 ProxyChannel.cxx(2862) Q931s Call 9
>> is NAT type 0
>> 2011/10/04 11:32:38.408 1 ProxyChannel.cxx(870) Call 9:
>> h245Routed=1 proxy=1
>> 2011/10/04 11:32:38.408 3 ProxyChannel.cxx(887) GK Call 9
>> proxy enabled
>> 2011/10/04 11:32:38.409 4 ProxyChannel.cxx(966) Q931 Send to
>> 0.0.21.204:1720 {
>>
>> On 2011-10-04, at 11:21 AM, Jan Willamowius wrote:
>>
>>> Can you post the Setup or ARQ that is triggering the routing process ?
>>> Then we can see which fields GnuGk tries to route on.
>>>
>>> Regards,
>>> Jan
>>>
>>> Fred Gillette wrote:
>>>> The plot thickens...
>>>>
>>>> The packets are arriving at the remote gnugk but it is rejecting the
>>>> incoming call. It seems that it is resolving the call to a mysterious IP
>>>> address.
>>>>
>>>> 2011/10/04 10:49:55.159 4 ProxyChannel.cxx(2017) Q931s GWRewrite
>>>> source for 216.13.45.141:20023: setup H323 ID or E164
>>>> 2011/10/04 10:49:55.160 5 Routing.cxx(196) ROUTING Checking
>>>> policy Explicit for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5 Routing.cxx(196) ROUTING Checking
>>>> policy Internal for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5 Routing.cxx(196) ROUTING Checking
>>>> policy SRV for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5 Routing.cxx(196) ROUTING Checking
>>>> policy DNS for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 4 Routing.cxx(604) ROUTING DNS policy
>>>> resolves to 5580 @ 0.0.21.204:1720
>>>> 2011/10/04 10:49:55.160 5 Routing.cxx(202) ROUTING Policy DNS
>>>> applied to the request Setup CRV=22393
>>>>
>>>> Here is the registration data from the console.
>>>>
>>>> AllRegistrations
>>>> RCF|192.168.1.197:1720|5580:dialedDigits|terminal|6738_endp
>>>> Number of Endpoints: 1
>>>>
>>>> Why would the gnugk resolve 5580 to 5580@0.0.21.204 ???
>>>>
>>>> ..FG..
>>>>
>>>> On 2011-10-04, at 8:36 AM, Jan Willamowius wrote:
>>>>
>>>>> You are looking at the status port which only shows a small number of
>>>>> events. I meant you should create a GnuGk trace:
>>>>> gnugk -c <your config> -ttttt -o trace.log
>>>>>
>>>>> After the call, trace.log will contain a lot more useful hints what
>>>>> GnuGk received and what it did with it.
>>>>> You can also enable such a trace from the status port with "setlog
>>>>> trace.log" and "debug trc 5", but the command line variant is usually
>>>>> easier.
>>>>>
>>>>> Regards,
>>>>> Jan
>>>>>
>>>>> Fred Gillette wrote:
>>>>>> I seem to be only able to set a trace level of 2. See below...
>>>>>>
>>>>>> root@HDPassport1:~# telnet 192.168.217.79 7000
>>>>>> Trying 192.168.217.79...
>>>>>> Connected to 192.168.217.79.
>>>>>> Escape character is '^]'.
>>>>>> Version:
>>>>>> Gatekeeper(GNU) Version(2.3.4)
>>>>>> Ext(pthreads=1,radius=1,mysql=1,pgsql=0,firebird=0,odbc=1,sqlite=1,large_fdset=0,crypto/ssl=1,h46018=0,h46023=1)
>>>>>> H323Plus(1.21.0) PTLib(2.6.7) Build(Jul 14 2011, 15:16:35) Sys(Linux
>>>>>> x86_64 2.6.32-26-generic)
>>>>>> Startup: Mon, 03 Oct 2011 08:23:32 -0400 Running: 0 days 23:36:58
>>>>>> ;
>>>>>> trace 5
>>>>>> Syntax Error: trace 0|1|2|"min"|"max"
>>>>>> trace max
>>>>>> Output trace level is 2
>>>>>> ACF|192.168.217.53:1720|1049_endp|22388|h323:5580@74.199.95.14:url_ID|6877:dialedDigits|false|ce-ea-1b-4a-ee-ec-e0-11-9f-44-00-90-f5-99-89-f3;
>>>>>> DCF|192.168.217.53|1049_endp|22388|normalDrop|ce-ea-1b-4a-ee-ec-e0-11-9f-44-00-90-f5-99-89-f3;
>>>>>>
>>>>>> I'm trying to call 5580@74.199.95.14.
>>>>>>
>>>>>> ..FG..
>>>>>>
>>>>>> On 2011-10-03, at 7:36 PM, Jan Willamowius wrote:
>>>>>>
>>>>>>> You should do a level 5 trace for that call to see which policy GnuGk
>>>>>>> chooses to route the call and which IP it tries to forward the Setup to.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jan
>>>>>>>
>>>>>>> ajgillette98 wrote:
>>>>>>>>
>>>>>>>> I added the suggested entries in my gatekeeper.ini, but there seems to
>>>>>>>> me no
>>>>>>>> difference.
>>>>>>>> If I try to call an H.323 endpoint external to my gnugk with an ip
>>>>>>>> address
>>>>>>>> everything works.
>>>>>>>> If I try to call with an extension and an IP the gnugk does not relay
>>>>>>>> the
>>>>>>>> setup message.
>>>>>>>>
>>>>>>>> I did a wireshark trace and saw the admission request, followed by the
>>>>>>>> admission confirm.
>>>>>>>> Then the setup followed by a release complete. When I dig into the
>>>>>>>> release
>>>>>>>> complete I get
>>>>>>>> a cause value of "No route to destination (3)".
>>>>>>>>
>>>>>>>> If I try calling by IP without the extension the messages go out the
>>>>>>>> public
>>>>>>>> NIC of the gnugk
>>>>>>>> but the far end does not know which endpoint I want to call.
>>>>>>>>
>>>>>>>> ..FG..
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Willamowius wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> if you want GnuGk to resolve DNS names eg. in URLs, you should include
>>>>>>>>> the dns and srv policy in your config. I usually suggest this:
>>>>>>>>>
>>>>>>>>> [RoutingPolicy]
>>>>>>>>> default=explicit,internal,srv,dns,internal,parent,neighbor
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>> ajgillette98 wrote:
>>>>>>>>>>
>>>>>>>>>> Hey Guys,
>>>>>>>>>> I have gnugk working great for calls to devices on the Internet but
>>>>>>>>>> when
>>>>>>>>>> I call gnugk to gnugk I get "calledPartyNotRegistered". I suspect
>>>>>>>>>> that I
>>>>>>>>>> don't understand some aspect of routing? This seems to only happen
>>>>>>>>>> when I
>>>>>>>>>> am
>>>>>>>>>> trying to call a URL xxxx@x.x.x.x if I call an ip address everything
>>>>>>>>>> is
>>>>>>>>>> fine.
>>>>>>>>>>
>>>>>>>>>> My gatekeeper.ini file has the following:
>>>>>>>>>>
>>>>>>>>>> [RoutedMode]
>>>>>>>>>> GKRouted=1
>>>>>>>>>> H245Routed=1
>>>>>>>>>> AcceptUnregisteredCalls=1
>>>>>>>>>> AcceptNeighborsCalls=1
>>>>>>>>>> CallSignalPort=1720
>>>>>>>>>> CallSignalHandlerNumber=1
>>>>>>>>>> RemoveH245AddressOnTunneling=1
>>>>>>>>>> DropCallsByReleaseComplete=1
>>>>>>>>>> SupportNATedEndpoints=1
>>>>>>>>>> SupportCallingNATedEndpoints=1
>>>>>>>>>> Q931PortRange=20000-20099
>>>>>>>>>> H245PortRange=30000-30099
>>>>>>>>>> SendReleaseCompleteOnDRQ=1
>>>>>>>>>>
>>>>>>>>>> [Proxy]
>>>>>>>>>> Enable=1
>>>>>>>>>> InternalNetwork=192.168.216.0/24,10.191.20.0/24
>>>>>>>>>> T120PortRange=50000-59999
>>>>>>>>>> RTPPortRange=50000-59999
>>>>>>>>>> ProxyForNAT=1
>>>>>>>>>> ProxyForSameNAT=0
>>>>>>>>>> ProxyAlways=1
>>>>>>>>>>
>>>>>>>>>> [RoutingPolicy]
>>>>>>>>>> default=explicit,internal
>
> --
> Jan Willamowius, j...@willamowius.de, http://www.gnugk.org/
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________________
>
> Posting: mailto:Openh323gk-users@lists.sourceforge.net
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________________
Posting: mailto:Openh323gk-users@lists.sourceforge.net
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
