Dean Willis wrote:
On Feb 23, 2009, at 3:37 PM, Dale Worley wrote:
I've been considering the following idea for a diagnostic tool, and I'd
like to get some feedback on it.
The goal is to be able to trace the progress of a SIP request through
the network, including seeing the forking structure. We first need to
pick a provisional response codes. It appears that "170" is not
currently used. This response code is also used as an option-tag for
this feature. The processing is that whenever a SIP element receives a
request that contains "Supported: 170", the element will immediately (in
addition to anything else that it would do with the request) send a 170
response upstream, containing the request as its body (media type
message/sipfrag).
Your idea has merit. I believe Jiri Kuthan was working on something like
this a few years ago.
the problem and solution has been quite the same as later appeared with the
sip-frag based draft. (to reiterate: it is a problem for upstream
troubleshooter
to figure out what's going on downstream in a proxy chain, when it does not
even know where the problem could have occured)
In our proxy implementation we do don't reveal the whole SIP message in
error replies,
just very few items that are critical to locating the trouble. In
particular, the
current request URI, via-count, and upstream IP (from the
error-producing hop's perspective).
I don't think these pieces would be ever causing message size concerns
in the field.
This implementation works indeeed well in the field and is useful. A
standard would be
better to allow monitoring equipment to provide better troubleshooting
capabilities. Nevertheless, I think that troubleshooting has been
historically of rather
marginal interest here, so I'm not sure if there is really an action to be
made.
-jiri
for historical records:
http://tools.ietf.org/id/draft-kuthan-sipping-diag-00.txt
also: a great deal of troubleshooting information can be achieved using
traceroute-like tool, sipsak. It takes no standard changes for its basic
operation. Alas, for most qualified assertions more diagnostic information
would be useful, or at least Warning header-field which would reveal who
declined a request. (maybe a topic for a BCP? and religious discussions
about benefits of being able to troubleshoot a network versus benefits
of being able to hide it? ;-)
I've also previously suggested a similar provisional response to inform
the UAC about retargeting being done by a proxy. In addition to
debugging, this helps avoid the unanticipated respondent problem.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
