On Wed, 2009-04-29 at 16:27 -0400, Matt White wrote:
> The initial invite for the incoming call has Max forwards set to 16.
> A wireshark shows right before it gets to the fallback extension there
> are 8 VIA headers. The very next sip message is the "483 too many
> hops" and the Max Forwards is set to 0
Wireshark isn't particularly good for diagnosing routing errors because
it's not reliable about seeing messages between sipX components, which
is where much of the routing action happens.
If you'd like to diagnose the problem yourself, what you need to do is
get a sample call trace. The first step is to generate a failing call.
Then do "
/usr/bin/analyze_483s /var/log/sipxpbx/sipXproxy.log" to find out what
the call-id is. Suppose the output is:
The most common request-URIs in requests that failed with 482/483:
Count Request-URI Sample transaction
1 sip:[email protected]:5060;transport=udp
3a72a1a0-49fa0856c020e-4836b...@sipgt-1c35bbf6 1900596917
[end of list]
Isolate the part of the quoted call-id that is before the '@':
"3a72a1a0-49fa0856c020e-4836bcd1"
Then extract a trace of the call:
/usr/bin/merge-logs --containing=3a72a1a0-49fa0856c020e-4836bcd1
/var/log/sipxpbx/sip*.log
That generates a file "merged.xml", which you can look at using
Sipviewer: "/usr/bin/sipviewer .../merged.xml".
Then try to see where the loop is occurring, particularly the repeated
sequence of request-URIs. Something in the processing of those URIs is
the problem.
Dale
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
