I would not put much emphasis on the item you looked up. If the call was not acked it means there was a sip trace or pcap associated in order to make that determination.
If the call is coming in FROM the ITSP using sipxbridge as a trunk manager, whether you are REGISTERED or NOT, it should send to port 5080 (the invite from the ITSP with the DID would show the destination port 5080). You really ought to spend some time and generate a pcap or sip trace or verify with the provider that this is where they are sending it and that your firewall is not transforming port 5080 to port 5060. Also if you have multiple wan ports, I find flowroute very impractical to work with. Why? The media will come from different providers (i.e. level3, etc.) and even though you register to them it's problematic to ensure the media does not follow the gateway (with flowroute it does not). So all of this would be observable with a PCAP file (or siptrace). It could also be your firewall is locked down tight enough (usually a good thing), but again, flowroute's lack of a network makes them a posterchild of why "not" to use them. There is nothing "wrong" with how they do this, but it makes it very hard to ensure the media follows the correct route and impossible to setup firewall acl's and such in an enterprise environment to guarantee much. With a single WAN (like our lab system) it works and functions, that's all. If multi wan is your thing, get theee to another provider. Do us all a favor and get a pcap or siptrace, ok? On Wed, Mar 21, 2012 at 12:29 PM, Stiles Watson <[email protected]>wrote: > While searching the old messages on this list to see if I can get any > insight on this issue, I found this 2010 note from Tony Graziano in a > response to a different question: > > "It means they are not acking the call. I suspect this is because > sipxbridge may not be involved in the call, and only sipxproxy is, which > would be problematic for a lot of call scenarios (like transfers)." > > This seems related to my issue. I see log entries in sipXproxy.log for the > failed transfers, but I do not see anything in sipxbridge.log. Mostly I > just see keep-alive records for flowroute (US and CANADA) and callwithus > (for international calls only). It could be I do not understand what to > look for... > > Anyway, how would sipxbridge "not be involved in the call" and how do I > check to see if it is or not and how do I fix it? > > At this point the only thing that does not work are incoming calls > answered by the AA can not transfer to an ext. The CDR says the call was > transfered, but it is. Calling out works, and ext to ext works. > > Stiles > > > On 03/21/2012 11:18 AM, Stiles Watson wrote: > > OK, thanks. DNS is running on the sipXecs server. > > I re-installed and used the fully qualified domain during the setup. The > auto generated DNS zone file is correct and all the tests pass. > > However, I still have the initial problem of not being able to transfer to > an incoming call to an ext from the Auto Attendant. > > Below is the contents of sipXproxy.log for the call. Some things that I > noticed are > > - repeated warnings of "missing 'signature' param" > - DNS query for name '_sip._tls.voip.datatek-net.com', type = 33 > (SRV): returned error ----->This SRV record is not in the zone file, is > this something needed by polycom phones? > - KERNEL:ERR ... doSendCore message send failed for queue > 'SipTcpServer-3' - no room, ret = 9 > > sipXproxy.log: > > "2012-03-21T14:59:18.826072Z":756:SIP:WARNING:voip.datatek-net.com:SipXProxyCseObserver-10:B77FAB90:SipXProxy:"SipXauthIdentity::decode > '<sip:[email protected]> <sip:[email protected]>' > missing 'signature' param" > "2012-03-21T14:59:18.827981Z":757:SIP:WARNING:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipXauthIdentity::decode > '<sip:[email protected]> <sip:[email protected]>' > missing 'signature' param" > "2012-03-21T14:59:18.829672Z":758:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T14:59:18.857719Z":759:SIP:WARNING:voip.datatek-net.com:SipSrvLookupThread-14:B6A74B90:SipXProxy:"DNS > query for name '_sip._tls.voip.datatek-net.com', type = 33 (SRV): > returned error" > "2012-03-21T14:59:18.867593Z":760:SIP:WARNING:voip.datatek-net.com:SipXProxyCseObserver-10:B77FAB90:SipXProxy:"SipXauthIdentity::decode > '<sip:[email protected]> <sip:[email protected]>' > missing 'signature' param" > "2012-03-21T14:59:18.872363Z":761:SIP:WARNING:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > INVITE request matches existing transaction" > "2012-03-21T14:59:18.873147Z":762:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T14:59:18.937284Z":763:SIP:ERR:voip.datatek-net.com:SipUserAgent-2:B6E78B90:SipXProxy:"SipUserAgent::handleMessage > SIP message timeout expired with no matching transaction" > "2012-03-21T14:59:18.947827Z":764:SIP:WARNING:voip.datatek-net.com:SipXProxyCseObserver-10:B77FAB90:SipXProxy:"SipXauthIdentity::decode > '\"IVR\" <sip:[email protected]> <sip:[email protected]>' missing > 'signature' param" > "2012-03-21T14:59:18.954528Z":765:SIP:WARNING:voip.datatek-net.com:SipXProxyCseObserver-10:B77FAB90:SipXProxy:"SipXauthIdentity::decode > '\"IVR\" <sip:[email protected]> <sip:[email protected]>' missing > 'signature' param" > "2012-03-21T14:59:19.140082Z":766:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T14:59:30.718114Z":767:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T14:59:30.729993Z":768:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T14:59:46.579296Z":769:SIP:ERR:voip.datatek-net.com:SipRouter-11:B6D77B90:SipXProxy:"SipUserAgent::send > outgoing call 1" > "2012-03-21T15:01:41.158371Z":770:KERNEL:ERR:voip.datatek-net.com:SipClientTcp-377:FFFFFFFF:SipXProxy:"OsMsgQShared::doSendCore > message send failed for queue 'SipTcpServer-3' - no room, ret = 9" > > Any ideas? > > Stiles > > On 03/19/2012 04:40 PM, Douglas Hubler wrote: > > Nettica.com should work. > > If you only have one server, you don't need srv records, but dns should be > running on sipx server and it should be configured automatically > On Mar 19, 2012 3:53 PM, "Stiles Watson" <[email protected]> wrote: > >> Are there instructions for setting up SRV records with Godaddy? I do not >> plan to ever ad servers, but if this is the preferred way. If no one like >> Godaddy for this, are there DNS providers which work well for this setup? >> >> I tried a couple of months ago to get SRV recs set up, but I had a >> problem with the _sip._tcp.rr record I asked about in my original email. >> Godaddy is not setup to except it. >> >> Stiles >> >> On 03/19/2012 02:38 PM, Michael Picher wrote: >> >> Changing the SIP domain is a bad thing to do... >> >> If you want to use A-Records, you should start that way. >> >> I'd suggest another reinstall and do it with A-Records.... >> >> Be aware if you use A-Records you can not just add servers to the >> cluster. This assumes SRV records. >> >> Mike >> >> On Mon, Mar 19, 2012 at 2:31 PM, Stiles Watson <[email protected]>wrote: >> >>> This is a follow up question to a problem I submitted about 2 months >>> ago. Long story short, I reinstalled sipxecs 4.2 and made the sipxecs >>> server the DHCP and DNS servers as well. This solved some of my issues, >>> but not all. I still am unable to transfer incoming calls to any >>> extension. I can dial out from any ext, I can dial ext to ext, I can >>> dial into the system and the Auto Attendant answers, but when I dial an >>> ext I get "Please hold while I transfer your call" but the ext never >>> rings. The CDR says the call was transfered and there is no error >>> reported. >>> >>> All calls in and out of sipxecs are through a SIP Trunk via Flowroute. >>> I'm using Polycom SoundPoint IP 335 phones. My firewall is a Sonicwall >>> NSA, with SIP Transformations turned off and H.323 turned off, and >>> consistent NAT enabled. RTP ports 30000-31000 UDP, SIP port 5060 UDP & >>> TCP, SIP port 5080 UDP all open and NAT rules set up to send traffic on >>> these ports to the sipxecs server. I have to support remote phones. >>> >>> My external DNS records are through godaddy and the only record for >>> sipxecs is an A record. I've followed the instructions at >>> http://wiki.sipfoundry.org/display/sipXecs/DNS+Concepts+for+sipXecs for >>> setting up A records and have changed the domain name to the fully >>> qualified domain under System-->Domain. I clicked Apply, restarted the >>> services and then rebooted. I also sent new profiles to the phones. This >>> also required me to change the internal DNS zone file to use the fully >>> qualified domain. After doing this I restarted the named service. >>> >>> DNS advisor runs successfully, but the DNS test under >>> Diagnostics-->Configuration Tests returns a warning that SRV records for >>> the unqualified domain can not be found: >>> >>> Starting DNS servers test. >>> DNS testing of name server: voip.datatek-net.com >>> NAPTR Lookup for datatek-net.com domain: >>> No NAPTR records found. >>> >>> SRV Lookup for Target: _sip._udp.datatek-net.com >>> No SRV records found. >>> >>> SRV Lookup for Target: _sip._tcp.datatek-net.com >>> No SRV records found. >>> >>> SRV Lookup for Target: _sips._tcp.datatek-net.com >>> No SRV records found. >>> >>> Why is the test looking for SRV records for datatek-net.com and not >>> voip.datatek-net.com (which exist and which I had to add to make the DNS >>> advisor happy)? >>> >>> There is one record in the internal DNS config that I do not understand: >>> >>> ; SRV record for service SIP TCP rr.voip.datatek-net.com >>> ; priority: 1 weight: 0 port: 5070 server: voip.datatek-net.com >>> ; >>> _sip._tcp.rr.voip.datatek-net.com. IN SRV 1 0 5070 >>> voip.datatek-net.com. >>> >>> Why is port 5070 being used and for what? >>> >>> Thanks for your help... >>> >>> Stiles >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> Michael Picher, Director of Technical Services >> eZuce, Inc. >> >> 300 Brickstone Square >> >> Suite 201 >> >> Andover, MA. 01810 >> O.978-296-1005 X2015 <978-296-1005%20X2015> >> M.207-956-0262 >> @mpicher <http://twitter.com/mpicher> >> www.ezuce.com >> >> >> ------------------------------------------------------------------------------------------------------------ >> There are 10 kinds of people in the world, those who understand binary >> and those who don't. >> >> >> >> _______________________________________________ >> 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 [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/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
