Sounds somewhat similar to draft-ietf-sip-hop-limit-diagnostics. The 170 proposal would potentially suffer from similar message size, security, and privacy issues.
> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Dale Worley > Sent: Monday, February 23, 2009 4:37 PM > To: sip-implementors > Subject: [Sip-implementors] Diagnostic idea > > I've been considering the following idea for a diagnostic tool, and I'd > like to get some feedback on it. > > The goal is to be able to trace the progress of a SIP request through > the network, including seeing the forking structure. We first need to > pick a provisional response codes. It appears that "170" is not > currently used. This response code is also used as an option-tag for > this feature. The processing is that whenever a SIP element receives a > request that contains "Supported: 170", the element will immediately (in > addition to anything else that it would do with the request) send a 170 > response upstream, containing the request as its body (media type > message/sipfrag). > > Dale > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
