Subject: RE: [Sipping] URIs for Gateways

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Jan 2003 15:48:41 -0500

Yeah, I actually thought of just allowing a display name in the
Request URI and using that, but it seems so foolish to make a change,
and have that change not be exactly what we needed.

We could use NAI.  I suppose we could use a P-Asserted-Identity
with a tel URI:  
P-Asserted-Identity tel:+17247426826

What do we do when the "real" NAI happens?

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 3:10 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> > I'd like to get a new header for the calling party number on
> > an outbound call.  That way, the translator can be a proxy and
> > add the header.  I'd recommend that gateways allow the number
> > to be in the From.   
> 
> Generalized, you want something like the Request-URI that can be 
> modified or inserted. How about the NAI stuff?
> 
_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Mon, 6 Jan 2003 14:05:53 -0500

RFC3325 was 'short-term' because it was achievable in the short-term and has
a more limited (but still useful) applicability. The long-term identity
solution must be a superset of the functionality of short-term - it must
address the short-term scope of applicability, but also encompass general
needs for network assertion (which SIP does have). Accordingly, it takes
longer to develop. At such a time as there is a workable long-term solution,
it would be pointless to allow both to be SIP standards except as part of a
transition plan. So in that sense, I disagree - one is a short-term solution
of the other.

Jon Peterson
NeuStar, Inc.

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 8:20 AM
> To: Rosen, Brian; 'Henning Schulzrinne'
> Cc: [email-masked]'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> Network asserted identity (RFC 3325) is the real network 
> asserted identity. It is a P header not because it is 
> preliminary, but because the whole idea of network assertion 
> is not generally applicable to all SIP architectures. For RFC 
> 3325 a trust domain needs to exist between proxies that use 
> the P-Asserted-Identity in order to guarantee the privacy, 
> this does not exist in all SIP networks. In does in 3GPP and 
> therefore 3GPP are using RFC 3325.
> 
> If you want to let the 1et outbound proxy assert identity on 
> your behalf then use RFC 3325. If you want to let application 
> servers with whom you have a secure relationship assert your 
> identity, then use Jon Petersons drafts, when they eventually 
> become RFCs. 
> 
> One is not a short term solution for the other.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked] 
> 
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: 02 January 2003 20:49
> > To: 'Henning Schulzrinne'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Jan 2003 10:11:37 -0500

I think Reply-To is a so-so place to put a second identity.
I think it's problematic to have a From have the "real"
SIP URI and the Reply-To have the "real" tel URI.  It
warps the definition of Reply-To.

It also has a serious problem that a proxy can't add it.
One of the requirements I have is that a proxy be able to
do the translation.  Not every gateway can hold all the tables
required for this kind of translation, and I don't think
we want to force every gateway to have the tables.

I think your proposals on identity will not work unless
the signer can be a proxy which later in the routing
than my proxy that does the translation.  If the gateway
does the translation, then in theory there would have to be
a trust relationship between the PSTN and the gateway.  
That won't work for an enterprise gateway, although I'm not
sure that's a practical problem, because if the gateway
translated, the PSTN is going to check that the number
the gateway asserted is one of the identities that loop
is allocated (PRIs have ranges).

I don't see how ENUM is useful with identity assertion,
although it's clearly applicable to the proxy that
translates a SIP URI into a phone number or vice versa in
the Request URI.  

