Explain how your incoming calls come in? Do you have sip disabled in the sonic wall (you should)?
It means the calls are not being anchored by sipxbridge or something is getting in the way. Transfers use REFER. sipXbridge holds the refer locally (like any SBC) because most any itsps do not support refer. 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/
