RE: [reSIProcate] UdpTransport problem
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
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>