RE: [reSIProcate] UdpTransport problem
I believe I've found the problem...
in TransactionState.cxx, there is the following code block:
else if (isResponse(msg) && isFromWire(msg)) // from the wire
{
//StackLog (<< "received response from wire");
SipMessage* sip = dynamic_cast<SipMessage*>(msg);
int code = sip->header(h_StatusLine).responseCode();
if (code >= 100 && code < 200) // 1XX
{
if (mState == Trying || mState == Proceeding)
{
mState = Proceeding;
if (!mIsReliable)
{
mController.mTimers.add(Timer::TimerE2, mId, Timer::T2 );
}
sendToTU(msg); // don't delete
}
else
{
// ignore
delete msg;
}
}
else if (code >= 200)
{
// don't notify the TU of retransmissions
if (mState == Trying || mState == Proceeding)
{
sendToTU(msg); // don't delete
}
else if (mState == Completed)
{
delete msg;
}
if (mIsReliable)
{
terminateClientTransaction(mId);
delete this;
}
else if (mState != Completed) // prevent TimerK reproduced
{
mState = Completed;
mController.mTimers.add(Timer::TimerK, mId, Timer::T4
);
}
}
}
If we receive a 200, and the state is "completed", we don't pass the
message along to the TU... is this the correct behavior? I would think
even 200s completing a transaction should be passed up to the UA.
--Sharon
On Mon, 2004-08-09 at 12:35, Jason Fischl wrote:
> It looks like you are receiving messages that are not SipMessages from the
> SipStack. Have you called SipStack::registerForTransactionTermination?
> Alternatively, have you called any of the SipStack::post methods? If so, you
> will need to call SipStack::receiveAny instead of SipStack::receive and then
> use a dynamic_cast to SipMessage*.
>
> e.g.
>
> while ( !received )
> {
> FdSet mFdset;
> myStack.buildFdSet(mFdset);
> int ret =
> mFdset.selectMilliSeconds(myStack.getTimeTillNextProcessMS());
> if (ret >= 0)
> {
> myStack.process(mFdset);
> }
>
> if ( myStack.hasMessage() )
> {
> Message* msg = myStack.receive();
> received = dynamic_cast<SipMessage*>(msg);
> if (received == 0) delete msg; // avoid leaking
> }
> }
>
>
> Jason
>
>
> > -----Original Message-----
> > From: sharon paisner [mailto:spaisner@xxxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Monday, August 09, 2004 6:42 AM
> > To: Jason Fischl
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] UdpTransport problem
> >
> >
> > I adjusted my loop so that the FDSet was constructed inside the loop.
> > The code block is as follows:
> >
> > while ( !received )
> > {
> > FdSet mFdset;
> > myStack.buildFdSet(mFdset);
> > int ret =
> >
> > mFdset.selectMilliSeconds(myStack.getTimeTillNextProcessMS());
> > if (ret >= 0)
> > {
> > myStack.process(mFdset);
> > }
> >
> > if ( myStack.hasMessage() )
> > received = myStack.receive();
> > }
> >
> > We discovered that the "rejecting datagram as unparsable" error was
> > being caused by the NAT pings keeping the channel open, and when we
> > turned that off, we stopped getting the error. However, I'm still unable
> > to get the 200 OK from the stack.
> >
> > Any suggestions?
> >
> > the debug logs looks like this for the 200 OK message:
> >
> > DEBUG | 20040806-172044.014 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSPORT | 29421 | 1453398960 | Transport.cxx:374 | incoming
> > from: [ V4 192.168.10.105:5060 UDP received on: Transport: [ V4
> > 0.0.0.0:5080 UDP connectionId=0 ] connectionId=0 ]
> > STACK | 20040806-172044.015 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSPORT | 29421 | 1453398960 | Transport.cxx:375 |
> > SIP/2.0 200 OK - updated subscriber registration
> > To:
> > <sip:caller_0@xxxxxxxxxxxxxx:5060>;tag=b27e1a1d33761e85846fc98f5f3
> > a7e58.cdae
> > From: <sip:called_0@xxxxxxxxxxxx:5080>;tag=6dec747d
> > Via: SIP/2.0/UDP
> > 192.168.10.4:5080;branch=z9hG4bK-c87542-869942051-1--c87542-;rport=5080
> > Call-ID: 5b1dc26d96126a13
> > CSeq: 1 REGISTER
> > Server: Sip EXpress router (0.8.99-dev (i386/linux))
> > Content-Length: 0
> > P-Behind-NAT: Yes
> >
> >
> > STACK | 20040806-172044.015 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:125 |
> > Found matching transaction for SipResp: 200 tid=869942051 cseq=REGISTER
> > / 1 from(wire) -> tid=869942051 [ ClientNonInvite/Completed unreliable
> > target=[ V4 0.0.0.0:0 UNKNOWN_TRANSPORT connectionId=0 ]]
> > STACK | 20040806-172044.015 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:366 |
> > TransactionState::processClientNonInvite: SipResp: 200 tid=869942051
> > cseq=REGISTER / 1 from(wire)
> > STACK | 20040806-172044.489 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:125 |
> > Found matching transaction for Timer: Timer E1 500 -> tid=869942051 [
> > ClientNonInvite/Completed unreliable target=[ V4 0.0.0.0:0
> > UNKNOWN_TRANSPORT connectionId=0 ]]
> > STACK | 20040806-172044.490 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:366 |
> > TransactionState::processClientNonInvite: Timer: Timer E1 500
> > STACK | 20040806-172049.008 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:125 |
> > Found matching transaction for Timer: Timer K 5000 -> tid=869942051 [
> > ClientNonInvite/Completed unreliable target=[ V4 0.0.0.0:0
> > UNKNOWN_TRANSPORT connectionId=0 ]]
> > STACK | 20040806-172049.008 | spaisner.bridgeport-networks.com | stix |
> > RESIP:TRANSACTION | 29421 | 1453398960 | TransactionState.cxx:366 |
> > TransactionState::processClientNonInvite: Timer: Timer K 5000
> > stix: SipStack.cxx:291: resip::SipMessage* resip::SipStack::receive():
> > Assertion `0' failed.
> > Aborted
> >
> >
> > --Sharon
> >
> > On Fri, 2004-08-06 at 16:36, Jason Fischl wrote:
> > > It looks like the 200 OK is being received and processed by the stack.
> > > However, it looks like the filedescriptor for the UDP transport
> > (read set)
> > > is still in the FdSet. What does your main loop with the select
> > call in it
> > > look like?
> > >
> > > Do you create a new FdSet before each call to buildFdSet. e.g.
> > >
> > > while (1)
> > > {
> > > FdSet fdset;
> > > stack.buildFdSet(fdset);
> > > int ret = fdset.selectMilliseconds(stack.getTimeTillNextProcessMS());
> > > if (ret >= 0)
> > > {
> > > stack.process(fdset);
> > > }
> > > }
> > >
> > > If you defined the FdSet outside the loop, you might see this behavior.
> > >
> > > Jason
> > >
> > >
> > > > STACK | 20040806-161216.154 |
> > spaisner.bridgeport-networks.com | stix |
> > > > RESIP:TRANSPORT | 28812 | 1453398960 | Transport.cxx:375 |
> > > > SIP/2.0 200 OK - updated subscriber registration
> > > > To:
> > > > <sip:caller_0@xxxxxxxxxxxxxx:5060>;tag=b27e1a1d33761e85846fc98f5f3
> > > > a7e58.1939
> > > > From: <sip:called_0@xxxxxxxxxxxx:5080>;tag=b31d6c10
> > > > Via: SIP/2.0/UDP
> > > >
> > 192.168.10.4:5080;branch=z9hG4bK-c87542-380322371-1--c87542-;rport=5080
> > > > Call-ID: cfd2997689ab4f3f
> > > > CSeq: 1 REGISTER
> > > > Server: Sip EXpress router (0.8.99-dev (i386/linux))
> > > > Content-Length: 0
> > > > P-Behind-NAT: Yes
> > > >
> > > >
> > >
> > > > RESIP:TRANSPORT | 28812 | 1453398960 | UdpTransport.cxx:159 | Scanner
> > > > rejecting datagram as unparsable / fragmented from [ V4
> > > > 192.168.10.105:5060 UDP received on: Transport: [ V4 0.0.0.0:5080 UDP
> > > > connectionId=0 ] connectionId=0 ]
> > > > DEBUG | 20040806-161235.887 |
> > spaisner.bridgeport-networks.com | stix |
> > > > RESIP:TRANSPORT | 28812 | 1453398960 | UdpTransport.cxx:160 |
> > > >
> > > > --Sharon
> > > >
> > > >
> > > > On Fri, 2004-08-06 at 15:41, Jason Fischl wrote:
> > > > > Can you rerun your test program, run it with LOG_STACK and
> > post the log
> > > > > results. It might also help if you provided an ethereal capture
> > > > file (pcap)
> > > > > of the SIP packets.
> > > > >
> > > > > Thanks,
> > > > > Jason
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > > > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of
> > > > > > sharon paisner
> > > > > > Sent: Friday, August 06, 2004 12:31 PM
> > > > > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > Subject: [reSIProcate] UdpTransport problem
> > > > > >
> > > > > >
> > > > > > I've recently upgraded my resiprocate code to the latest
> > from svn. Now
> > > > > > "200 REGISTER" responses are being discarded by the
> > > > UdpTransport as wish
> > > > > > the error:
> > > > > >
> > > > > > | UdpTransport.cxx:159 | Scanner rejecting datagram as
> > unparsable /
> > > > > > fragmented
> > > > > >
> > > > > > Can anyone tell me what's going on? release 0.4.0 was
> > able to parse
> > > > > > these messages.
> > > > > >
> > > > > > thanks,
> > > > > > Sharon
> > > > > >
> > > > > > _______________________________________________
> > > > > > resiprocate-devel mailing list
> > > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>