Subject: RE: [Sipping] URIs for Gateways

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Jan 2003 10:51:07 -0500

Hmm, well, another case of explain the problem and you often solve
it yourself.
> You miss the point. You may have called sip:alice. That call is then 
> proxied to a pstn number "1234567890" sip:port@gateway. The 
> proxy can't 
> change the To address to put the phone number in. It can't even solve 
> the problem with a redirect, because your UAC will probably 
> just change 
> the request id and reissue the invite with the old To value.
I'll agree that if you called alice, and it got proxied to 1234567890
then the proxy can't change the To:.  On the other hand, all the proxy
can do is to change the Request URI, and that doesn't have a display
name, so you can't actually proxy to "1234567890" sip:port@gateway
You can proxy to a Tel URI, which has a phone number, but does
not have the port and gateway.  However, point taken.

> > In a prior message, I did agree that P-Asserted-Identity with
> > a tel URI could be used for a proxy asserting the translation, 
> > but not the "real" NAI stuff (Jon's signed headers).  Do you
> > want a BCP to say that P-Asserted-Identity is what translators
> > use to get the phone number in the message? 
> 
> What you are suggesting seems backward. The 
> P-Asserted-Identity is only 
> useful for the calling number, not the called number. Assuming the 
> gateway can trust the callerid info it gets from the PSTN, it 
> should be 
> inserting a P-Asserted-Identity header with that value for inbound 
> calls. And it ought to be using it to generate callerid on outbound 
> calls. The kind of translator you describe seems useless for this.
Let's start with inbound calls.  The gateway has calling and called
numbers, it may have a calledId name.  If it has mapping, it has the
sip URI of the intended recipient.  I now see that this works:

The text of 3325 talks about asserting the identity of the entity
the message is from.  For an inbound call, this is really the gateway,
but in this case, I think we would assume that we would use it for
the calling party identity as you say.  Two of them can be used to get
both the number and the name.  The Request URI, if the gateway
has mapping, could be the end UAS, but if it doesn't, either it has to be
a translator URI, or it just sends it with a tel URI, and the proxies
handle it.  The gateway could use a tel URI as the From field which
would be the called party number, but it would have to get the port
number in as a parameter to the tel URI because if translation is
needed, that information is essential to the translation.
If the gateway doesn't have translation, the translator takes the
called party from the Request URI, or if necessary, the From:
and changes the Request URI to the sip URI of the UAS.  Okay,
that works.  Never saw a gateway that came even close to it (okay,
well I've seen some gateways take a tel uri in the Request URI 
for the calling number), but it seems to work.

On outgoing calls, the originating UAC could construct a tel URI, 
or a phone number@gateway sip uri for the Request URI and To: and 
it would clearly put it's sip URI, not it's phone number in the From. 
If there was a translator, it would put a P-Asserted-Identity of the
From (the sip UAC) as a phone number (and name if it wanted).  
It would have to add the port number to the Request URI as a parameter
to the tel URI and forward it to the gateway.  I guess the UAC could 
put the P-Asserted-Identity in the original INVITE just like the gateway
does if there is no translator.  I'm not sure I understand how
routing is done if the proxy that knows which gateway is associated
with the user's line (or destination phone number if that's the routing
decision) would construct a Request URI with the port@gateway 
addressing and still keep the number to dial.  That means the
routing gateway has to be next-to-last proxy in the path, which is
clearly not always true. 

> 
> I think the best choice right now for outbound calls is a 
> tel: uri. You 
> can pack all sorts of info into it. This can also be represented as a 
> sip uri with user=phone. If you want to use a translator, start by 
> generating a tel: uri, then route it to the translator, which 
> can turn 
> it into a sip uri with user=phone, using the domain name to 
> select the 
> actual gateway. It can also fill in extra parameters (defined in the 
> tel: uri) in the user part of the sip uri to help the gateway do the 
> right thing.
> 
>  > The "P-" is a
> > problem.  P-Asserted-Identity should go away once the
> > signed header idea is fully baked, but this problem stays for
> > a very long time.
> 
> I don't think the signed header is a replacement for the 
> P-Asserted-Identity. Which to use depends on whether you have trusted 
> servers in the network that are responsible for some aspects of 
> identity. As long as you are interoperating with the PSTN this will 
> probably remain as a requirement.
Probably not the thread for a discussion like this, but it does seem
to me that the "right" way we want to move to is to have the UAC set
identity correctly, and have the trusted proxy sign it to authenticate
it.  I think there is then no reason to keep P-Asserted-Identity for
any NAI application, including 3G and PSTN interwork.  The only
thing that won't do is allow the "trusted" network to have some
identity that the UAC is unaware of.  I don't think that is a good
plan although you still need the phone number AND the UAC sip uri,
which is what we are really talking about, so the P-A-I morphs
into a UAC (or local, untrusted, proxy) thing, and not a trusted
proxy thing, and the trusted proxy signs it, authenticating it.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Jan 2003 14:30:00 -0500

