Simplest way, if you can afford it: 1 - Remove/rotate all your logs on /var/log/sipxpbx 2 - Do the call test scenario you want to investigate 3 - Run sipx-trace -a -o merged.xml <call-id>
One not-so-hard way to get the call-id is to look at the CDR(Diagnostics->Call Detail Records) for the call then click on the Download link. Open the CSV on excel and look for the call_id column. - MM On Thu, May 10, 2012 at 3:20 PM, m...@grounded.net <m...@grounded.net>wrote: > When I ran the trace, I started it just before we made the call and ended > it as soon as the call failed. Should I wait a little longer as well? > > > On Thu, 10 May 2012 14:15:00 -0400, Matt White wrote: > >>>> "m...@grounded.net" <m...@grounded.net> 05/10/12 1:59 PM >>> > > > > > >> Yes, I see that in the trace; Max-Forwards: 13 > >> > > > >> I don't see this as a setting in the gateway, is this something I can > >> change? And even if so, why would it need to be >changed when sipx works > >> fine with the other ITSP's? Does that point to verizon needing to change > >> something or appia? > >> > > I wouldnt suspect the max-forwards just yet. > > > > Your trace looks incomplete. > > > > The "406" not acceptable comes from an options packet. Those two packets > > are call-id c6bb48c7-e0caac23-47193a4 > > > > The rest of your trace is for call-id > > 415a5778905eadc713c4142cf64ecfa3ed9b3bb8eb21907ff8-0095-4550 > > > > Notice that the only two sip packets from 70.167.153.130 > > > > The rest of your call comes from/to a different gateway. > > > > Rerun your trace with the single call-id, else you'll be chasing the > rabbit > > down the wrong hole. > > > > -M > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
