Subject: [sipcore] Geolocation Header Question

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Aug 2012 10:35:01 +0300

Hi guys, 

I had gotten a question from the ATIS guys since they are thinking about using the Geolocation header from RFC 6442 but in an interesting way. 

Section 4.1 of RFC 6442 indicates what URIs can go into the Geolocation header, which includes SIP and SIPS URIs. 

ATIS has a different deployment model where the SIP messages go to a gateway that allows interactions with a legacy PSAP. The legacy PSAP then performs a location lookup using a regular phone number (using legacy location protocols). 

In order to convey that phone number for a lookup they are thinking about using the Geolocation header in the following form:
Geolocation:<SIP:[email-masked];user=phone)

Since a SIP URI is allowed in the Geolocation header it seems that this functionality is supported but the semantics is quite different to what SIP location conveyance envisions. The envisioned functionality was that the receipient of that location URI would either look at the body of the message (in case of a CID), would use HELD (in case of a HTTP/HTTPS URI) or SIP (in case of a SIP, SIPS, or PRES URI). 

I had spoken to a few of you during the meeting and I had gotten conflicting responses about whether this is allowed behavior or not. 

Any feedback from folks on this list? 

Ciao
Hannes

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Aug 2012 07:31:07 -0700

> Any feedback from folks on this list?

Well, the problem I see with this is that including a sip uri in 
geolocation header field implies that the deref will be done via a 
subscribe. Apparently that isn't then intent here.

That presents two distinct problems:

- what happens if the dereferencer actually tries to use subscribe?

- what happens if dereferencer uses this ATIS-specific mechanism
   but the server for the designated URI only supports subscribe
   and not this new mechanism?

I have no problem with using this approach *if* both of the above cases 
work. But if either of them will fail then I think this is an abuse of 6442.

IMO it would be ok for the dereferencer to attempt some proprietary 
optimization of the deref as long as:
- it is also capable of falling back to subscribe if the optimization
   fails;
- the server for the supplied sip uri (mgcf.carrier.net in the example)
   is capable of handling the subscribe if it gets one;
- the results of the subscribe and the proprietary deref always
   yield the same result.

	Thanks,
	Paul (as individual)

(I'm speaking as an individual for now. Later we can discuss if we need 
a chair ruling.)

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 7 Aug 2012 10:52:11 -0400

> From: Hannes Tschofenig [[email-masked]]
> 
> In order to convey that phone number for a lookup they are thinking
> about using the Geolocation header in the following form:

Naively, I'd say that since the goal is to carry an E.164 number, a
tel: URI would be the ideal choice.

Dale

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Aug 2012 18:31:18 +0300

I agree but the tel URI is not one of the supported location URIs in RFC 6442. 
Hence, the guys just use a different way to convey the same information.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Aug 2012 18:35:52 +0300

Hi Paul, 

these are good points. Thanks for the feedback. 

I could imagine that the interaction with the location server fails when one tries to dereference the location URI using a subscribe.

I will forward your comments to the respective ATIS persons. 

Ciao
Hannes

On Aug 7, 2012, at 5:31 PM, Paul Kyzivat wrote:

