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/
