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

From: [email-masked]
Date: Mon, 26 Aug 2002 11:20:29 -0400

Medhavi,
I had  a similar thought on the implementation. The 'traceroute' 
functionality could be introducted by a header such as 'Trace-Route:'. In 
addition,
an XML scheme could be defined for the body to encapsulate 'richer' 
information.

However, from the initial discussion we had on the list, it seemed there 
may be  a need to see the scope of the overall requirement
and analyze if we need anything more than a traceroute. Hence the 
requirements before the specific implementation.

Your comments would be welcome.

regds
arjun

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

"Medhavi Bhatia" <[email-masked]>
08/26/2002 11:10 AM

        To:     [email-masked], "Jiri Kuthan" <[email-masked]>
        cc:     "Dean Willis" <[email-masked]>, [email-masked], 
[email-masked]
        Subject:        Re: [Sip] SIP Traceroute using Max-Forwards

Arjun,

I was thinking more about the mechanism to do this, and
what others think about the following idea, as a 
requirement/implementation:

If a proxy modifies or adds a header in a request forwarded by it ( this
includes
forking), it adds that information (or the modified header), in a special
container
header/body of some sort. I think a simple thing like that may capture a 
lot
of things for diagnostic purposes.

-Medhavi.

----- Original Message -----
From: <[email-masked]>
To: "Jiri Kuthan" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, August 26, 2002 10:26 AM
Subject: RE: [Sip] SIP Traceroute using Max-Forwards

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-pat
htrace-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

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the 
information
transmitted by this email including damage from virus.

_______________________________________________
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: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 26 Aug 2002 11:29:04 -0400

Arjun,

In the requirements section itself, I think we should have two levels,
indicating basic support in terms of a simple set of requirements and
lanother for advanced features. The whole issue of diagnostics is a very
extensible
idea, which will grow as the protocol develops more and more interesting
functionalities.  However, the routing aspects are pretty much defined right
now,
and diagnostics can be clearly specified. Hence my suggestion to capture the
latter
very simply in side a container header.

-Medhavi.

----- Original Message -----
From: <[email-masked]>
To: "Medhavi Bhatia" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; "Jiri Kuthan"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, August 26, 2002 11:20 AM
Subject: Re: [Sip] SIP Traceroute using Max-Forwards

Medhavi,

regds
arjun

Arjun,

-Medhavi.

----- Original Message -----
From: <[email-masked]>
To: "Jiri Kuthan" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; <[email-masked]>;
<[email-masked]>

Comments welcome.

regds
Arjun

-Jiri

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 26 Aug 2002 10:50:44 -0500

By the way guys -- requirements development work is done in SIPPING,
right? Can we move the requirements development over there?

--
Dean

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Medhavi Bhatia
> Sent: Monday, August 26, 2002 10:29 AM
> To: [email-masked]
> Cc: Dean Willis; Jiri Kuthan; [email-masked]; [email-masked]
> In the requirements section itself, I think we should have 
> two levels, indicating basic support in terms of a simple set 
> of requirements and lanother for advanced features. The whole 
> issue of diagnostics is a very extensible idea, which will 
> grow as the protocol develops more and more interesting 
> functionalities.  However, the routing aspects are pretty 
> much defined right now, and diagnostics can be clearly 
> specified. Hence my suggestion to capture the latter very 
> simply in side a container header.
> 
> -Medhavi.
> 
> I had  a similar thought on the implementation. The 
> 'traceroute' functionality could be introducted by a header 
> such as 'Trace-Route:'. In addition, an XML scheme could be 
> defined for the body to encapsulate 'richer' information.
> 
> However, from the initial discussion we had on the list, it 
> seemed there may be  a need to see the scope of the overall 
> requirement and analyze if we need anything more than a 
> traceroute. Hence the requirements before the specific implementation.
> 
> If a proxy modifies or adds a header in a request forwarded 
> by it ( this includes forking), it adds that information (or 
> the modified header), in a special container header/body of 
> some sort. I think a simple thing like that may capture a lot 
> Cc: "Dean Willis" <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> 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 )
> 
> 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
> 
> --
> 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:
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
> 
> 
> DISCLAIMER: This message is proprietary to Hughes Software 
> Systems Limited (HSS) and is intended solely for the use of 
> the individual to whom it is addressed. It may contain  
> privileged or confidential information  and should not be 
> circulated or used for any purpose other than for what it is 
> intended. If you have received this message in error, please 
> notify the originator immediately. If you are not the 
> intended recipient, you are notified that you are strictly 
> prohibited from using, copying, altering, or disclosing the 
> contents of this message. HSS accepts no responsibility for 
> loss or damage arising from the use of the information 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>