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

From: "Arjun Roychowdhury" <[email-masked]>
Date: Thu, 5 Sep 2002 14:53:08 -0400

Jonathan,

Here what my line of thought was:

There are two categories of information requirement:

a) Identity
b) Other Information (any kind)

'Other Information' can be the product-ID, or  build, or supported codecs 
and so on. These, I would consider as details and should
probably be covered when we design  a schema to represent this information 
(maybe XML or something else - its a later issue)

Categorizing information as 'Diagnostic' or 'Informational' etc. is 
difficult since it depends on the reason why the client sent this request
in the first place (ie did it send a request to discover foo's SIP 
extension support because it wants to discover a server which meets one
of his requirements or did he send it do diagnose what that server was not 
accepting his request)

Therefore, I was leaning towards defining a requirment for 'identity' as 
limited to IP/port (similar to traceroute) and leaving the requirements
for b) as an overall behaviour in this draft  (ie rules a client must 
follow while sending any generic 'other information' request and how a 
server must process it). As you rightly say, its a broad topic.

Would you consider the points you outlined as need to be addressed right 
now or do they fall under subsequent work which can 
expand on the 'kind of data' that is encapsulated in the information 
request ?

regds
arjun

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

Jonathan Rosenberg <[email-masked]>
09/05/2002 02:30 PM

        To:     [email-masked]
        cc:     Jiri Kuthan <[email-masked]>, Dean Willis <[email-masked]>, 
[email-masked]
        Subject:        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-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

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.

_______________________________________________
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