Subject: [Sip] SIP Traceroute using Max-Forwards

From: "Pyrik, Dan" <[email-masked]>
Date: Thu, 15 Aug 2002 11:25:48 -0400

Hello, I am trying to write an application that performs a "SIP Traceroute"
by constantly incrementing the Max-Forwards header starting at 0. The SIP
spec states: "The Max-Forwards request-header field may be used with any SIP
method to limit the number of proxies or gateways that can forward the
request to the next downstream server. This can also be useful when the
client is attempting to trace a request chain which appears to be failing or
looping in mid-chain. ". 
However, I do not see how to figure out the IP address of any proxy other
than the first outbound proxy. When any other proxy responds with a 483 Too
Many Hops packet, it will forward its response along down the proxy chain
and the client will receive the response packet with the IP source address
set to the first outbound proxy. There is nothing within the SIP packet to
show who the originator of the response packet is (without using Record
Route headers). Is there any way to get this to work? 
 Thanks,

Dan Pyrik
Brix Networks

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 16 Aug 2002 14:13:11 +0200

Hello Dan and all
From my understanding the Max Forward header is used for decrementing a value to avoid circular routing. Also there is a proposal within ITU for the SIP-ISUP mapping to map the Hop-Counter to the Max-Forward Header and vice versa to avoid circular routing.
Therefore I think it is not a good idea to use the Max Forward for incrementing a value.
Because if one domain increments the Max Forward Header and the other decrement it, you will never have a mechanism that avoids circular routing.
Please correct me if I misunderstood your mail.  

Best regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]> 

-----Ursprüngliche Nachricht-----
Von: Pyrik, Dan [mailto:[email-masked]]
Gesendet: Donnerstag, 15. August 2002 17:26
An: [email-masked]'
Cc: Hedayat, Kaynam; Naylor, Bob; Venna, Nagarjuna
Betreff: [Sip] SIP Traceroute using Max-Forwards

Dan Pyrik
Brix Networks

---

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 16 Aug 2002 09:46:47 -0500

Dan,

The use of Max Forwards to perform TraceRoute is detailed in Section 11 of
RFC 3261 (SIP). I quote below:

<Quote>
Alternatively, a server receiving an OPTIONS request with a Max-Forwards
header field value of 0 MAY respond to the request regardless of the
Request-URI. 

This behavior is common with HTTP/1.1. This behavior can be used as a
"traceroute" functionality to check the capabilities of individual hop
servers by sending a series of OPTIONS requests with incremented
Max-Forwards values. 

</Quote>

HTH,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jesske, R [mailto:[email-masked]]
Sent: Friday, August 16, 2002 7:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Sip] SIP Traceroute using Max-Forwards

Hello Dan and all
From my understanding the Max Forward header is used for decrementing a
value to avoid circular routing. Also there is a proposal within ITU for the
SIP-ISUP mapping to map the Hop-Counter to the Max-Forward Header and vice
versa to avoid circular routing.
Therefore I think it is not a good idea to use the Max Forward for
incrementing a value.
Because if one domain increments the Max Forward Header and the other
decrement it, you will never have a mechanism that avoids circular routing.
Please correct me if I misunderstood your mail.  

Best regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale

-----Ursprüngliche Nachricht-----
Von: Pyrik, Dan [mailto:[email-masked]]
Gesendet: Donnerstag, 15. August 2002 17:26
An: [email-masked]'
Cc: Hedayat, Kaynam; Naylor, Bob; Venna, Nagarjuna
Betreff: [Sip] SIP Traceroute using Max-Forwards

Dan Pyrik
Brix Networks

---

From: "Pyrik, Dan" <[email-masked]>
Date: Mon, 19 Aug 2002 09:37:14 -0400

Thanks for the information. The "SIP traceroute" application is meant to be
more of a diagnostic tool, and perform the following:
1. record the path taken by the SIP messages. If there are multiple paths
taken, that is fine. The application will tell us what the various paths
are. 
2. perform some timing on the responses of the proxies/endpoint.
3. record the capabilities of the proxies in the path(s)