Brian

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 6:35 AM
> To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: [email-masked]'
> First, it is possible, with the long-term identity mechanism, 
> to assert two
> identities in an authenticated identity body. So, you could 
> have headers
> corresponding to a telephone number and a SIP URI of a 
> gateway or a user -
> it strikes me that a telephone number is a good Reply-To, 
> actually, when a
> call comes from a gateway (originating in the PSTN, say) and 
> the From header
> field contains a SIP URI for the gateway, perhaps including some port
> information. The identity that the gateway which handles a 
> PSTN-SIP call
> would assert needs to be its own, and recipients of calls 
> from gateways need
> to trust the telephone number provided by the gateway or not 
> accordingly
> (i.e. a signature from att.com vouching for such a request should be
> acceptable).
> 
> Technologies like ENUM (when/where available) could enable gateways to
> convert originating telephone numbers into URIs. Of course, a gateway
> wouldn't be able to assert that identity to an intermediary unless it
> possessed credentials appropriate to that URI, which is unlikely.
> 
> For outbound calls (SIP-PSTN), the gateway may or may not be 
> able to map
> (authenticated) SIP URIs representing originators to 
> appropriate telephone
> numbers via some sort of local tables as you suggested. If 
> not, might also
> pick a number from a pool, sure. The question of whether some 
> authentication
> service should be able to assert an originating telephone 
> number (in an
> authenticated identity body, say) that a gateway will use is 
> also a trust
> question - it is possible to put the tel URL in the AIB. If 
> the gateway has
> a reason to trust the authentication service, then certainly 
> it should send
> that number to the PSTN (when the protocol allows gateways to supply a
> number, like with ISUP or Q.931). The gateway would be very 
> ill advised to
> take just any authentication service's word on this matter, though. 
> 
> The target of the calls for the PSTN should be identified 
> with a telephone
> number - at least, by the time the call arrives a gateway, 
> it's Request-URI
> should contain a tel URL or a SIP URI with a tel URL 
> component. Whether the
> originating UAC sets the To header field to a tel URL or a 
> subsequent proxy
> retargets the request doesn't seem to make much difference. 
> ENUM can also
> play a pretty obvious role here.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > Sent: Monday, January 06, 2003 1:22 PM
> > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning
> > Schulzrinne'
> > Cc: [email-masked]'
> > I agree with this.  I'm confused by those who seem to think that
> > P-Asserted-Identity is needed when the long term solution is
> > fully baked.  If the UA knows its identity, which seems
> > reasonable, then it can "assert" it, and have that assertion
> > validated by a trusted entity using cryptographic means.
> > That is the fundamental idea I get out of Jon's proposal.
> > The only circumstance where that won't work is where the
> > UA doesn't know its identity.  I don't see that as a problem
> > on any network I'm aware of, but ...... keep reading.
> > 
> > I do think there is a problem which this whole thread talks about.
> > The basic reality is that many users of SIP UAs will have two
> > identities - a SIP URI and a telephone number.  It may be
> > necessary to assert both identities in one call, because the
> > originator of the call does not know which identity may be
> > needed.  There is no current header to do this.  I think that 
> > it is advantageous to have a proxy be able to assert the phone 
> > number.  Otherwise EVERY UA will have to be able to understand 
> > that two identities are possible, know them both by some 
> > unspecified means, and assert them in every call on every UA.  
> > This seems unreasonable.  I'm not sure that there is a reason
> > to have both identities validated, but there could be.
> > 
> > Brian
> > > From: Peterson, Jon [mailto:[email-masked]]
> > > Sent: Monday, January 06, 2003 2:06 PM
> > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> > > Cc: [email-masked]'
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Jan 2003 10:02:38 -0500

Note below

> What I suggested was that the From header hold the URI of the 
> gateway - not
> the 'real' SIP URI of the user - for PSTN-to-SIP calls. The 
> From address in
> this instance is not the address to which you should reply if 
> you want to
> reach the initiator of the session later. The tel URL of that 
> user is in
> fact the URI to which you should reply. I think this is a 
> good place to put
> it for this case, and it doesn't warp the Reply-To header in 
> any way that I
> can see. This is completely unrelated to where one would put 
> the 'real' SIP
> URI of the user.
I see how it works in this case, but only if the UA knows both identities.
In some cases it doesn't now, but I think we might reasonably ask
whether it should (ie the BCP I propose could state that gateways
should know the telephone number it is connected to, and fill in
From and Reply To as you suggest).  We want to build systems where
a proxy knows this, and doesn't rely on the gateway.  Basically, we
have ONE place that maintains the phone-number-to-user and phone-number-
to-port-on-gateway information, and all tel URIs are routed through
that proxy.  It adds mappings and decides on which gateway will get
the call.  UAs don't know the mapping, gateways don't know the mapping,
only the one proxy knows.  We now have mechanisms that attempt to
keep gateway mapping systems accurate from the one database.  It takes 
vendor specific code in the proxy that knows how to manipulate the 
management port of each gateway in order to maintain the mappings.
That's not a good system design, even if it does work.

