I have no skin in this game, so take my comments with a grain of salt...
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.
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.
Paul
Henning Schulzrinne wrote:
My general take is that the source, on the return trip, should be able
to identify location information it has inserted. Note that a single UA
or proxy could theoretically insert two locations (e.g., geo + civic) or
reference and value, so some additional identification beyond the node
may be necessary. If it weren't for various SBCs mucking with Via's, the
Via solution sounds interesting, but maybe the simple host name is easiest.
The problem with the host name (or Via) is that the party discovering
the error and the party inserting the location are generally *NOT* the
same. The error is likely to be discovered far downstream, e.g., by the
UAS or the PSAP proxy. The UAS or PSAP proxy has no way to know what
node inserted the location, since the Geolocation header field currently
only says "endpoint" or "server".
Thus, another variation that allows host identification and avoids this
problem:
<proposal>
Just define ;inserted-by to use the host name, and then use the same
parameter in the error indication.
</proposal>
Henning
On Jul 6, 2007, at 2:27 PM, Paul Kyzivat wrote:
Hmm. I've been behind on reading. I was having a side conversation
with James on this, and it looks like some of that would be worth
sharing here. James was asking me for ideas of how to handle this
"identifier".
The following is what I last sent to James:
Paul Kyzivat wrote:
What do you expect will happen as a result of identifying the source
of the error?
Do you expect that the source will itself recognize that it has made
a mistake and do something about it? Or do you expect some other
element to keep notes on which nodes do a bad job of supplying
addresses?
Also, do you expect the node that inserts the address to remember
what address it inserted when it gets the error response? Or some
other node other than the one that inserted it to remember it?
The answer to these questions impacts the kind of solution that is
appropriate.
If the UAS is the one to detect the problem, and also the one to log
the problem for future use, then it must be possible to actually
determine the address of the source of the address. An index into the
Via list might be adequate for that. Or, the "inserted-by" could be
changed to actually include the address of the node doing the insertion.
If the node doing the insertion is responsible for tracking its own
failures, then its probably bad to assume that it will remember what
it inserted. So the actual offending address should probably be
included in the error response. In that case, there is probably
something in that address that will allow the offender to recognize
that it was the source of the problem.
If some other node (other than the UAS and the offending node) is
responsible for logging the problem, then it will certainly want the
offending address as well. So again it should be included in the
response. And again, there probably isn't need of anything else.
At least that's my take based on what little info I have.
Paul
Henning Schulzrinne wrote:
James,
I think your #1 and #2 covers it, in addition to an identifier that
points to the location element that suffers from the problem
identified. (The latter was discussed, if I recall correctly, but
seems to be missing from your syntax proposal.)
I don't feel strongly about identifying the originator of the error,
but it might be useful to have an extensible parameter list, in
standard SIP header fashion, so that we can easily add more debugging
information later.
Henning
On Jul 5, 2007, at 8:22 PM, James M. Polk wrote:
Henning
Regarding Conveyance -08 and the new Geolocation-Error header that
you want to replace the Warning header code(s) function (section 3.4
of the -07 ID)...
What fields do you want in the header?
#1 error-code,
#2 text-string explaining what error it is
#?
Do you need anything else?
Warning had/has the node ID of the sending entity. Do you want that
in the new Geolocation-Error header? Do you really see a purpose in
having that piece there?
Attempting to put the final pieces of -08 together, and this new
header is less than straightforward in writing it.
Is this viable ABNF for what you want?
Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue
*(COMMA locationErrorValue))
locationErrorValue = numeric-code *(SEMI geoloc-error-param)
numeric-code = decimal-string
geoloc-error-param = "code" EQUAL error-text-string
/ generic-param ; (from RFC 3261)
error-text-string = string
(anyone) let me know what you think
Thanks
James
_______________________________________________
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
_______________________________________________
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
