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