> Well, the problem I see with this is that including a sip uri in geolocation header field implies that the deref will be done via a subscribe. Apparently that isn't then intent here.
> 
> I have no problem with using this approach *if* both of the above cases work. But if either of them will fail then I think this is an abuse of 6442.
> 
> IMO it would be ok for the dereferencer to attempt some proprietary optimization of the deref as long as:
> (I'm speaking as an individual for now. Later we can discuss if we need a chair ruling.)
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Aug 2012 17:57:21 +0000

You could do this:
Geolocation: <sip:[email-masked];user=phone>
(although why ATIS would be defining how calls from Finland work is beyond me ;)

But I don't understand why they need it in a Geoloc header to begin with.  I assumed that header was for devices/networks that use its mechanisms (ie, HELD, SUB, pidf).  They're not going to do that, so why use that header?

You said they're doing the location lookup on the PSTN side - presumably then the location is being looked up based on the calling party info, which should be in another existing header.  Can't they use one of them as the query key for the lookup? (we have plenty to choose from for that already :)

-hadriel

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2012 13:55:14 -0400

I don't think so.

A geolocation header with a sip uri has to lead to a presence server that
can respond to a presence subscription which would return a PIDF with
location.

Routing a tel uri (which user=phone is supposed to be interchangeable
with) to a presence service usually makes no sense.  I don't think you can
send a SUBSCRIBE to a tel uri.  If you could, user=phone is okay.  If you
can't, user=phone is not okay.

It's perfectly reasonable to make the uri
sip:[email-masked]
that is, a real domain, and no user=phone

Brian
> But I don't understand why they need it in a Geoloc header to begin with.
> I assumed that header was for devices/networks that use its mechanisms
> (ie, HELD, SUB, pidf).  They're not going to do that, so why use that
> header?
>
> You said they're doing the location lookup on the PSTN side - presumably
> then the location is being looked up based on the calling party info,
> which should be in another existing header.  Can't they use one of them as
> the query key for the lookup? (we have plenty to choose from for that
> already :)
>
> -hadriel
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2012 15:59:03 -0400

I already commented to the original question.
Here I'm just commenting on the comments.

> can't, user=phone is not okay.

I disagree that a tel uri is *equivalent* to a sip URI with user=phone!

A sip URI with user=phone is supposed to be routed like any other sip 
URI until it reaches a server responsible for the domain of the URI. 
*Then* the user part is to be interpreted as representing a phone number.

Conversely, a tel URI has no domain. (And no user=phone.) The semantics 
of telephone numbers are public knowledge. So any server can decide 
where to route it next, based on the number and whatever other context 
it has.

IMO the distinction is important. If you want to enable anybody to 
decide how to reach the phone number (including going through a PSTN 
GW), then use a tel URI. If you want the call handled via SIP at least 
until it reaches a particular domain, then use a sip URI.

	Thanks,
	Paul

>> Geolocation:<sip:[email-masked];user=phone>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2012 17:04:17 -0400

Yes, agree, but probably not relevant to the discussion.

I went back and looked at the original email, and decided I either don't
understand something, or there is some larger problem.

Between what two elements is this Geolocation header running?

UAS to proxy server (UE to E-CSCF)?  Proxy to gateway (E-CSCF to MGCF)?

Regardless, it seems to be misusing the header, because it's not a sip or
http LbyR.
Better to get a real scheme somehow that does the right thing, use a
parameter in another header, or create a new header.  Depends on what this
actually represents.  It sounds like it really is LbyR, and you want to
communicate a key.  <scheme>:<tel>@domain is appropriate.  The issue is
what is the right scheme?  It's not sip - it's not sip presence.  It's not
HELD identity I take it.

Brian

>>> (although why ATIS would be defining how calls from Finland work is
>>> beyond
>>> me ;)
>>>
>>>> I agree but the tel URI is not one of the supported location URIs in
>>>> RFC
>>>> 6442.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2012 17:11:55 -0400

On 8/14/12 5:04 PM, Brian Rosen wrote:
> communicate a key.<scheme>:<tel>@domain is appropriate.  The issue is

As I already stated, I think sip: is ok if this special lookup can be 
viewed as an *optimization* over doing the presence lookup, and doing it 
the presence way still works.

Otherwise I agree with Brian.

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Tue, 21 Aug 2012 19:05:05 -0500

At 04:11 PM 8/14/2012, Paul Kyzivat wrote:
>As I already stated, I think sip: is ok if this special lookup can 
>be viewed as an *optimization* over doing the presence lookup, and 
>doing it the presence way still works.
>

<tel:> isn't an allowed URI in RFC 6442, neither is the use=phone 
tag, so IMO that makes this offering a no go as far as 'being in line 
with an IETF standards track RFC' (to be formal about it).

James

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 00:31:42 -0400

On 8/21/12 8:05 PM, James Polk wrote:
>> viewed as an *optimization* over doing the presence lookup, and doing
>> it the presence way still works.
>>
> <tel:> isn't an allowed URI in RFC 6442, neither is the use=phone tag,
> so IMO that makes this offering a no go as far as 'being in line with an
> IETF standards track RFC' (to be formal about it).

how does it forbid user=phone? (It's a sip uri parameter, not a header 
parameter.)

>>>>>> which should be in another existing header.  Can't they use one of
>>>>>> them
>>>>>> as

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Aug 2012 10:14:22 +0300

> how does it forbid user=phone? (It's a sip uri parameter, not a header

Reading through the SIP location conveyance document I couldn't find a place
that said sip:[email-masked];user=phone isn't allowed.

So, I agree with Paul.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 22 Aug 2012 03:15:50 -0400

Um... why isn't sip:<tel>@domain valid? I see sip-uri as valid in the BNF, and that implies tel in the user portion.

Jon Peterson
NeuStar, Inc.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of James Polk [[email-masked]]
Sent: Tuesday, August 21, 2012 5:05 PM
To: Paul Kyzivat; Brian Rosen
Cc: [email-masked]
Subject: Re: [sipcore] Geolocation Header Question

James

---

From: James Polk <[email-masked]>
Date: Wed, 22 Aug 2012 13:54:54 -0500

At 02:15 AM 8/22/2012, Peterson, Jon wrote:

>Um... why isn't sip:<tel>@domain valid? I see sip-uri as valid in 
>the BNF, and that implies tel in the user portion.

I'm basing my response on this from section 4.6

    If a location URI is included in a SIP request, the sending user
    agent MUST also include a Supported header field indicating which
    location profiles it supports.  Two option tags for location profiles
    are defined by this document: "geolocation-sip" and "geolocation-
    http".  Future specifications MAY define further location profiles
    per the IANA policy described in Section 8.3.

    The "geolocation-sip" option tag signals support for acquiring
    location information via the presence event package of SIP [RFC3856].
    A location recipient who supports this option can send a SUBSCRIBE
    request and parse a resulting NOTIFY containing a PIDF-LO object.
    The URI schemes supported by this option include "sip", "sips", and
    "pres".

I haven't read that this

    Geolocation: <tel-URI>; user=phone

will be subscribed to and expect to receive a PIDF-LO, which the RFC 
says earlier is the only location value format that's specified as acceptable.

I may have missed something in the discussion, but that's why I don't 
think the <tel> scenario is depicting what RFC 6442 is 
specifying.  Additionally, and I just may not know this - as I'm not 
an expert on <tel-URIs>, but I haven't ever heard of someone wanting 
to SUBSCRIBE to a <tel>. But again, I could be underinformed on this one.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 15:38:09 -0400

On 8/22/12 2:54 PM, James Polk wrote:
>> Um... why isn't sip:<tel>@domain valid? I see sip-uri as valid in the
>> BNF, and that implies tel in the user portion.
>

This discussion is mixing up two related but different things:
- a uri with a "tel:" scheme
- a sip uri with phone number syntax in the user part
   and a ";user=phone" parameter.

I guess this header doesn't all use of the tel: scheme, so that is off 
the table unless it is changed.

A sip uri with ";user=phone" is still a sip uri. The syntax you show 
above isn't right, because the parameter should be inside the <>. E.g.

    Geolocation: <sip:[email-masked];user=phone>

So *syntactically* it should be fine to do this. But then there are 
still the options to deal with. I assume geolocation-sip would apply 
here (since its hard to do a GET on a sip uri.) So that says the 
specified sip uri should be suitable for doing a subscribe for presence.

What I argued earlier is that IMO it might be ok in this case for the 
dereferencer to *try* some other proprietary mechanism, , and then fall 
back to subscription if that fails.

> think the <tel> scenario is depicting what RFC 6442 is specifying.
> Additionally, and I just may not know this - as I'm not an expert on
> <tel-URIs>, but I haven't ever heard of someone wanting to SUBSCRIBE to
> a <tel>. But again, I could be underinformed on this one.

Well, technically its ok to send a SUBSCRIBE with a tel: R-URI. That 
will be ok as long as it can be routed through the sip network. If it 
gets to a PSTN gateway its hard to say what will happen. Probably most 
gateways will have no idea what to do with a subscribe for presence.

My *impression* when I first saw this mentioned was that the intent was 
that the tel: URI would override geolocation-sip, and be an implicit 
indication to some telephony-specific mechanism. But that was just my guess.

	Thanks,
	Paul

>> >>>>with) to a presence service usually makes no sense.  I don't think
>> you
>> >>>>can
>> >>>>>which should be in another existing header.  Can't they use one
>> of them
>> >>>>>as

---

From: James Polk <[email-masked]>
Date: Wed, 22 Aug 2012 14:52:07 -0500

At 02:38 PM 8/22/2012, Paul Kyzivat wrote:
>I guess this header doesn't all use of the tel: scheme, so that is 
>off the table unless it is changed.
>
>above isn't right, because the parameter should be inside the <>

sorry, I was writing quickly

>. E.g.
>What I argued earlier is that IMO it might be ok in this case for 
>the dereferencer to *try* some other proprietary mechanism, , and 
>then fall back to subscription if that fails.
>
>will be ok as long as it can be routed through the sip network. If 
>it gets to a PSTN gateway its hard to say what will happen. Probably 
>most gateways will have no idea what to do with a subscribe for presence.

That's my impression of this scenario also, unless the something 
within the <tel:> or <sip:> URI *doesn't* point that SUBSCRIBE 
request at the gateway, but rather to another presence server that 
can give out the PIDF-LO for that phone number. I'm just guessing 
here too. But at that point, why not use a <pres:> URI that points to 
the location record contained on that server?

James

>My *impression* when I first saw this mentioned was that the intent 
>was that the tel: URI would override geolocation-sip, and be an 
>implicit indication to some telephony-specific mechanism. But that 
>was just my guess.
>
>         Thanks,
>         Paul
>
>>James
>>
>>
>>>Jon Peterson
>>>NeuStar, Inc.