> I think you mean that you want the proxy to be able to add a telephone
> number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI
> representing the originating user to a request for a PSTN-to-SIP call
> (though this latter one is difficult - how would a user authenticate
> themselves to an auth service through a PSTN gateway?). I agree that
> Reply-To is not a good candidate for this usage - this is 
> where it has been
> argued that P-Asserted-Identity is a good candidate.
Yes, you see what I mean.  Yes P-A-I would work, although this use
does not meet the definition of P-A-I.  I'm also bothered that we use
two different headers for what I think is the same thing (holding both
a sip URI and a tel URI in the sip message for the "From" identity).

> 
> There are some minor issues with this (such as how a proxy 
> knows when and
> why to add identities, and how authentication for particular 
> identifies is
> managed), but I think that if a proxy asserts an identity, it 
> can and should
> use the identity mechanisms we've already defined, which were designed
> specifically with proxies in mind. However, there are some 
> reasons to ask
> whether or not proxies are always the best entities to decide 
> when synonym
> identities should be added to a request.
I agree that authentication in this case is a little tricky, but
I don't think it's very hard.  

> The whole issue of who should do 'translation' by various 
> entities is a
> little problematic, and ultimately this problem should be 
> separable from the
> selection of the headers we might use to express the results 
> of translation.
> Personally, I think ENUM is the right way to do telephone 
> number to URI
> translations - however, it is not servicable for the reverse, 
> for URI to
> telephone number translations. Having some kind of 'reverse 
> ENUM' for this
> purpose has been the subject of much speculation in ENUM 
> circles, but it
> currently is not well understood how it would work.
This is only true for Service Provider gateways.  It is not true
for enterprise gateways.  You would not want to use the currently
defined ENUM, because it would require that every enterprise
publish their internal mappings in the global ENUM DNS.  That
is not acceptable, and there are no mechanisms to do that (it
implies that, for example, an enterprise tells it's SP what the
SIP URI associated with each extension is).

> 
> ENUM is best performed by the initiator of the session, rather than an
> intermediary, for various reasons that are enumerated in 
> sipping-e164-02.
> Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is 
> the right
> place to do an ENUM query. This does not require the gateway 
> to have any
> tables, or what have you. Intermediaries can also query ENUM 
> and apply the
> results to a message, even if it is sub-optimal for them to do so.
When ENUM is used, I agree, best at the gateway, less optimal in
an intermediary (proxy).  

> > than my proxy that does the translation.  
> 
> Well, an authentication service, as I describe it, does the 
> signing after a
> request has been generated, yes. If a later proxy wants to shove some
> (authenticated) information into the request afterwards, that 
> isn't possible
> unless is supplies a separate signed body.
It would be ugly, but possible, for an authentication to be performed
first on From/To/Reply-To and then subsequently on P-A-I. 
The idea of authenticating cryptographically the P-A-I header 
amuses me.

> > If the gateway
> There is always, in effect, a trust relationship between the 
> PSTN and a
> gateway. The gateway is a node on the PSTN (whether it is a 
> privileged node,
> like an SS7 gateway, or a user node, like a CAS gateway), and 
> nodes have a
> certain defined trust relationship with the PSTN. I think the 
> gateway is one
> of the better candidates to do ENUM, and possibly to perform 
> the reverse
> operation (however that would work).
Do SPs really trust CAS gateways?  I didn't think it's true, 
although I don't know what actually happens if the gateway
supplies a calling number that is not one of it's assigned DNs.
I'm pretty sure it's NOT true of PRI gateways, but don't really
know.  I don't think that it matters for this discussion.

See above for routing issues that argue against the gateway doing
the mapping, at least for an enterprise system.

