Re: SIP Tracing Facility

Wouldn't SIP-CLF be a better way to go?

On Mar 6, 2009, at 12:52 PM, Hadriel Kaplan wrote:

> Hi Dale,
>
> I appreciate that doing troubleshooting of SIP in SIP is very  
> appealing, but I'm worried about it.  There are some real security  
> issues with this, even if we don't want to admit it.  The reality is  
> that if this trace mechanism is actually adopted by any sizeable  
> measure, then middleboxes will be forced to munge the messages more  
> than they already do, to prevent it from being used/work.  In other  
> words it's a self-defeating mechanism.
>
> Today you can do incrementing Max-Forwards traceroute, similar to  
> the ICMP traceroute TTL trick, and even that's gotten some folks  
> worried enough to make us munge the Max-Forwards value (despite the  
> obvious dangers in doing so).  But anyway why isn't that type of  
> trace enough for your needs?
>
>
> Also, a couple specific questions/comments regarding this draft:
>
> 1) You use the term "final response" a couple times as being sent in  
> the 170's body.  How would a final response be sent in a 170  
> response, since the 170 would be before a final response?
>
> 2) You state that a UAC should not create an early-dialog for the  
> 170, but for any B2BUA in the path which did not know about this new  
> trace mechanism, wouldn't it create early dialogs on the b2bua since  
> it would treat it as a 183?
>
> -hadriel
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf  
>> Of Dale
>> Worley
>> Sent: Wednesday, March 04, 2009 1:29 PM
>> To: SIP
>> Subject: [Sip] SIP Tracing Facility
>>
>> I wrote up the "170" trace proposal as an I-D:
>>
>> A new version of I-D, draft-worley-trace-00.txt has been successfuly
>> submitted by Dale Worley and posted to the IETF repository.
>>
>> Filename:        draft-worley-trace
>> Revision:        00
>> Title:           SIP Tracing Facility
>> Creation_date:   2009-03-03
>> WG ID:           Independent Submission
>> Number_of_pages: 18
>>
>> Abstract:
>> This document defines a SIP option tag, "trace", to be used within
>> SIP messages to request that SIP elements (both proxies and UASs)
>> that receive the message reflect to the UAC the request they received
>> and the response they gave by encapsulating the request and response
>> in a provisional response.  A new provisional response code "170" is
>> defined to carry the request and response.  This option tag is
>> expected to be used solely for diagnostic purposes.
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email protected] for questions on current sip
>> Use [email protected] for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip