Take a look at a level 5 trace of the call how the VCS rewrites the call destination. There are multiple possibilities where it may put the destination IP. Regards, Jan Sébastien Bonnaire wrote: > Thank you jan for your answer. > > I followed every recommandation, but situation is still the same : > - a System Registered to the traversal server uses the "explicit" policy > - a System Registered to the vcs control : its call is routed correctly to the gnugk (traversal server) but then the gnugk uses the dns policy to route the call > > Note : when using the dns policy the h323id is filled with the dialed string. That prevents me to route calls to RADVISION MCU > > Thanks for your answers. > > Sebastien > > Le 19 mars 2013 à 08:19, Jan Willamowius <jan@xxxxxxxxxxxxxx> a écrit : > > Hi Sebastien, > > sending IP calls through a traversal server works, but you have to make > sure the internal gatekeeper has the 'explicit' policy _after_ the > 'neighbor' policy. Otherwise it will try to handle all IP calls by > itself (which is bound to fail). > > You should also include the SendIPs= switch in the [Neighbor::] > section to configure which IP ranges you want to send through the > traversal zone. > > Regards, > Jan > > -- > Jan Willamowius, Founder of the GNU Gatekeeper Project > EMail : jan@xxxxxxxxxxxxxx > Website: http://www.gnugk.org > Support: http://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 > > > Sébastien Bonnaire wrote: > > Hi, > > > > In my configuration, i've got the following : > > Endpoint ---> Tandberg VCS ---(H460.18)---> GNUGK Traversal Server ---> > > public IP Address > > > > The GNUGK version is 3.1.0, the same problem appears in 3.2.0 version. > > The GNUGK configuration is the following : > > > > [RoutingPolicy] > > default=internal,explicit,neighbor,dns > > > > [RasSrv::Neighbors] > > GKinternal=Generic > > > > [Neighbor::GKinternal] > > GatekeeperIdentifier=GKinternal > > Host=xxx.xxx.xxx.xxx > > Dynamic=1 > > AcceptPrefixes=* > > H46018Client=0 > > H46018Server=1 > > AuthUser=intgk > > ;Password=intgk > > > > First of all, i should disable password for the H.460.18 connection because > > the VCS do not send authentication within the LRQ. > > Then, i was able to do outgoing calls to public IP address (to a codian MCU > > or a regular Endpoint), but some services are not accepting my calls. This > > problem is not appearing on the endpoint locally registered to GNUGK. > > > > After a search into logs and Tcpdump, i was able to find the problem : > > - the RoutingPolicy used for any call to a public IP address from the GNUGK > > is "explicit" => that's what i was expecting > > - the RoutingPolicy used for any call to a public IP address from my VCS is > > "dns" => that's a surprise > > => when looking at the Tcpdump trace i can see the setup going out with > > an H323-ID destinationinfo set to "ip$yyy.yyy.yyy.yyy:1720" which seams to > > be refused by the remote party. > > > > Would you be kind enough to tell me if i can tweak my configuration to > > remove this H323-ID for this particular destination ? > > > > Best regards, -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________________ 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/