> Presumably, gateways shouldn't trust authentication services 
> that might give
> them improper information. In fact, there are numerous restrictions
> surrounding what sorts of phone numbers should be sent over 
> many sorts of
> ISUP trunks as well (as well as rules about when a CgPN must 
> be present, as
> opposed to may be present). An proxy or user agent that 
> supplies originating
> telephone numbers for SIP-to-PSTN calls should expect 
> gateways to validate
> them, and there should be some way to accomodate cases in 
> which the gateway
> cannot transmit these numbers to the PSTN, since it may be 
> difficult for a
> proxy to determine what sort of gateway a request will 
> ultimately land on
> (which is one of the reasons why proxies might not be the 
> best place for
> synonym identities to be managed).
> 
> It doesn't assert identity itself, certainly. The one place 
> in which it is
> conceivably useful for identity assertion is that ENUM could 
> be queried for
> a URI associated with the calling party's number in a 
> PSTN-to-SIP call. This
> could be useful for a number of reasons - that URI could be stuck in a
> header to indicate a SIP URI for the end user that is more explicit or
> recognizable than their telephone number.
Agree.  This could be useful.  What header?

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Jan 2003 10:13:05 -0500

Juha

Not all gateways are equipped to do the mapping.
In many cases, there is some element (a proxy server) that
does the mapping.  I am loath to make it a requirement
that the mapping is done at the gateway. 

Also, tel URIs in Request-URIs are often rewritten by
proxy servers to a form of sip:phonenumber@gateway;user=phone
when the routing mechanisms that decide which gateway
gets the call is not the next-to-last proxy.  For example, one
might have gateways at two sites in an enterprise.  A local
decision may be made on one site to forward a call to the
gateway at the other site.  To do this, it must rewrite the
Request-URI so that subsequent proxy servers will correctly
route the call.  We have seen 3 or 4 different ways that
gateways interpret fields to handle this case.

P-A-I is interesting when asserting a phone number for a "normal"
sip URI.  This usage does not precisely follow the text of the
RFC, but it's pretty close.

Brian 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 2:49 AM
> To: Rosen, Brian
> Cc: [email-masked]'
> brian,
> you can program your sip/ss7 gw whatever way you like to map phone
> numbers and sip uris.  there is no need to standardize 
> anything new now
> that we already have asserted identity to place the phone 
> number in case
> the user is using a from uri which is either anonymous or does not
> contain callers phone number.  the mappings themselves are a local
> matter of your domain.
> 
> -- juha
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 9 Jan 2003 19:01:17 -0500

I may have been a little thick up to this point - I now think that by
'gateway' you mean something that acts like a PBX (I was kind of thinking
you meant a PSTN gateway, which has very different requirement for all of
this). From the notes below, it sounds like in your case the PBX is a SIP UA
that has a set of hardwired phone lines (your 'ports'), each of which goes
to a single black phone. You want a proxy server to manage the mappings of
identifiers (be they tel URLs or SIP URIs) to particular PBXs and PBX ports,
because you want the PBXs themselves to be ignorant of the URIs that
identify the phones that they manage. Is that right?

Ordinarily, we say that in SIP architectures, features are pushed to the
edges, not to the core of the network. Abstract out the PBX for a minute,
and imagine coming forward with a SIP architecture in which you have a set
of user agents that are so simple that they don't know their own identity,
they can't learn it somehow from the network, and therefore cannot correctly
populate the From header field of requests they generate. Instead, they'd
like a proxy server to somehow populate this identity in requests as they
are sent through the network. This would be essentially the same problem you
brought to the list.

My reaction would probably be that RFC3261 assumes that SIP UAs have the
ability to populate a From header field. Even my 1G CDMA cell phone knows
its own phone number. A PBX usually means something with a lot of features.
Even if in your architecture you're trying to radically reduce the cost of
the PBX component, a PBX can be expected to more be complex than, say, the
sorts of simple SIP phones we see today (which are in my experience all
capable of mananging one identity, if not several, for their users). Is it
really that much harder for a PBX to look at the string 'port3' in the R-U
of a SIP request and map that to a hardware resource than it is for a PBX to
look at the string '+12025332600' in the R-U of a SIP request and map that
to a hardware resource? PBXs that are compliant SIP implementations will
have to perform a number of vastly more complicated operations.

