Re: Diagnostic idea

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