You should fix your DNS. On Jan 17, 2012 12:59 PM, "Stiles Watson" <[email protected]> wrote:
> ** > Thanks Tony and Michael. I do need to support remote phones so port 5060 > has to remain open. I've turned connection limiting on in the SonicWall. So > we'll see if that eliminates the problem. Unfortunately, SonicOS only > allows connection limiting based on percentage of total allowed connections > instead of being able to set a specific number so it is set to the minimum > of 1%, which is still around 250 connections/sec. > > I do not have any SRV records at present. I had created them last week > based on the DNS Concepts wiki page ( > http://wiki.sipfoundry.org/display/sipXecs/DNS+Concepts+for+sipXecs), but > I deleted them before the weekend. > > My problem now is that I can not transfer a call at all. If I set the main > DID to the AA, it picks up fine. Then I dial the extension for the Polycom > and the AA says the call is being transfered, but nothing happens. The CDR > reports the call as transfered as well. If I set the main DID directly on > the extension, the call goes through fine and will even transfer to email > if not answered. However, when I'm in v-mail, I can not dial 0 to get to > the operator. I get the same message, "Your call is being transfered," but > then I get dead air - the call is not disconnected. > > Stiles > > > On 01/16/2012 08:10 PM, Michael Picher wrote: > > This sounds like 2 different issues... > > The polycom lock-up... This is a common problem with the polycoms if > your sip domain = your host name and you have srv records configured. > > As tony said, enable some rate limiting on your firewall or don't open > those ports if you don't need them. > On Jan 16, 2012 4:29 PM, "Stiles Watson" <[email protected]> wrote: > >> Long story short, our sipx project was pushed to the back burner about 6 >> months ago. I picked it up again mid-week last week. When I came into >> the office this morning, my Polycom 335 was locked up and then rebooted >> itself. In addition to this, there were some other network anomalies >> which got me investigating what the heck was going on. The >> sipXproxy.log.1 log dated 1/15/2012 is 2.5M even though we initiated no >> call traffic. It is full of entries of call attempts like the one below >> starting systematically with ext 00, 0000, 000000, 01, etc. and going >> through ext 672. They started about 8:20 pm and ended about 9:10pm. >> >> The log entry below reports, mTransactionState: LOCALLY_INITIATED and >> received=199.19.109.190. I could be reading this wrong because, like I >> said, it has been 6 months, but address 199.* is not on our network. >> >> I'm running sipXecs 4.2.1 >> >> "2012-01-15T22:06:55.789708Z":7903:SIP:WARNING:voip.datatek-net.com: >> SipRouter-11:B6DB7B90:SipXProxy:"SipTransaction::handleOutgoing >> invalid relationship: DIFFERENT_BRANCH\nACK sip:[email protected] >> SIP/2.0\r\nVia: SIP/2.0/UDP >> 127.0.0.1:5144 >> ;branch=z9hG4bK-4290799059;rport=5144;received=199.19.109.190\r\nContent-Length: >> 0\r\nFrom: \"671\"<sip:[email protected]>; >> tag=3637310133303331323638353234\r\nAccept: >> application/sdp\r\nUser-Agent: friendly-scanner\r\nTo: >> \"671\"<sip:[email protected]>\r\nContact: >> <sip:[email protected]>\r\nCseq: 1 REGISTER ACK\r\nCall-Id: >> 632667408\r\nMax-Forwards: 20\r\nDate: Sun, 15 Jan 2012 22:06:53 >> GMT\r\n\r\n\n SipTransaction dump:\n this: 0xb51923c8\n >> hash: 632667408c1\n mCallId: 632667408\n mpBranchId->data(): >> z9hG4bK-XX-0ce1U2Fa06ZqoTHTsV6oKtH_HA\n mRequestUri: >> sip:[email protected]\n mSendToAddress: 24.106.178.178\n >> mSendToPort: -1\n mSendToProtocol: UNKNOWN\n >> mCancelReasonValue: \n mpDnsSrvRecords: NULL\n mFromField: >> \"671\"<sip:[email protected]>;tag=3637310133303331323638353234\n >> mToField: \"671\"<sip:[email protected]>\n mRequestMethod: ACK\n >> mCseq: 1\n mIsServerTransaction: FALSE\n mIsUaTransaction: >> FALSE\n mpRequest: (nil)\n mpLastProvisionalResponse: >> (nil)\n mpLastFinalResponse: (nil)\n mpAck: (nil)\n mpCancel: >> (nil)\n mpCancelResponse: (nil)\n mpParentTransaction: >> (nil)\n mChildTransactions: none\n mTransactionCreateTime: >> 181394\n mTransactionStartTime: -1\n mTimeStamp: 181394\n >> mTransactionState: LOCALLY_INITIATED\n mIsCanceled: FALSE\n >> mIsRecursing: FALSE\n mIsDnsSrvChild: FALSE\n >> mProvisionalSdp: FALSE\n mQvalue: 1.000000\n mExpires: -1\n >> mIsBusy: 181394\n mBusyTaskName: SipRouter-11\n mWaitingList: >> (nil)" >> >> In the current sipXproxy.log, I have lots of the following: >> >> "2012-01-16T21:02:19.767920Z":7968:SIP:ERR:voip.datatek-net.com: >> SipRouter-11:B6DB7B90:SipXProxy:"SipUserAgent::send >> outgoing call 1" >> "2012-01-16T21:07:34.487367Z":7969:KERNEL:NOTICE:voip.datatek-net.com: >> SipClientTcp-144:FFFFFFFF:SipXProxy:"OsMsgQShared::doSendCore >> message queue 'SipTcpServer-3' is over half full - count = 91, max = 100" >> >> Any clues? >> >> Stiles Watson >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > _______________________________________________ > sipx-users mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
