Subject: [Sipping] Re: [Sip] SIP Traceroute using Max-Forwards

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Sep 2002 14:30:03 -0400

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 15 Sep 2002 14:01:13 -0700

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
>
>
> http://us.f1.yahoofs.com/users/930f6dec/bc/id/draft-roychowdhury-s
> ipping-pathtrace-reqts-00.txt?bcrJka9AQILo3Pai
> >
> > Comments welcome.
> >