Subject: [Sip] SIP location conveyance: error indication

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 17:16:50 -0400

During the call today, we discussed error handling in SIP location  
conveyance and identified two problems:

(1) With multiple locations, it is impossible to tell which error  
(warning) refers to which location. Since location elements may be  
inserted by proxies and are then invisible to the UAC, the UAC could  
get an error indication which makes no sense since it refers to  
another location.

(2) The current return-424 model is inappropriate if location-related  
failures should not cause the call to fail, as will often be the  
case. (Just because Domino's can't dereference my location URL, it  
still wants to talk to me about ordering pizza, but I also want to  
fix that URL.)

Thus, my proposal:

(1) Define a new Location-Error request (?) and response header, as in

Geolocation-Error: "Cannot  
dereference" ;tag="xkauc" ;code=711 ;source="alice.example.com"

where tag is a new tag added to a location header. This error can  
occur in a 424 or any other status code, including a 200. If included  
in the request, it's used by the UAS in case location handling is  
delegated to some other proxy. (I'm not sure whether the request  
header thing is a good idea.)

(2) Define a new Accept-* header, as in

Accept-Geolocation: sip, http

which identifies the dereferencing protocols supported, to avoid the  
current ugly overloading of the warning messages.

Henning

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 25 Apr 2007 16:51:12 -0500

Henning

Initial thoughts in-line

>dereference" ;tag="xkauc" ;code=711 ;source="alice.example.com"

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?

Another thought, I think this Geolocation-Error shouldn't be in 
requests (as I don't see a use case for it yet).

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.

>current ugly overloading of the warning messages.

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.

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?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Apr 2007 18:04:21 -0400

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.

> 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  

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.

> in which most/any Accept-* aren't being done - so why do we keep  

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 Apr 2007 19:31:19 -0500

>exactly what's in the current warning header.

for whatever reason, a request has a PIDF-LO with city, street, 
street number, etc *but* not state or country.  How does this get 
indicated in the new Geolocation-Error header field format?

this is exactly the example that was given to me two IETFs ago when 
you (and others) wanted the XML blob as a message body part in the 
424 response (with the exact failure and the exact fields that are 
bad (for whatever reason)).

I had no problem with goin along with that message body in 424 idea, 
but I had a timing issue with "it ain't done yet, and it ain't even 
started yet, so how long is it gonna take to get there" wondering.

I put it into -06 and got a few comments that absolutely didn't like 
the idea, so I took it back out, leaving us with little exact info on 
what's bad in the request that Warning (and Reason) can't solve for 
in their current form.

>>one inserted by the UAC), the error is referring to.

Do others agree with this?

>little doubt as to what namespaces are being supported.

but they aren't trustworthy domains, so the administrators don't want 
to give someone the answer if they don't already have it

>convey the same information).

What do others think here?

---

From: Andrew Newton <[email-masked]>
Date: Mon, 30 Apr 2007 20:36:45 -0400

> Do others agree with this?

Makes sense to me.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Apr 2007 20:45:57 -0400

> indicated in the new Geolocation-Error header field format?

The same way it does in the existing Warning header, I presume. I was  
not trying to make the new header do location verification.

> I had no problem with goin along with that message body in 424  
> idea, but I had a timing issue with "it ain't done yet, and it  
> ain't even started yet, so how long is it gonna take to get there"  
> wondering.
>
> I put it into -06 and got a few comments that absolutely didn't  
> like the idea, so I took it back out, leaving us with little exact  
> info on what's bad in the request that Warning (and Reason) can't  
> solve for in their current form.

To cite a slightly related example, we don't have a formal mechanism  
to specify exactly which part of an SDP description is broken, or to  
call out the syntax error in SIP messages by line number or precise  
description. I think of these more like compiler errors, which are  
also presented as (maybe) some generic label and plain text.

In general, such information isn't useful to machines, since they  
can't debug the problem by themselves, so if an implementation wants  
to be helpful, a simple

Geo-Error: "Missing <country>" <some-syntax-error-code>

is probably about as helpful as you can get. This type of error  
message is only useful to humans, after all.

Thus, I agree that no additional XML error reporting is necessary here.

>
>
> but they aren't trustworthy domains, so the administrators don't  
> want to give someone the answer if they don't already have it
>

That's presumably not a problem in our case.

Henning