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=b27e1a1d33761e85846fc98f5f3a7e58.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
> > > >
> > >
> > >
> >
>
>