[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] SIP location conveyance: error indication
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip