just wondering if each codec offer was a forward (branch) and each was being answered/counted it would help to shut some of the codecs off so it reduced the hop count.
I think the ultimate answer is to ask the trunk provider to increase theirs. 10 is really not enough, though they might be really targeting a residential/soho market and their idea of a trunk is really a one stop connection to the ua/answering machine, so they assume (and might be right in that context) that 10 is enough. On Wed, Nov 9, 2011 at 11:52 AM, Joegen Baclor <[email protected]> wrote: > ** > Tony, > I dont think codec matters in the OP's case. Although i sure hope it > does. codec issues is something that sipx excels in because of it being a > proxy. Unfortunately this is not one of those. RFC war? nah --- > joegen > > > > On 11/09/2011 11:34 PM, Tony Graziano wrote: > > would it matter how many codex you have enabled in your client/ua? > On Nov 9, 2011 10:01 AM, "Joegen Baclor" <[email protected]> wrote: > >> Perhaps this would help. >> http://wiki.sipfoundry.org/display/sipXecs/Call+Redirectors >> >> Each redirect is a hop. >> >> On 11/09/2011 08:14 PM, Paul Kramer wrote: >> >> Thank you both for your kind input. I'm very impressed at the promptness >> of replies on the list so far! >> >> I've created a new issue at http://track.sipfoundry.org/browse/XX-9954, >> however this is the first issue I have created so there could be problems >> with it. >> >> Apart from the "Too many hops" error message in the sipxproxy log, was >> there any other indication that the problem could be related to >> max-forwards? In the pcap file I can see the original invite from the ITSP >> contains a max-forwards value of 10 which i'm guessing also helped in >> diagnosing the problem. >> >> Do you know if there's a resource available describinig the flow of >> data between each SipXecs component? I'm looking at the merged.xml file in >> sipviewer and must say i'm quite confused. >> >> Thanks again for your help. >> >> Paul >> >> On Wed, Nov 9, 2011 at 9:27 PM, Joegen Baclor <[email protected]> wrote: >> >>> Max-Forwards strikes again. Your ITSP is sending a Max-Forwards of 10 >>> which is consumed by the hops required to eventually land the call to the >>> IVR. The reason why it does not show when not using aliases is because it >>> takes a lesser amount of hop and does not consume the max forwards. I >>> have discussed this with the developers and we agreed that we can introduce >>> a reset-max-forwards=value parameter in the ITSP account setting. This >>> would allow calls coming from these ITSPs with very low max forwards to be >>> rewritten. >>> >>> >>> Please create a tracker for this in jira and attach the logs oisted >>> here. >>> >>> >>> >>> On 11/09/2011 04:19 PM, Paul Kramer wrote: >>> >>> Ok here is the log with enhanced debugging. I had a quick look at the >>> voicemail dialplan and everything seemed to be in order. >>> >>> On Tue, Nov 8, 2011 at 1:18 PM, Paul Kramer <[email protected]>wrote: >>> >>>> Hi all, this is my first post on the forums and I'm a little wet behind >>>> the ears - might have to be a bit patient with me [image: Laughing] >>>> >>>> I'm having an issue with calls made from the PSTN coming in through the >>>> Internode (Australian) ITSP trunk I have setup in sipxecs. When I forward >>>> calls to an extension via System -> Servers -> *server* -> Sip Trunking -> >>>> Incoming Calls Destination, calls forward to VM successfully. However when >>>> I apply my ITSP DID to any extension, the extension rings and a call can be >>>> established but when the call is forwarded to VM, it is dropped at the far >>>> end. VM forwarding also works as expected during internal calls. >>>> >>>> Attached are two sets of logs and traces: one with aliases configured >>>> and one with calls passed straight through to an extension. >>>> >>>> Thanks in advance for your help. >>>> >>>> Paul >>> >>> >>> >>> _______________________________________________ >>> 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/ >> > > _______________________________________________ > sipx-users mailing [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 Email: [email protected] 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 Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services!
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
