On Apr 25, 2007, at 5:51 PM, James M. Polk wrote:
this is interesting, but we have to account for errors that identify *what* was wrong in an LO (value or reference, assuming the dereference worked), and that requires more header parameters - thus making this header larger than this example. Do you think we can merely list the CAtypes that were supplied that were good, and list those that are still necessary by the Location Recipient? Or just the ones still needed, with text stating to include all that was in the original LO *and* "these" new ones?
I don't understand this comment. The information is pretty much exactly what's in the current warning header.
Another thought, I think this Geolocation-Error shouldn't be in requests (as I don't see a use case for it yet).
The case, somewhat contrived, is that an ESRP can't route on the location (say, the dereferencing failed), but routes the call to a default PSAP, ignoring the location. It would be nice if the ESRP could indicate this failure to the PSAP.
However, I do see the need, if this new header progresses through WG consensus as necessary, to extend the Geolocation header that's currently in Conveyance to include this location "tag" header parameter. I think they need to match up so the UAC understands which location, if more than one is in a request (but not more than one inserted by the UAC), the error is referring to.
Right.
As much as I think this is an easy way of doing this, no vendor that I know of that's doing the Resource-Priority header from RFC 4412, for example, is coding the Accept-Resource-Priority header - also defined in 4412.
My guess is that 4412 is used within single domains, so there's little doubt as to what namespaces are being supported.
Is this a case where this one Accept-* is not being done? Or a case in which most/any Accept-* aren't being done - so why do we keep creating new ones?
They seem to be commonly used for other SIP-related things. At least they show up on IMS call flows... Certainly beats creating a new error code for each new URL scheme that comes along (which doesn't convey the same information).
Henning _______________________________________________ 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
