"2011-05-31T19:36:19.881578Z":24:SIP:NOTICE:pbx.voice.mydomain.tld:SipRedirectServer-13:419E4940:SipRegistrar:"ContactList::add(): [100-PICKUP] SipRedirectorPickUp added contact for 'sip:[email protected];sipx-noroute=VoiceMail;sipx-userforward=false':\n '<sip:[email protected];transport=tcp;sipXecs-CallDest=PARK?Route=sip%3A172.16.248.10%3A5120>' (contact index 0)" "2011-05-31T19:36:19.881812Z":25:SIP:NOTICE:pbx.voice.mydomain.tld:SipRedirectServer-13:419E4940:SipRegistrar:"ContactList::set(): [999-AUTHROUTER] SipRedirectorAuthRouter modified contact index 0 for 'sip:[email protected];sipx-noroute=VoiceMail;sipx-userforward=false':\n was: '<sip:[email protected];transport=tcp;sipXecs-CallDest=PARK?Route=sip%3A172.16.248.10%3A5120>'\n now is: '<sip:[email protected];transport=tcp;sipXecs-CallDest=PARK?ROUTE=%3Csip%3Avoice.mydomain.tld%3Blr%3E%2Csip%3A172.16.248.10%3A5120>'"
Why is sipredirector modifying the transport protocol? I think this is what I am seeing. I am not sure if it is problematic or not, but why wouldn't udp be used if the call comes in udp from the gateway and the handset uses udp? The park server changes it to tcp? On Tue, May 31, 2011 at 5:42 PM, Tony Graziano <[email protected]> wrote: > I see a much higher normal number of TCP based transactions on this > system. This started as soon as I started to register a couple of > lines via a snom device (the rest are polycom). > > I did see some tcp based transaction for a park extension in the > registrar log and am wondering how that can be at all? > > I was restarting the registrar every 60 seconds until after i pulled > the plug on the snoms. but it bothers me that a tcp based device can > have the same effect as a dod from inside the network. Now I have a > core dump as well as a snapshot, but they are extremely large. > > Why would a call park be using tcp (the phones involved in the > transaction are all polycom, no remotes, etc. I think the issue is a > two-part problem. 1. snom (though I recall specifically setting them > for udp only, but that was a long time ago). , 2. Why is the park > server using tcp? > > > > On Tue, May 31, 2011 at 1:33 PM, Douglas Hubler <[email protected]> wrote: >> On Tue, May 31, 2011 at 12:53 PM, Tony Graziano >> <[email protected]> wrote: >>> In trying to determine part of this issue, I tried to pull in the >>> sipxrls/commserverlib/sipxconfig packages from the build repo. When I >>> did that the registrar failed and STAYED failed (rest using a stable >>> 4.4.0 repo). >>> >>> If RLS is "not" responsible for the registrar failing, what changes >>> were made to sipxconfig or sipxcommserverlib that would? >> >> There were no obvious fixes that would cause registrar fail since 4.4 >> was initially released. If you can provide access to a snapshot to >> George, Joegen or I we can take a look. >> >> In the meantime, I'm installing the build I sent you and I can run a >> REGISTER/INVITE test at a fairly high call rate to see if i see >> anything as well. >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.326.5325 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Contract Customers: > http://support.myitdepartment.net > Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
