Subject: Re: [Sip] Diagnostic idea

From: Jiri Kuthan <[email-masked]>
Date: Tue, 24 Mar 2009 05:53:50 +0100

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-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 24 Mar 2009 05:56:53 +0100

Robert Sparks wrote:
> Won't this run into exactly the same response-size obstacle that the 
> previous diagnostics work tripped up on?

IMO, the most compelling piece of information is what one needs to learn
about where an error occured in the SIP chain at all. at least turning
on Warning HF. Ideally revealing current request URI too. This amount
of information helps a lot but does not break message size constraints
in the field.

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

I'm a bit worried that SUB-NOT is another piece of complexity which is
not necessarily helpful when a simple transaction fails. (chance is
high SUB-NOT will fail too)

-jiri

> Maybe something else...
> RjS
>> Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Mar 2009 05:06:25 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiri
> Kuthan
> Sent: Tuesday, March 24, 2009 12:54 AM
> 
> Nevertheless, I think that troubleshooting has been
> historically of rather

I think dealing with the operational aspects of SIP networks, especially with troubleshooting them, is a topic whose time has come.  There are at least 3 recent drafts introducing mechanisms to aid in troubleshooting SIP.  Personally I think it's one of the next hurdles in growing SIP's adoption.

>From a DISPATCH draft-routing-to-WG perspective, one could argue we actually need a SipOps WG.

-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 24 Mar 2009 19:58:42 -0500

> I think dealing with the operational aspects of SIP networks, especially 
> with troubleshooting them, is a topic whose time has come.  There are at 
> least 3 recent drafts introducing mechanisms to aid in troubleshooting 
> SIP.  Personally I think it's one of the next hurdles in growing SIP's 
> adoption.
>

Hadriel,

I really agree with this. I'm assuming that "operational aspects of SIP 
networks" is

(1) big enough, and

(2) obvious enough

to justify requesting a traditional BOF (not sliding through DISPATCH). So, 
a couple of questions:

(1) is that OK, based on the current view of DISPATCH? or should we be 
requesting DISPATCH time in Stockholm? and

(2) do we have enough people with enough clue to propose a SIPOps BOF?

Thanks,

Spencer

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 25 Mar 2009 16:28:57 +0000

> (2) do we have enough people with enough clue to propose a SIPOps BOF?

I was going to suggest exactly this, I just hadn't worked out the
process for doing it yet :)

I think it would be a great, great idea and would love to see more
focus on operations in the same was an dns, ipv6 etc does, or even
something less formal like the IEPG on sunday morning?

recent statistics show SIP has a huge penetration on the *public*
internet - way more than i think any of us did.

 ~ Theo

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 17:45:41 +0100

It's a great idea. 

Laura

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Theo Zourzouvillys
> Sent: Wednesday, March 25, 2009 5:29 PM
> To: Spencer Dawkins
> Cc: SIP; Dean Willis
> Subject: Re: [Sip] Diagnostic idea
>

---

From: Victor Pascual Ávila <[email-masked]>
Date: Wed, 25 Mar 2009 17:49:04 +0100

> It's a great idea.

+1
-- 
Victor Pascual Ávila

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 25 Mar 2009 17:49:23 +0100

> something less formal like the IEPG on sunday morning?

I think too, there is a large array of topics which are underrepresented
and have large impact on the field. It seems too that the same important
these are, the same unattractive they seem to many who prefer to focus
their creative juices on building new stuff :-)

anyhow, to be more specific: I think diagnostics (such as "proxy chain
troublehooting",disclosing SIP routing decisions to monitoring equipment,
...), security BCPs (see the thread on how to mititage relay attacks,
how to sort out all the identity mechanisms we have,security policies,..),
some interop stuff (Hadriel's HOWTO for session id crossing over 
middleboxes...),
global service discovery, and certainly more.

> internet - way more than i think any of us did.

Some hard publicly disclosed numbers?

Thanks!

-jiri

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 25 Mar 2009 17:02:24 +0000

> Some hard publicly disclosed numbers?

wait until my presentation in SIP after lunch :-)

lots of people have expressed interest in the stats - i've started
doign regular scans fngerprinting, etc and will provide the full
details publically over the next few weeks as well as ongoing graphs
etc.

i just need to find some time to put them up and provide web interface
to the database, and have obviously been rather busy the last few
weeks ;)

 ~ Theo