At 08:34 PM 7/6/2007, 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>
wouldn't this run into the same SBCs & B2BUAs mucking it up problem,
thereby making this unreliable? I mean there could easily be
domain-of-host scrubbing going on at borders, to include this field.
I'm not sure either if PSAPs reeeeally care if location was inserted
by a UAC or proxy along the way - they just want something. It
sounded good when I first came up with the idea, but it is also
merely informative in nature, and has zero integrity.
Also, if I go with your proposal, which seems easy to add, what
strength do I put on the location inserter putting this in? It seems
like it ought to be something like "...MUST insert inserter's
host-id/name header parameter in the locationValue".
Matching this host-id/name into the GeolocationError header's
locationErrorValue within the response seems easy then.
BTW Paul - there are lots of GeolocationError codes of various
flavors, depending on what was wrong with the location when it was discovered.
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