In other words, it's hard for me to understand why the PBX UA (the edge)
isn't the right place to manage the mapping between an identifier (a phone
number) and a port. Doing this in a proxy (the core) introduces a number of
data synchronization questions as well as the protocol questions that have
run through this thread. Is there some special reason why this PBX cannot be
expected to do one of the simpler things that we ask of UAs? Is there a
particularly large number of ports that you imagine such a PBX would manage
(in the millions, maybe)? It would really help to have more background. The
motivation for this is a little obscure to me.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, January 09, 2003 7:03 AM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: [email-masked]'

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Jan 2003 14:21:13 -0500

Sorry about the tardy reply
> 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].)
Yes, or at least, yes for many interesting systems
There are two cases:
	a) the SIP system is the only phone system at the site,
		gateways are connected to the PSTN.  For small
		sites, you have one line of gateway per user to
		get CallerID correct.  If you don't need outgoing
		CallerId, then you can use "pool" mode and this
		problem doesn't arise.  For large sites, you use
		PRI and the outgoing callerId is set by the gateway.

	b) The sip system is connected to a PBX.  In this case
		you are pretty much forced to have port of gateway
		per user unless you can have a PRI interface to the
		PBX operating as a "remote". 
  
> 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]?
Yes if it's a small site and line per gateway.  With PRI type
gateways the port number often doesn't matter (although it may).
> 
> If the above are true, do you then want to put knowledge of these 
> mappings in your translator proxy rather than in the gateway?
Many small gateways have the mappings in the gateway.  Many larger
gateways don't.  The reason we use a translator is mostly because
the sipphones don't "know" their PSTN numbers, they know their
SIP identities, and even if they did, they don't put both numbers
out on an INVITE.  You don't have to do that, but it's pretty 
helpful.

> 
> 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].
Most gateways we have use the port number as the user in the From.
Yes, the translator can map.  Gateways that have mapping functions
can send calls directly to the associated user, meaning you don't
need the translator, but some of the larger gateways don't map.

> 
> 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].
Not really arguing with you.  I think that is better.  It's not
what most of them do, although I've seen a couple that do.

> 
> 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.
right
> 
> 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.
Yes, that could work, but you lose the port number.  The gateway may
need to know what port number to use.  It actually is not much of
a problem, because mapping gateways usually map the From: sip identity 
into which port to use.  The bigger gateways which tend to not
have mapping usually don't need ports (next available DS0 is
usually enough).  However, I don't think you can REQUIRE mapping in
small gateways, and if there is trunk differentiation on a large
gateway, you may have to differentiate ports.  For example, you may
have local (ILEC) trunks on ports 1-4 and long distance (IXC) trunks
on ports 5-7.  A proxy that did least cost routing would need to
specify the port (actually, a port group would be best).

> 
> Further comments inline below.
> 
> 	Paul
> 
> Rosen, Brian wrote:
> > 
> > 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 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?
I was confused.  This confuses me often, sorry.
Let's see, the gateway knows:
What port the call came in on
The callerId information from the call (calling party name 
  and number).
Some gateways would know the called party number, 
  but not all would.

Every gateway can be told where to send INVITES.  Gateways
that map have a URI per port.  Gateways that don't either have
a fixed URI, or a domain+calling number.  It never made too
much sense to me to used the calling number in the Request-URI,
but I can show you several gateways that do that.
> 
> > 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.
> 
> 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.
> 
> > If the gateway doesn't have translation, the translator takes the
> > called party from the Request URI, or if necessary, the From:
>                                                            ^^^^^
>                                                            ?????
> The above is still worrying me.
> 
> > 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).  
> 
> Tat seems ok.
> 
> > 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. 
> 
> See above for a way to finesse this.
> 
>  > 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. 
> 
> Possible answer above.
> 
> > 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.
> 
> 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
>