As far as I can remeber - it always did. The problem is that some Cisco IOS versions report problems and some not, so maybe that is the reason it went unnoticed so long. ----- Original Message ----- From: <Ian.Campbell@xxxxxxxxxx> Sent: Tuesday, May 25, 2004 11:55 AM > Michal, > When did the code actually start doing this? > > Ian > > -----Original Message----- > From: Zygmuntowicz Michal [mailto:m.zygmuntowicz@xxxxxxx] > Subject: Re: Bad Non standard data in ACF > > It should be already fixed in the cvs (I commited a fix a few days ago). > Copying nonStandardData fields to reply messages is obviously not the best > idea. > > ----- Original Message ----- > From: <Ian.Campbell@xxxxxxxxxx> > Sent: Tuesday, May 25, 2004 11:29 AM > > > > Hello, > > I have been having a problem with the GnuGK interaction with our > > Cisco gateway. The problem is bad non standard data in the ACF message > > returned by the GnuGK causing a parsing error when the message is received > > by the Cisco, the relevant debug trace is below: > > > > May 14 10:40:43.354: RAS INCOMING ENCODE BUFFER::= > > 2B80203940050040D5A6090306B80 > > 07740B5000012078000000E8001C31400C001000B8001F80100010001000100 > > May 14 10:40:43.358: > > May 14 10:40:43.358: RAS INCOMING PDU ::= > > > > value RasMessage ::= admissionConfirm : > > { > > requestSeqNum 8250 > > bandWidth 1280 > > callModel gatekeeperRouted : NULL > > destCallSignalAddress ipAddress : > > { > > ip 'D5A60903'H > > port 1720 > > } > > irrFrequency 120 > > nonStandardData > > { > > nonStandardIdentifier h221NonStandard : > > { > > t35CountryCode 181 > > t35Extension 0 > > manufacturerCode 18 > > } > > data '8000000E8001C3'H > > } > > willRespondToIRR FALSE > > uuiesRequested > > { > > setup FALSE > > callProceeding FALSE > > connect FALSE > > alerting FALSE > > information FALSE > > releaseComplete FALSE > > facility FALSE > > progress FALSE > > empty FALSE > > status FALSE > > statusInquiry FALSE > > setupAcknowledge FALSE > > notify FALSE > > } > > } > > > > > > > > May 14 10:40:43.358: H225 NONSTD INCOMING ENCODE BUFFER::= 8000000E8001C3 > > May 14 10:40:43.358: fld 'gtd'(type:_choice_ACFnnStndrdInf_gtd) of > > ACFnonStandardInfo DEC_ERR=-13 > > > > May 14 10:40:43.358: RAS OUTGOING PDU ::= > > > > value RasMessage ::= unknownMessageResponse : > > { > > requestSeqNum 8250 > > } > > > > After this sequence the call then fails. The relevant code in GnuGK just > > copies the non standard data from the incoming ARQ to the outgoing ACF: > > > > confirm.m_requestSeqNum = request.m_requestSeqNum; > > if (non_standard) { > > CopyNonStandardData(request, confirm); > > } > > return m_msg->m_replyRAS; > > > > in RasSrv.cxx. I've fixed this temporarily by preventing the code from > > copying the non standard data into the ACF and everything works ok. I was > > wondering if anybody else has had this problem? > > > > Cheers, > > > > Ian Campbell > > Band-X Ltd. ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
