> On Tue, Apr 6, 2010 at 7:42 AM, M. Ranganathan > <[email protected]> wrote: > > On Mon, Apr 5, 2010 at 4:40 PM, M. Ranganathan > <[email protected]> wrote: > >> On Mon, Apr 5, 2010 at 4:34 PM, Lazy Burd > <[email protected]> wrote: > >>> checkin 18325 to remove UDP as a listeningPointAddress is causing > >>> the following error in any standard sipxecs installation AFAIK > >>> > >>> > >>> > "2010-04-05T08:02:31.521000Z":42759:JAVA:INFO:systemp01:Timer-7769:0 > >>> 0000000:WaitingForStartState:"WaitingForStartState::start > >>> caught exception: "" > >>> > org.sipfoundry.sipcallwatcher.SubscribeDialog.SubscribeDialogS > tateException: > >>> java.lang.NullPointerException > >>> at > >>> > org.sipfoundry.sipcallwatcher.SubscribeDialog.SubscribeDialog.sendDi > >>> alogFormingSubscribe(SubscribeDialog.java:173) > >>> at > >>> > org.sipfoundry.sipcallwatcher.SubscribeDialog.WaitingForStartState.s > >>> tart(WaitingForStartState.java:14) > >>> at > >>> > org.sipfoundry.sipcallwatcher.SubscribeDialog.SubscribeDialog.start( > >>> SubscribeDialog.java:54) > >>> at > >>> > org.sipfoundry.sipcallwatcher.Subscriber$1.run(Subscriber.java:396) > >>> at java.util.TimerThread.mainLoop(Timer.java:512) > >>> at java.util.TimerThread.run(Timer.java:462) > >>> Caused by: java.lang.NullPointerException > >>> at > >>> > gov.nist.javax.sip.SipProviderImpl.getNewClientTransaction(SipProvid > >>> erImpl.java:397) > >>> at > >>> > org.sipfoundry.sipcallwatcher.Subscriber.sendDialogFormingSubscribe( > >>> Subscriber.java:291) > >>> at > >>> > org.sipfoundry.sipcallwatcher.SubscribeDialog.SubscribeDialog.sendDi > >>> alogFormingSubscribe(SubscribeDialog.java:168) > >>> ... 5 more > >>> > >>> > >> > >> Hello Lazy, > >> > >> Yes - it is a timing issue that needs a fix in > sipxopenfire. Does it > >> affect the overall behavior? > >> It should retry after that. > >> > >> > >> Ranga > > > > Hello! > > > > Sorry! Bad diagnosis from me. > > > > Yes the udp listening point should be put back. Will ping > Bob to do this today. > > > > > > Regards > > > > Ranga > > > After discussion with Bob, it is likely that this conclusion > is in error as well. Please send logs. > > We had a timing issue on startup but that happens only once > on startup and subsequently does not affect the functioning > of sipxopenifre. > SipXopenfire has been quite stable on our trial system. > > > > Thanks. > > Ranga > > > > > >> > >> > >>> > >>> _______________________________________________ > >>> sipx-dev mailing list [email protected] List Archive: > >>> http://list.sipfoundry.org/archive/sipx-dev > >>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > >>> sipXecs IP PBX -- http://www.sipfoundry.org/
Two things: #1 - we need the sipxopenfire log that covers that time when the sipXopenfire process started. The log we have is a repetition of the same error over and over again but does not contain the events that led up to that periodic error. #2 - If your system is still in this error state, could you post the output of 'netstat -nap | grep 5064'. One possibility is that the sipXopenfire process was not able to bind to TCP port 5064 because another process had it. If that were to happen, this condition could lead to the errors you are seeing. Obviously, if that turns out to be the case, we need to improve our handling of that error condition. I you can reproduce the problem at will, could you turn on the logging level to 'DEBUG' and send us those logs? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
