typically you would change the settings in the soft phone only and not in the system. On Nov 10, 2011 6:59 AM, "Paul Kramer" <[email protected]> wrote:
> 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/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
