On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote:
Is it really reasonable to expect a proxy that inserts a location
to remember what location it inserted, in enough detail to diagnose
why it might have been messed up? I presume it would have to
reconstruct what the location would have been based in information
in the response. It may not be possible to reconstruct the exact
same value, because the UAC may have moved in the meantime. I guess
the inserted location would have to be by reference, but the URL of
the reference may itself not be easily reconstructed, and multiple
queries of it may not return the same result.
IMO it would be much clearer to include the location itself in the
response. And if the location had been passed by reference, it
might be better to pass it by value in the response, so that there
is no possibility of the value changing.
I tend to agree that this would be better. The reference-to-value
translation may not always be feasible: If a proxy inserts a location
reference and a downstream proxy finds a problem, it can't insert a
value (except by the data URL mechanism I have been mentioning...).
OTOH that might result in divulging the location to nodes upstream
of the one that included it. If it was passed by reference then the
node that had inserted it could remove the reference in the
response. But if it is passed back by value that isn't allowed.
The alternative is that the proxy will have to retain the location
until the completion of the transaction. Maybe that's ok, but if
its only to diagnose an occasional glitch I get it doesn't get done.
My assumption was that most locations will be inserted by the UAC
rather than a proxy. In those cases, retaining the information is
probably not a big deal, since the UAC will generally only have one.
In summary, I think returning as much information about the erroneous
location information as possible seems best, i.e., both the location
information and the party that inserted it. This avoids the "who the
heck put that bogus location information in there?" problem.
In general, I think we have learned that we should help people with
debugging distributed systems with distributed responsibility, as
otherwise they'll either struggle or invent private mechanisms to
include this information. (See SER for the the latter.)
Paul
_______________________________________________
Sip mailing list https://www1.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
