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

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 16 Aug 2002 13:40:59 -0400

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). 

To get the address of X, you would have to increase Max-Fwd by 1 to ensure 
that this time, x is not the terminating entity. 
Therefore, it seems the difference b/w traditional traceroute and SIP 
level is that you would need to "go one hop ahead" of X to get 
the address of X.

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 ?

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.

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

"Sriram Parameswar" <[email-masked]>
Sent by: [email-masked]
08/16/2002 10:46 AM

        To:     "'Jesske, R'" <[email-masked]>, [email-masked], [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: [Sip] SIP Traceroute using Max-Forwards

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

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

_______________________________________________
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: Sean Olson <[email-masked]>
Date: Fri, 16 Aug 2002 11:31:25 -0700 (PDT)

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

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

> case you dont need to "go one hop ahead" to arrive

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