Brian,

Some of your comments seem so confusing to me that I think I must be 
misunderstanding them in some fundamental way.

Are you talking about a situation where a particular port on a gateway 
is intended to map 1:1 to a particular phone number in the PSTN and to a 
particular sip uri in the sip network? (To be specific, lets call these 
+1-987-654-3210, sip:[email-masked], sip:[email-masked].)

Do you then want take all outbound calls to the pstn from sip:foo@bar to 
be routed thru sip:[email-masked], and all inbound calls from the pstn 
to arrive at port3 on the gateway and then be sent to sip:[email-masked]?

If the above are true, do you then want to put knowledge of these 
mappings in your translator proxy rather than in the gateway?

Under those assumptions, I can start to make some sense of your 
comments. If the gw always sends inbound calls from the pstn to the 
translator, putting the port address (sip:[email-masked]) in the From 
header, then I suppose the translator could use the from address to map 
sip:[email-masked] to sip:[email-masked].

But it seems like an odd thing to do. It would make way more sense to me 
in this case for the gw to put tel:+1-987-654-3210 in the To and request 
addresses, and then send the request to the translator. The translator 
could then look that up and forward the request to sip:[email-masked].

Going the other way - a call from sip:[email-masked] to some phone number 
in the pstn (e.g. +1-789-456-0123), I would expect the UAC to put its 
own address in the From, and a tel: uri in the To and request uris. Then 
it would probably deliver this to the translator. The translator would 
look up +1-789-456-0123,  and discover it isn't in the sip network and 
so must be in the pstn. Given the assumptions I think you are making, it 
would then decide it must route this call to the gateway port associated 
with the caller. So it would look up the From address (sip:[email-masked]) 
and translate it to a gateway address (sip:[email-masked]) and forward 
the request there. But that breaks down, because the gw has no good way 
to learn called number.

This simplest answer I can see to this is for the translator to simply 
translate the From address to the FQDN of the gateway, and then to use 
that to convert the request address from tel: format to sip format: 
<sip:[email-masked];user=phone> and also insert an NAI of 
the caller as tel:+1-987-654-3210. This gets the call to the right 
gateway with the necessary information. It would be up to the gateway to 
figure out that calls from NAI tel:+1-987-654-3210 should use port3.

Further comments inline below.

	Paul

Rosen, Brian wrote:
> handle it. 

The last makes the most sense to me.

> The gateway could use a tel URI as the From field which
> would be the called party number,
                ^^^^^^
                calling???

I hope this was a typo. Why would you put the *called* number in the 
 From field?

> but it would have to get the port

Why? It would be a lot simpler if the gw at least knew, or could get, 
the phone number corresponding to each port, so it can form a tel: uri 
to use as the To address. Then the translator will have something useful 
to work from.

> called party from the Request URI, or if necessary, the From:
                                                           ^^^^^
                                                           ?????
The above is still worrying me.

>>From (the sip UAC) as a phone number (and name if it wanted).  

Tat seems ok.

> to the tel URI and forward it to the gateway. 

See above for a way to finesse this.

 > I guess the UAC could

Possible answer above.

> proxy thing, and the trusted proxy signs it, authenticating it.

I'm not confident that I understand all the issues yet. Jon's proposal 
seems pretty heavyweight - so I am not yet confident that it can be a 
total solution on its own. Also, I think as long as we have to deal with 
the PSTN, which assumes trusted network components, we may continue to 
need the NAI approach. But maybe not.

	Paul