Subject: Re: [Sipping] SIP serviceability - (was) SIP Traceroute using Max-Forwards

From: "Arjun Roychowdhury" <[email-masked]>
Date: Mon, 16 Sep 2002 09:03:52 -0400

Cullen,
thats a good idea.

Based on the feeback that I have received , I am reworking the scope of 
the requirements with the following
perspective:

a) Narrow the scope of the drafts to diagnostics for SIP [since in its 
current shape it is too broad ]
b) Clearly outline minimal profiles
c) Try to define the scope of the categories of information needed for 
diagnostics
d) Keep the flexibility requirement the same [ I dont think we can nail 
down exactly what should or should not be specified
in SIP now as opposed to snmp etc - therefore, I dont want to restrict 
everything at this early stage]

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

"Cullen Jennings" <[email-masked]>
Sent by: [email-masked]
09/15/2002 05:01 PM

        To:     <[email-masked]>
        cc: 
        Subject:        [Sipping] SIP serviceability - (was) SIP Traceroute using Max-Forwards

Would be nice to have something to indicate it was a test call being made
and be able to get the log information from each SIP element that touched
this call all in one common tool. Right now I have to look at the call ID
then go off to a ton of different boxes looking for information in the log
files about this call. We need have something that works well for mid 
dialog
messages too. I often find the INVITE worked fine but a ReINVITE or BYE 
did
not.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, September 05, 2002 11:30 AM
> To: [email-masked]
> Cc: Jiri Kuthan; Dean Willis; [email-masked]
> Subject: [Sipping] Re: [Sip] SIP Traceroute using Max-Forwards
>
>
> Moved to sipping, since this is a requirements issue.
>
> I think there is merit in considering ways to enhance sip to support
> diagnostic information. Clearly, the first step is requirements. I think
> Arjun's draft is a start, but its jumping into details without
> summarizing the specific diagnostic problems we are trying so solve.
> Enumerating and understanding those problems is the first step.
>
> Some thoughts on the kinds of things we might want:
>
> * a way for a client to discover the IP address and port of proxies on
> the path from it to a specific URI
>
> * a way for a client to discover the manufacturer, build, and product ID
> of proxies on the path to a specific URI
>
> * a way for a client to discover the specific proxy which generated a
> 4xx class response
>
> * a way for a client to discover the specific reason a proxy generated a
> 4xx class response (stack trace?)
>
> * a way for a third party to discover ththe specific proxy which
> generated a 4xx response
>
> * a way to discover, using a specific request generated by a UAC as
> input, the message flow through a sip proxy network which resulted from
> that message
>
>
>
> And so on.
>
> I am not saying that these all should be requirements; some should, some
> shouldn't. But this is the level at which we need to start. I also don't
> think all of the diagnostic requirements might be met by SIP; some may
> very well be SNMP stuff.
>
> Other scope issues - does this include performance management? Is our
> goal to also standardize ways to determine what proxies got overloaded,
> why they got overloaded, and what happened afterwards? This can be a
> broad topic...
>
> -Jonathan R.
>
> [email-masked] wrote:
> > I have just posted a small ID that attempts to capture the 
requirements
> > based on our discussion in
> > the list. Its pretty much in initial stage, but its a start.
> >
> > Till it appears on the list, you could find it at (hold your
> breath - the
> > link is a mile long )
> >
> >
> http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-s
> ipping-pathtrace-reqts-00.txt?bcrJka9AQILo3Pai
> >
> > Comments welcome.
> >
> > One of the questions is whether we need to look at it as purely a
> > 'diagnostic' requirement or whether we should generalize
> > it to a 'path information' (which may include diagnostics,
> capabilities,
> > etc) requirement.
> >
> > regds
> > Arjun
> >
> > --
> > Arjun Roychowdhury @ Hughes Software Systems
> > 11717 Exploration Lane, Germantown MD 20876
> > (O): 301-212-7860        (M): 240-997-0066
> >
> >
> >
> >
> > Jiri Kuthan <[email-masked]>
> > Sent by: [email-masked]
> > 08/26/2002 07:47 AM
> >
> >
> >         To:     "Dean Willis" <[email-masked]>,
> <[email-masked]>
> >         cc:
> >         Subject:        RE: [Sip] SIP Traceroute using Max-Forwards
> >
> >
> > Hi Dean and anyone else looking at this discusssion.
> >
> > Thanks to Nils Ohlmeier, there is now beta-version of
> > *running code* that implements the traceroute functionality.
> > http://developer.berlios.de/projects/sipsak/
> >
> > It behaves very much like IP traceroute. It sends OPTIONS requests
> > with increasing Max-Forwards until something else than 483 or
> provisional
> > is received. It displays server name if a downstream server
> discloses it
> > in
> > Warning header field.
> >
> > I too believe there is a need for richer status reporting. Embedding
> > standardized diagnostic information in SIP replies would be very 
useful
> > for network trouble-shooting. If things go wrong and a negative reply
> > comes back, an upstream client knows very little now:
> > - it does not know who generated the reply (the server might be well
> >   hidden in a deep proxy chain and Warnings are optional)
> > - we do not know which r-uri caused a reply (it might have been
> >   rewritten couple of times)
> > - we do not know the hop which last relayed our request to the 
replying
> >   server (and might be possibly guilty of troubles)
> >
> > -Jiri
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.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
> >
>
>
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP