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
