You might be able to get the ingate to increase the Max-Forwards in newer firmware.
Most of the ingates I have deployed are running firmware at least a year or so old, and i had a ticket open with ingate to add this feature but at the time it wasn't there. Regardless of what the ingate does, you still need good routing. Even if the ingate can hide the low max-forwards and send sipX a new invite with higher max-forwards, sipx will still keep track of the hops as it goes through the system and if it hits zero, it will drop the call. -M >>> Tony Graziano <tgrazi...@myitdepartment.net> 10/19/12 2:31 PM >>> 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 <mwh...@thesummit-grp.com> 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 202@sipx.domain > > 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 202@sipx.domain. > 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 <itnc...@yahoo.com> 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 > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net 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: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
