On Thu, Apr 3, 2008 at 3:21 PM, Michael Broughton <Michael_Broughton at advanis.ca> wrote: > > Just to get the feel of what's happening, can you print the following in > gdb: > > > > - (pjsip_transaction*) tsx > > - (pjsip_rx_data*) rdata > > - (pjsip_inv_session*) dlg->mod_data[7] > > - (struct dlg_data*) dlg->mod_data[5] (dlg_data is private structure > > in sip_100rel.c) > > > > Attached. > Thanks, I'll look into it a bit later (it looks like time consuming :) ). But I notice that the offending transaction is a PRACK, so at least we know that it's not a plain vanilla SIP call. > > Honestly, I didn't see anything unusual this time. > > The last time I saw this crash it was a little unusual. I think I had about > four or five of my survey processes dialing 30 phone lines each. Three of > the processes coredumped with this same assertion failure, all within thirty > seconds of each other. This makes me wonder if there is some external force > at work... perhaps it is our Avaya SIP server. > > Notice the 408 request timeout... our SIP server often returns this status > code for phone numbers that are out of service. However, it does it for > other unexplained reasons as well. I really need to set up SER... > > > Do you have libuuid-dev installed? (see > http://trac.pjsip.org/repos/ticket/412) > > > > No I don't think so. Would this be even more important for high calling > volume? > Yep, this would be extremely important for high volume of calls. Without this, there is a possibility that two ongoing transactions will have the same Via branch with high volume of calls, which I imagine would cause something to break. If you can't use libuuid, maybe you can upgrade to later revisions where the uid generation has been improved? Cheers Benny
