Subject: RE: [Sip] SIP Traceroute using Max-Forwards

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 16 Aug 2002 14:39:26 -0400

I think there may be some confusion here. The
Via: headers will provide no information to the
originator of the OPTIONS request as these are
consumed in the reverse path.

ARC> Oops my mistake. Yes, you are right -> I incorrectly pointed to Via 
whereas I meant Record-Route.
Again, this has the assumption that all nodes inbetween can and will 
Record-Route

If you want to diagnose a network failure and
pinpoint the source of the failure, OPTIONS is
somewhat lacking.

ARC> I would think this is exactly what Dan seems to want to do, instead 
of
discovering capabilities.

Regds
Arjun

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

_______________________________________________
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

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 19 Aug 2002 11:04:27 -0500

If you want to diagnose a network failure and
pinpoint the source of the failure, SIP is
somewhat lacking. It's easily fixed in single
oerator environments by adding some "Kilroy 
Was Here" type headers in responses.

I think it would be a good exercise to look at 
the requirements for this sort of thing (over in 
SIPPING) and see if we can move towards a nice,
safe, and secure way of solving the general class 
problem.

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 26 Aug 2002 13:47:50 +0200

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

--
Jiri Kuthan            http://iptel.org/~jiri/