Bump... Robert Kulagowski wrote: > In a followup to my "Routing calls to particular ISDN gateway" thread > from a few days ago, I'm now encountering the following: > > If my RoutingPolicy is: > [RoutingPolicy] > default=explicit,internal,neighbor,sql,enum,srv,dns > > And I have: > [RasSrv::RewriteE164] > 12125551212=310339 > 13129876543=223742 > > and > [RasSrv::Neighbors] > vcs=GnuGK > > [Neighbor::vcs] > GatekeeperIdentifier=vcs > Host=10.244.22.20 > SendPrefixes=* > AcceptPrefixes=* > ForwardLRQ=always > > And the endpoint that I'm trying to call to is registered to a local > gatekeeper which is neighbored to Tandberg VCS then... > > If I dial 12125551212 from an endpoint in Chicago, then the call gets > connected to the endpoint at 310339, even though I dialed 12125551212. > That's good, and the desired behavior. > > But if I change the RoutingPolicy to > [RoutingPolicy] > default=explicit,internal,sql,neighbor,enum,srv,dns > > Then when I place the call, I can see that the number is re-written by > the GnuGk: > > 2009/10/09 14:14:37.770 4 ProxyChannel.cxx(1856) Q931s > GWRewrite source for 10.244.22.21:39456: call record > 2009/10/09 14:14:37.770 2 Toolkit.cxx(695) RewritePString: > 12125551212 to 310339 > 2009/10/09 14:14:37.771 5 ipauth.cxx(266) FileIPAuth > IP 10.244.22.21 accepted for Called 310339 > > and then gets passed off by the SQL policy to the correct gatekeeper, > (10.244.2.5) but that gatekeeper is trying to route the call out to the > ISDN instead of seeing that the 310648 is registered locally: > > 1199275 15:14:09.046 CONNECTION Trace lookup: new call > type: "IP" > 1199276 15:14:09.047 CONNECTION Info Accepting incoming IP > to ISDN call > 1199277 15:14:09.048 CONNECTION Trace 3801i3802a: > conference_participant_set_name "" > 1199278 15:14:09.048 CONNECTION Trace 3801i3802a: > conference_participant_set_e164 "315136" > 1199279 15:14:09.048 CONNECTION Trace 3801i3802a: > conference_participant_set_remote_ip (10.23.10.222) > 1199280 15:14:09.048 CONNECTION Trace 3801i3802a: > set_call_type: Audio and Video > 1199281 15:14:09.048 CONNECTION Trace 3801i3802a: > conference_participant_set_maximum_media_bandwidth; 512000 512000 512000 > 512000 > 1199282 15:14:09.049 CONNECTION Info 3801I3803b : > update_flow_control > 1199283 15:14:09.049 CONNECTION Trace total: 0 kbps > 1199284 15:14:09.049 CONNECTION Trace audio: Null , 0 kbps > 1199285 15:14:09.049 CONNECTION Trace video: Null , 0 kbps > 1199286 15:14:09.049 CONNECTION Trace ext_v: Null , 0 kbps > 1199287 15:14:09.049 CONNECTION Trace 3801i3802a: Incoming > call to E164: "310339" > 1199288 15:14:09.049 CONNECTION Trace 3801i3802a: > conference_participant_incoming_call_info_complete > 1199289 15:14:09.050 DIAL_PLAN Detailed check_condition: > success > 1199290 15:14:09.050 DIAL_PLAN Detailed condition matched > 1199291 15:14:09.050 DIAL_PLAN Trace call "none" > 1199292 15:14:09.050 DIAL_PLAN Trace source "310339", > action: connect call if possible, rule: 2 > 1199293 15:14:09.050 DIAL_PLAN Detailed check_condition: > success > 1199294 15:14:09.050 DIAL_PLAN Detailed condition matched > 1199295 15:14:09.050 DIAL_PLAN Trace call "310339" > 1199296 15:14:09.050 CONNECTION Trace dial plan states max > 768 kbps call > 1199297 15:14:09.050 CONNECTION Trace dial plan states IP > encryption is optional > 1199298 15:14:09.061 CONNECTION Trace generating CDR for > new connection 3801 > > > NOTE HERE THAT IT'S TRYING TO PLACE AN H.320 CALL INSTEAD OF H.323? > > > 1199299 15:14:09.061 CONNECTION Info 3801i3802a: placing > partner call as H.320 to "310339" (BONDING) > 1199300 15:14:09.245 CONNECTION Detailed destroy context: > 0x8F81; try 0x83A30000 > 1199301 15:14:09.245 CONNECTION Detailed destroy context: > 0x8F81; try 0x1CF80 > 1199302 15:14:09.245 CONNECTION Detailed destroy context: > 0x8F81; try 0x811D0001 > 1199303 15:14:09.245 CONNECTION Detailed destroy context: > 0x8F81; try 0x8F81 > 1199304 15:14:09.245 CONNECTION Trace destroy connection > message sent for connection 3801I3803b > 1199305 15:14:09.247 CONNECTION Trace destroy connection > message received for connection 3801I3803b > 1199306 15:14:09.247 CONNECTION Trace 3801I3803b: > conference_participant_destroy (busy) > 1199307 15:14:09.247 CONNECTION Trace generating CDR for > terminating connection 3801 > 1199308 15:14:09.247 CONNECTION Info 3801i3802a: > cm_ensure_participant_disconnecting... 9 > 1199309 15:14:09.247 CONNECTION Trace 3801i3802a: > successfully sent disconnect indication > 1199310 15:14:09.248 CONNECTION Trace Trying to destroy > call pair 3801 > 1199311 15:14:09.248 CONNECTION Trace cannot destroy; call > 3801i3802a is in state "initial" > 1199312 15:14:09.250 CONNECTION Trace 3801i3802a: > conference_participant_set_status_message "Participant busy" > 1199313 15:14:09.250 CONNECTION Trace 3801i3802a: > conference_participant_set_disconnect_info_message "9" > > Shouldn't the GnuGk have generated a LRQ which was sent to the Codian > Gatekeeper? > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________________ 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/
