Robert Kulagowski wrote:
> On Tue, Feb 7, 2012 at 4:00 PM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote:
> > every H.323 calls has 2 fields to specify the destination and they can
> > be used alone or together: The destination IP and the destination alias
> > list.
> >
> > The user interfaces of different endpoints used different ways to allow
> > the user to fill the fields. The standard (Annex O) way, that is for
> > example used by Tandberg is <alias>@<ip>. Polycom and LifeSize use
> > <ip>##<alias>.
> >
> > The ## is nothing a gatekeeper has to deal with. It sees the raw
> > protocol messages and looks at destination IP and alias list if they
> > are provided.
> >
> > In addition to that some Polycoms have a bug that they disregard the IP
> > when they are registered to a gatekeeper, but thats a different story.
>
> Then is that the bug that I encountered? Here's the trace at the Gatekeeper:
>
> 2012/02/07 15:26:32.207 3 RasSrv.cxx(227) RAS
> admissionRequest {
> requestSeqNum = 18224
> callType = pointToPoint <<null>>
> callModel = gatekeeperRouted <<null>>
> endpointIdentifier = 9 characters {
> 0038 0031 0038 0037 005f 0065 006e 0064 8187_end
> 0070 p
> }
> destinationInfo = 1 entries {
> [0]=dialedDigits "770335"
> }
> srcInfo = 2 entries {
> [0]=h323_ID 9 characters {
> 006d 0065 006c 0062 006f 0075 0072 006e melbourn
> 0065 e
> }
> [1]=dialedDigits "61396507466"
> }
> bandWidth = 10240
> callReferenceValue = 29902
> conferenceID = 16 octets {
> 02 36 1b 23 1c 48 7a 1b 0c 8e 21 46 07 34 5d d3 .6.#.Hz...!F.4].
> }
> activeMC = false
> answerCall = false
> canMapAlias = true
> callIdentifier = {
> guid = 16 octets {
> 02 36 1b 23 1c 48 7a 1b 0c 8d 21 46 07 34 5d d3 .6.#.Hz...!F.4].
> }
> }
> gatekeeperIdentifier = 3 characters {
> 0067 006b 0031 gk1
> }
> willSupplyUUIEs = false
> featureSet = {
> replacementFeatureSet = false
> supportedFeatures = 1 entries {
> [0]={
> id = standard 9
> }
> }
> }
> }
>
> But the endpoint "called" shows:
> 206.83.160.33##770335 08/Feb/2012 08:26:32 Out
Yes, that the bug. The ARQ doesn't contain the IP 206.83.160.33 at all,
so GnuGk has no way to route the call there.
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
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________________
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/
