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]
<mailto:[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]
<mailto:[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] <mailto:[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 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 list
[email protected] <mailto:[email protected]>
List Archive:http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected] <mailto:[email protected]>
List Archive:http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected] <mailto:[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/
