Won't this run into exactly the same response-size obstacle that the
previous diagnostics work tripped up on?
It might help to spend some time trying to find some other pattern
than trying to use responses for moving the information you're trying
to capture around.
Source-routed requests in the opposite direction? (using content
indirection?) Subscribe/Notify? Maybe something else...
RjS
On Feb 23, 2009, at 3:37 PM, Dale Worley wrote:
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 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
