This is not unusual. Most sip trunk providers use a proxy to several larger ITSP's and preform least cost routing to the lowest trunk provider (ie ATT, Verizon etc). Each upstream provider can send it different max-forwards. Broadvox is likely passing through a low max-forward from a misbehaving upstream provider.
So when Broadvox tells you they are setting it to 60, that may be the case for some calls, but your sipx-trace clearly showed some calls coming in with 6....and that is way too low. Broadvox needs to watch a trace of a good call, and a bad call, and figure out which provider is setting the max-forwards so low. The key is, tell Broadvox they NOT setting it to 60 for all calls and they have a problem. -M >>> Brian Buckles <[email protected]> 10/23/12 1:14 PM >>> Thanks Melcon this seems to build on what Tony said as well. I'll check the 10th frame prior to calling BroadVox back again. From: Melcon Moraes <[email protected]> To: Brian Buckles <[email protected]>; Discussion list for users of sipXecs software <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Tuesday, October 23, 2012 1:02 PM Subject: Re: [sipx-users] Getting 483 Too Many Hops Error >From your packet capture named BroadVOX_Capture_726910-3.pcap there are 2 >calls attempts. First one to 8004144231 and the secont to 6066796893 - both originated from 2165098666. In the first call, Max-Forwards is set to 8, which led the call to the 483 - Too many hops. You can see the INVITE in frame 1 The second call has Max-Forwards set to 67. Check frame 10. Something seems to be wrong on how BroadVOX is sending you calls, with different Max-Forwards depending on the type of destination number. I don't know from where they took the 60 hops to answer you, but certainly wasn't from the call to your toll free number. - MM On Tue, Oct 23, 2012 at 2:29 PM, Brian Buckles <[email protected]> wrote: Thanks Tony, We'll confirm with the ITSP that the hop count isn't this low. We haven't changed any of the hunt groups or added any phones recently. This started suddenly and had previously worked fine. The call I had with the ITSP a day or so ago suggested it was quite high. I understood her to say it was 60 hops, but we will confirm. From: Tony Graziano <[email protected]> To: Brian Buckles <[email protected]> Cc: Discussion list for users of sipXecs software <[email protected]> Sent: Tuesday, October 23, 2012 12:10 PM Subject: Re: [sipx-users] Getting 483 Too Many Hops Error 6 hops is just too low. If it "started" suddenly, it's a change at the provider's end (meaning you didn't add a lot of phones to your hunt group, etc. If it were me, and it's not, I'd make BVOX fix it. It does not adhere to RFC3261. http://tools.ietf.org/html/rfc3261#page-38 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. Another alternate way to do this is with an AA. Let the AA answer the call, and reduce all the options to the minumum time and have it transfer to the hunt group on failure OR make the user press a key to get to the hunt group. Once the call is answered, the hops issue is removed, and the AA will answer the call. Alternately you could see if the ingate will artificially fix this, but the cause s probably a new low cost route for toll free services added and/or changed AT broadvox. How either party (Ingate support or Broadvox) could say it is the cause of the sip proxy or sipx without admitting to this is comical. On Tue, Oct 23, 2012 at 11:58 AM, Brian Buckles <[email protected]> wrote: Tony, Both the Toll Free Dial Plan and the Long Distance Dial plan have the same gateway IP. From: Tony Graziano <[email protected]> To: Brian Buckles <[email protected]>; Discussion list for users of sipXecs software <[email protected]> Cc: Matt White <[email protected]> Sent: Tuesday, October 23, 2012 10:22 AM Subject: Re: [sipx-users] Getting 483 Too Many Hops Error Please confirm the dial plan rule for toll free is enabled (or not) and what gateway it points to (as compared to your long distance rule, for example). On Tue, Oct 23, 2012 at 10:18 AM, Brian Buckles <[email protected]> wrote: > Matt or others interested in the SipXecs capture, please see the link below. > Please follow the link below and choose "click here to start download from" > SendSpace. This capture is of a call from 8595235338 to one of the > problematic toll free numbers 800-414-4231. Please let me know if this > provides any further info that may help to resolve this issue more quickly. > Thanks in advance for any assistance. > > > http://www.sendspace.com/file/m2hoiu > > ________________________________ > From: Matt White <[email protected]> > To: [email protected]; [email protected] > Sent: Monday, October 22, 2012 2:37 PM > > Subject: Re: [sipx-users] Getting 483 Too Many Hops Error > > A sipx-trace will be far more beneficial. What you have is only gonna show > whats happening at the gateway...its not gonna show us anything about how > sipx is dealing with it internally. > > http://www.sipfoundry.org/web/mpicher/~/426137/blogs/-/asset_publisher/xfZRF9U0rLa7/blog/id/78163 > > -M >>>> Brian Buckles <[email protected]> 10/22/12 1:18 PM >>> > All, > Please see the link below for the captures from the Ingate and BroadVox. > The Ingate capture is called "Configured by Ingate Startup Tool..." and can > be viewed from a web browser. You can scroll toward the bottom to see the > capture and search for "483 too many hops if needed". The BroadVox capture > is labeled "BroadVox_Capture_726910-3.pcap" and is just a standard pcap > file. Once you follow link just click on download for each file then click > "Click here to start download from sendspace" at the bottom to save to your > PC. As an FYI I spoke to Ingate and we can upgrade the Ingate a new version > that will allow the preservation of hops. I'm going to hold off on this for > now to prevent downtime of the phone system until necessary and see if > BroadVox can increase the hops. Thanks for the help and please let me know > if the captures offer any further help and suggestions you may have. > > > http://www.sendspace.com/filegroup/6kkw1N%2BO9fAUeWPKwPXWTg > > > ________________________________ > From: Tony Graziano <[email protected]> > To: Discussion list for users of sipXecs software > <[email protected]> > Cc: [email protected] > Sent: Friday, October 19, 2012 2:30 PM > Subject: Re: [sipx-users] Getting 483 Too Many Hops Error > > Except with an ingate we can probably preserve the hop count inside > and make it a non issue (I think). > > On Fri, Oct 19, 2012 at 2:18 PM, Matt White <[email protected]> > wrote: >> Attachments typically don't make ti to the list. Post them to a webserver >> and provide a url. >> >> 483 Too many Hops is generally because the call is getting >> referred/re-invited too many times. >> >> The ITSP will typically send the call with predefined number of "hops" set >> in the SIP header. We often find that this changes even within a single >> ITSP depending on where the call originates. Most ITSP set this around 10 >> hops. >> >> its not hard for this to decrement down to 0. Call hits the ingate >> (1)...Call Goes to an alias on an AA (2), call is sent from the alias to >> the >> AA (3), AA transfers to a hunt group (4)....etc. A few hops are used >> internally to sipx as well. Eventually it bounces around too many times. >> >> So for starters see if you can simplify your call routing. >> >> Its also good to fully qualify call forwarding routes as it removes a hop. >> For example. >> >> Lets say you have extension 201 as a dumy user and it sends calls to hunt >> group 202. >> When you setup the call forwarding enter it as [email protected] >> >> If you just put 202 in their...it will take 2 hops. One when it sends 202 >> to the proxy, and a second when the proxy changes 202 to [email protected]. >> You can see it can eat up hops real quick. >> >> Same goes for alias. If you can route calls to the actual user extension >> it >> will take one less hop than an alias to the same user. >> >> If all else fails, see if the itsp can up the hops for you. >> >> -m >> >>>>> Brian Buckles <[email protected]> 10/19/12 1:44 PM >>> >> >> >> >> ________________________________ >> >> Sorry if this gets re-posted a second time. I haven't gotten any >> confirmation from the admins that this was or wasn't accepted, and this is >> something we need to resolve quickly. Please see my previous email below >> for details. >> Attention SipXecs support community, >> We have a client that is running SipXecs 4.4.0. The Session Boarder >> Controller is an InGate Siparator and the SIP provider for the SIP trunks >> is >> BroadVox. The client is unable to receive calls to most of their toll >> free >> numbers properly. Our client noticed that prior to calling us, that it >> seemed they could get a call to successfully go through from a cell phone >> to >> the toll free numbers, but not from land lines. After further testing it >> appears the some calls go through for most cell phone carriers and not >> others. It appears most land line calls to the toll free numbers fail, >> but >> there's been one or 2 land based offices that were able to successfully >> call >> the toll free numbers. All calls to the local numbers have went through >> without incident as to the best of our knowledge. We talked to the SIP >> provider and vendor for the SBC. They found that the SipXecs system is >> giving a "483 Too Many Hops" error. I've attached a capture (see the >> 726910-3.pcap file ) from the SIP provider as well as capture (See the >> "Configured by Ingate...." file) from the SBC vendor that was ran on the >> SBC. You'll can view the capture from the SBC using a web browser, then >> scroll down toward the bottom to see the capture. You can search for the >> error code given above. The only changes we are aware of that happened on >> the SipXecs system, is that the selt signed cert had expired and was >> renewed >> about a month ago. The issue with the "483 Too Many Hops" has only been >> noticed by the client within the last 1.5 to 2 weeks. The toll free >> number >> of 8004144231 was used during the gathering of the 2 attached captures. >> Can >> someone please take a look at the attached capture files ASAP and let us >> know of any suggestions you have to resolve this issue? This issue is >> having a major impact the client's normal business operations. >> >> >> >> _______________________________________________ >> 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! > ~~~~~~~~~~~~~~~~~~ > > Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab > 2013! > > -- > 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/ > > > > > > _______________________________________________ > 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! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! -- 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 -- ~~~~~~~~~~~~~~~~~~ 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! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected]. net 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/ _______________________________________________ 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/
