Glen Sykes wrote:
> Hi Robert,
>
> The Tandberg VCS Control or Tandberg GK which have an inbuilt H.460
> client should be able to register with GnuGK's H.460 server as it's
> all standards based. Inbound is taken care of in H.460, as the
> client sends keepalives to the server ensuring an inbound call alerts
> on the client if that's how you choose to route the call.
>
Would this support allow the GnuGK to act as an outbound IP path? I'm
trying to determine if the GnuGK running 2.3.1 CVS can be configured as
a Traversal Server (with VCS as Traversal Client) so that an endpoint
which is registered to VCS can make calls dialed to an external IP address.
Or maybe that's not the correct approach...
In VCS, I've configured a neighbor zone called "GnuGK", and configured a
pattern-match of "#", which I then strip before sending to the GnuGK. I
have an endpoint which is registered to VCS and dialed #208.189.200.100
On a level-5 trace, it looks like this:
2009/08/20 13:02:55.164 4 RasSrv.cxx(230) RAS
Receiving on 10.23.10.222:1719(U)
2009/08/20 13:02:55.164 2 RasSrv.cxx(189) RAS Read
from 10.244.22.20:1719
2009/08/20 13:02:55.164 3 RasSrv.cxx(238) RAS
locationRequest {
requestSeqNum = 31595
destinationInfo = 1 entries {
[0]=h323_ID 15 characters {
0032 0030 0038 002e 0031 0038 0039 002e 208.189.
0032 0030 0030 002e 0031 0030 0031 200.101
}
}
replyAddress = ipAddress {
ip = 4 octets {
0a f4 16 14 ....
}
port = 1719
}
sourceInfo = 1 entries {
[0]=h323_ID 3 characters {
0076 0063 0073 vcs
}
}
canMapAlias = true
genericData = 1 entries {
[0]={
id = nonStandard 16 octets {
dd 4a ad ab 21 b6 11 dd 89 65 00 50 56 c0 00 08
.J..!....e.PV...
}
parameters = 2 entries {
[0]={
id = nonStandard 16 octets {
dd 4a ad ac 21 b6 11 dd 89 65 00 50 56 c0 00 08
.J..!....e.PV...
}
content = raw 16 octets {
1a 2b 10 2c 3a 1d 11 b2 b0 7f 00 10 f3 0f 6f ec
.+.,:.........o.
}
}
[1]={
id = nonStandard 16 octets {
dd 4a ad b1 21 b6 11 dd 89 65 00 50 56 c0 00 08
.J..!....e.PV...
}
content = raw 119 octets {
56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 Via:
SIP/2.0/UDP
20 31 30 2e 32 34 34 2e 32 32 2e 32 30 3b 62 72
10.244.22.20;br
61 6e 63 68 3d 48 33 32 33 2e 36 63 37 64 34 30
anch=H323.6c7d40
62 39 32 34 39 64 34 62 62 63 61 64 30 39 35 31
b9249d4bbcad0951
64 62 35 36 38 30 34 32 31 36 0d 0a 56 69 61 3a
db56804216..Via:
20 53 49 50 2f 32 2e 30 2f 55 44 50 20 31 30 2e
SIP/2.0/UDP 10.
32 34 34 2e 32 32 2e 32 34 3b 62 72 61 6e 63 68
244.22.24;branch
3d 48 33 32 33 0d 0a =H323..
}
}
}
}
}
hopCount = 15
callIdentifier = {
guid = 16 octets {
1a 2b 98 c6 3a 1d 11 b2 8e 8b 00 10 f3 0f 6f ec .+..:.........o.
}
}
sourceEndpointInfo = 2 entries {
[0]=h323_ID 6 characters {
0043 0046 004f 0020 004d 0043 CFO MC
}
[1]=dialedDigits "353825"
}
}
2009/08/20 13:02:55.164 5 job.cxx(364) JOB Worker
threads: 10 total - 10 busy, 0 idle
2009/08/20 13:02:55.164 5 job.cxx(190) JOB Starting
Job LRQ at Worker thread 3075439504
2009/08/20 13:02:55.164 1 RasSrv.cxx(368) RAS LRQ
Received from 10.244.22.20:1719
2009/08/20 13:02:55.164 5 Routing.h(177) ROUTING Checking
policy Explicit for the request LRQ 31595
2009/08/20 13:02:55.164 5 Routing.h(177) ROUTING Checking
policy Internal for the request LRQ 31595
2009/08/20 13:02:55.164 5 Routing.h(177) ROUTING Checking
policy Neighbor for the request LRQ 31595
2009/08/20 13:02:55.165 5 Routing.h(177) ROUTING Checking
policy ENUM for the request LRQ 31595
2009/08/20 13:02:55.165 4 Routing.cxx(1323) ROUTING Policy
ENUM not supported for LRQ
2009/08/20 13:02:55.165 5 Routing.h(177) ROUTING Checking
policy SRV for the request LRQ 31595
2009/08/20 13:02:55.165 4 Neighbor.cxx(1531) ROUTING Policy
SRV not supported for LRQ
2009/08/20 13:02:55.165 5 Routing.h(177) ROUTING Checking
policy DNS for the request LRQ 31595
2009/08/20 13:02:55.165 4 Routing.cxx(611) ROUTING Policy
DNS not supported for LRQ
2009/08/20 13:02:55.165 2 RasSrv.cxx(408)
LRJ|10.244.22.20|208.189.200.101:h323_ID
2009/08/20 13:02:55.165 3 RasSrv.cxx(250) RAS Send to
10.244.22.20:1719
locationReject {
requestSeqNum = 31595
rejectReason = requestDenied <<null>>
}
So it seems like the issue is that the GnuGK is getting a destination of
"208.189.200.101" which it's looking up in it's local table rather than
acting as a proxy and establishing a connection to the IP address.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
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/
