Re: [Sip] Diagnostic idea

["Dale Worley" <[e-mail]>]

On Mon, 2009-02-23 at 22:08 +0000, Elwell, John wrote:
> History-Info can provide some information, depending of course whether
> all proxies forward it and add to it as it goes downstream, that the UAS
> sends it back, and that all proxies forward it upstream in the response.

Yes, if every element implements History-Info fully, you get even better
information than a flock of 170's.  But I originated this with the idea
of inserting it into the sipX stack, and it would take less work to
implement 170 than History-Info.  There's also the interesting idea of
collating the History-Info values from a bunch of 170's.

> Both mechanisms would suffer from border elements that strip
> things out for topology hiding or other reasons.

Yes.  And if I go forward with this idea, I would need to show that
topology hiding could be done easily and sensibly.  One case that would
be nice to handle well is that if the UAC's and UAS's organizational
networks did not want to topology-hide but the transit carrier did --
you'd like to be able to have the transit carrier hide its topology
without hiding what happens in the endpoint networks.

> On the detail, I believe 170 would establish an early dialog - is this
> desirable, and if not is it avoidable? 

It would establish an early dialog, and it's not avoidable, other than
for the fact that any element that understands 170's knows that there
will be no further messages in the early dialog.  I'm not sure if it
causes any problems.

I haven't thought through the interaction with 100rel, though.  I think
the way to handle that would be to postulate that the 170 came from an
internal UAS that did not implement 100rel.

On Tue, 2009-02-24 at 10:03 -0600, Robert Sparks wrote:
> Won't this run into exactly the same response-size obstacle that the  
> previous diagnostics work tripped up on?

I've mostly assumed that it would be used in an enterprise network, and
not worried about message size.  sipX has been implementing
draft-ietf-sip-hop-limit-diagnostics for years, and we haven't seen any
problems.  Although in the case of a provisional response, its loss
isn't much of a problem.

> It might help to spend some time trying to find some other pattern  
> than trying to use responses for moving the information you're trying  
> to capture around.
> Source-routed requests in the opposite direction? (using content  
> indirection?) Subscribe/Notify? Maybe something else...

Yes, that would help, though it's not clear what mechanism could be as
simple as a provisional response.

On Tue, 2009-02-24 at 10:36 -0600, Dean Willis wrote: 
> Do we really need the whole message, or just enough information to  
> identify the message and its context, and possibly describe what the  
> proxy is doing in response to the message?
> 
> For example, what about returning a response that contains little more  
> than the minimum plus a copy of the H-I header that would have been  
> added?

A good point.  Though it's hard to explicitly rule out any particular
header from being returned, given that in some particular case, the
proxies' transformations of that header is the interesting question.


On Tue, 2009-02-24 at 10:33 -0600, Dean Willis wrote: 
> Your idea has merit. I believe Jiri Kuthan was working on something  
> like this a few years ago.

http://tools.ietf.org/html/draft-kuthan-sipping-diag-00 -- Thanks, I'll
have to look at 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.

Which suggests the possibility of sending 170's based not on the receipt
of a request, but on *sending* a copy of the request downstream.  The
effect would not be much different, but it would require implementing
170 only in proxies.

It would also be helpful if the 170 carried the sending and receiving
address/port/transport triples, in addition to the usual request-URI.

Dale