Hi, The decoded tcpdump of the Setup message indicates the BCIE information transfer rate is set to Multirate (0x18) with a 64Kbps base rate and the Rate multiplier is 134. The binary of 134 is 1000 0110, which parsed per the q931 spec gives us a multiplier of "6", yielding a 384Kbps rate for a 384Kbps call. Now, if the rate is clearly present in the Setup message, why is the default value being used by RasTbl.cxx? -- Mike Ockenga > -----Original Message----- > From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx > [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On > Behalf Of Mike Ockenga > Sent: Tuesday, July 24, 2007 3:54 PM > To: GNU Gatekeeper Users > Subject: Re: Accounting Oddity > > > -----Original Message----- > > From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx > > [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On > Behalf Of > > Zygmuntowicz Michal > > Sent: Tuesday, July 24, 2007 8:29 AM > > To: GNU Gatekeeper Users > > Subject: Re: Accounting Oddity > > > > Unregistered endpoints do not have to report bandwidth usage. > > Try to check contents of Setup message to see if bandwidth > is reported > > by the unregistered endpoint. If no bandwidth report is > received, the > > default 1280 value is being used. > > > > Hi, > > Thanks for the reply. > > This supports my guess that it was inserting the default > because specific bandwidth info was not in the Setup message. > > But I'm still confused. Because A level 5 GnuGK trace AND a > tcpdump both indicate that the registered called party sends > an ARQ with the correct bandwidth request immediately after > receiving the proxied Setup message from the GK. Wouldn't > this indicate that the BW request is available in the Setup message? > > It appears to go as follows: > > 1) GnuGK receives an LRQ from a Cisco MCM GK. > 2) GnuGK sends an LCF to the Cisco GK. > 3) The "unregistered" endpoint (registered to the Cisco GK) > sends a Setup to GnuGK > 4) GnuGK SqlAcct does a StartQuery INSERT with the default BW 1280. > 5) GnuGK proxies the Setup to the locally-registered endpoint. > 6) The called endpoint sends an ARQ to GnuGK with the correct > bandwidth request (7680). > 7) GnuGK sends an ACF to the called endpoint. > > Then the called endpoint sends Alerting and Connect msgs and > the call proceeds as expected. > > BTW, I would update BW on a StopQuery UPDATE, but I need the > correct BW available to query while calls are active for a > bandwidth-based CAC scheme I've cooked up. It works for > calls between locally registered endpoints and when local EPs > call unregistered EPs. > > -- > Mike Ockenga > > > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and > a browser. > Download your FREE copy of Splunk now >> > http://get.splunk.com/ > _______________________________________________________ > > Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: > http://sourceforge.net/mailarchive/forum.php?forum_name=openh3 > 23gk-users > Unsubscribe: > http://lists.sourceforge.net/lists/listinfo/openh323gk-users > Homepage: http://www.gnugk.org/ > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________________ 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/