It looks like it will be able to do most of the above, with the exception of
recording the addresses of proxies that do not support record-route. Thanks
for all the help!

Dan Pyrik
Brix Networks

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Friday, August 16, 2002 2:31 PM
To: Arjun Roychowdhury; Sriram Parameswar
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; 'Jesske, R'; [email-masked]; [email-masked]
Subject: RE: [Sip] SIP Traceroute using Max-Forwards

--- Arjun Roychowdhury <[email-masked]> wrote:
> To address the remaining open question:
> 
> How do you figure out the address of the entity that
> was the last node ? 
> In typical ICMP, the entity that receives
> TTL sets to 0, sets its own IP address in the ICMP
> response. However ,in 
> the case of SIP , the Via header in 
> the response will contain the address of the
> previous hop (x-1) entity not 
> the one that responded (x). 

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. 

In fact, there is no way in the base SIP specification
to get the ICMP traceroute behavior you seek. The
closest approximation would be to examine the
Record-Route: headers in an INVITE response.

If you read the text of RFC3261 carefully:

     This behavior is common with HTTP/1.1.
     This behavior can be used as a "traceroute"
     functionality to check the capabilities of
     individual hop servers by sending a series of
     OPTIONS requests with incremented Max-Forwards
     values

You see that what you get is not the identity of
the servers along the path, but rather their 
capabilities. 

> Again, the other thing is that in ICMP traceroute ,
> there is no absolute 
> guarantee that the next iteration will trace the
> same path 
> as the previous path. That does not seem to be a
> stumbling block in SIP 
> ->t o help solve this problem, am I correct in
> saying 
> that Dan has to implement the source routing
> record-route to ensure that 
> subsequent paths follow the previous path-set ?

I guess the real question is what are you trying
to accomplish with this "traceoute" behaviour.
With stateless proxies in the path, it is quite
likely that subsequent OPTIONS will take different
paths. This is a good thing. You can, of course,
send an OPTIONS within a dialog coupled with 
record-route to get more deterministic behavior,
but again, loose routing makes no guarantees here.

If you want to understand the capabilities of
the servers that would be involved in procesing
a dialog, OPTIONS has everything you need. 

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

> 
> It is also possible that if you send an OPTIONS the
> entity that responds 
> with 200OK embeds its address in some place in the
> SDP which
> could account for reachability -> but then this is
> not standard and no 
> process has been defined for it (to my knowledge) in
> which 
> case you dont need to "go one hop ahead" to arrive
> at the address of the 
> previous node.

This is a possibility, but non-standard as you
mention. It might be useful to publish an 
informational on this topic which describes the
SDP usage you mention.

Regards,
Sean Olson
Microsoft

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

---

From: [email-masked]
Date: Mon, 19 Aug 2002 10:40:08 -0400

How will this work when CPL scripts  and caller preferen ce systems
are common?

"Pyrik, Dan" <[email-masked]>@ietf.org on 08/19/2002 09:37:14 AM

Sent by:  [email-masked]

To:   "'Sean Olson'" <[email-masked]>, Arjun Roychowdhury
      <[email-masked]>, Sriram Parameswar
      <[email-masked]>
cc:   "Naylor, Bob" <[email-masked]>, "Pyrik, Dan"
      <[email-masked]>, "Hedayat, Kaynam" <[email-masked]>,
      "Venna, Nagarjuna"  <[email-masked]>, "'Jesske, R'"
      <[email-masked]>, [email-masked], [email-masked]
Subject:  RE: [Sip] SIP Traceroute using Max-Forwards

It looks like it will be able to do most of the above, with the exception
of
recording the addresses of proxies that do not support record-route. Thanks
for all the help!

Dan Pyrik
Brix Networks

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Friday, August 16, 2002 2:31 PM
To: Arjun Roychowdhury; Sriram Parameswar
Cc: [email-masked]; [email-masked]; [email-masked];

Regards,
Sean Olson
Microsoft