I've changed the trunk in sipx to only allow PCMU/PCMA and also changed XLite to only support the same. Unfortunately the call is still being dropped. I also spoke to my ISP who informed me that because the max-forwards is a system wide parameter, it cannot be changed. Looks like I need a new ITSP! Thanks again for your help guys.
On Thu, Nov 10, 2011 at 4:59 AM, Tony Graziano <[email protected] > wrote: > 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/
