Re: [GnomeMeeting-devel-list] Re: I GOT THE PROBLEM! :) :) :)

[Damien Sandras <dsandras seconix com>]

Hello!

First of all, nice catch!

Le jeudi 14 avril 2005 à 11:52 +0200, Jan Schiefer a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I don't receive this hello corruption every time. There are also correct
> invites.
> 
> But one thing is really, really wired:
> 
> I do an cout << transport.rdbuf() << endl; after
> 
> #if defined(__MWERKS__) || (__GNUC__ >= 3) || (_MSC_VER >= 1300)
> if (transport.rdbuf()->pubseekoff(0, ios_base::cur) == streampos(_BADOFF))
> #else
> if (transport.rdbuf()->seekoff(0, ios::cur, ios::in) == EOF)
> #endif
> transport.clear(ios::badbit);
> 
> in BOOL SIP_PDU::Read(OpalTransport & transport) and i get:
> 
> INVITE sip:03419899434 195 158 171 101:5061;user=phone SIP/2.0
> From: <sip:anonymous 213 148 136 2;user=phone>;tag=aa8d4815
> To: <sip:03419899434 195 158 171 101;user=phone>
> CSeq: 1 INVITE
> Call-ID: d820fc5ab2bb9296b85e8d5724028918 sx3000
> Via: SIP/2.0/UDP 213.148.136.2:5060;branch=z9hG4bK65df926ab
> Allow:
> INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER
> Max-Forwards: 16
> Supported: 100rel
> Contact: <sip:anonymous 213 148 136 2:5060;user=phone>
> Privacy: user
> Content-Length: 316
> Content-Type: application/sdp
> 
> v=0
> o=HuaweiSoftX3000 90321 90321 IN IP4 213.148.135.2
> s=Sip Call
> c=IN IP4 213.148.136.2
> t=0 0
> m=audio 62276 RTP/AVP 18 8 0 4 97 96
> a=rtpmap:18 G729/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:4 G723/8000
> a=rtpmap:97 telephone-event/8000
> a=rtpmap:96 red/8000
> a=fmtp:97 0-15
> a=fmtp:96 97/97
> 
> This if fully correct.
> 
> BUT just after this transport.good() FAILS!!!
> Wtf???
> 
> So the REAL PROBLEM is:
> 
> #if defined(__MWERKS__) || (__GNUC__ >= 3) || (_MSC_VER >= 1300)
>   if (transport.rdbuf()->pubseekoff(0, ios_base::cur) == streampos(_BADOFF))
> #else
>   if (transport.rdbuf()->seekoff(0, ios::cur, ios::in) == EOF)
> #endif
>     transport.clear(ios::badbit);
> 
> doesn't work's correctly. The "bad bit" ( yeah ,really the BAD bit ) has
> to be cleared at invite. But this doesn't happen.

For now I don't really know how to debug this.

I think the problem is the following :
- it receives the "hello" from your provider
- the PDU is invalid
- transport is not good
- it returns with this :
"SIP\tPDU Read failed: " <<
transport.GetErrorText(PChannel::LastReadError));

- it receives the INVITE
- the hello is still in the buffer of OPAL
- the transport is still marked as not good
- it returns

I think the transport is erroneouosly marked as not good.
It should stay "good", and fail because the "hello" is not a correct
PDU.
-- 
 _      Damien Sandras
(o-     GnomeMeeting: http://www.gnomemeeting.org/
//\     FOSDEM 2005 : http://www.fosdem.org
v_/_    H.323 phone : callto:ils.seconix.com/dsandras seconix com