Subject: [Sip] Diagnostic idea

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Feb 2009 16:37:28 -0500

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).

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Feb 2009 22:08:29 +0000

Dale,

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.
It doesn't give you all the information you would get from your idea, of
course. Both mechanisms would suffer from border elements that strip
things out for topology hiding or other reasons.

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

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dale Worley
> Sent: 23 February 2009 21:37
> To: SIP
> Subject: [Sip] Diagnostic idea
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Feb 2009 10:03:00 -0600

Won't this run into exactly the same response-size obstacle that the  
previous diagnostics work tripped up on?
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...

RjS

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Feb 2009 10:33:49 -0600

> response upstream, containing the request as its body (media type

Your idea has merit. I believe Jiri Kuthan was working on something  
like this a few years ago.

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Feb 2009 10:36:47 -0600

On Feb 24, 2009, at 10:03 AM, Robert Sparks wrote:

> than trying to use responses for moving the information you're  
> trying to capture around.

True.

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?

--
Dean

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Feb 2009 17:04:10 -0500

> 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

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.

> 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.

> 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.

> 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.

> than the minimum plus a copy of the H-I header that would have been  

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.

> like this a few years ago.

http://tools.ietf.org/html/draft-kuthan-sipping-diag-00 -- Thanks, I'll
have to look at it.

> 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