Subject: RE: [Sipping] URIs for Gateways

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 8 Jan 2003 17:29:38 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 7:12 AM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'
> Cc: [email-masked]'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> 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.
> 

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.

> It also has a serious problem that a proxy can't add it.

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.

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.

> 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.
> 

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.

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.

> 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.  

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.

> If the gateway
> does the translation, then in theory there would have to be
> a trust relationship between the PSTN and 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).
 
> 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).
> 

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).

> 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.  

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.

> 
> Brian
> 
> > -----Original Message-----
> > 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]'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > 
> > 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.
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Monday, January 06, 2003 1:22 PM
> > > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, 
> Brian; 'Henning
> > > Schulzrinne'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > 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
> > > > -----Original Message-----
> > > > 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]'
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > 
> > > > 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.
> > > > 
> > > > > -----Original Message-----
> > > > > 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] 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rosen, Brian [mailto:[email-masked]]
> > > > > > Sent: 02 January 2003 20:49
> > > > > > To: 'Henning Schulzrinne'
> > > > > > Cc: [email-masked]'
> > > > > > Subject: RE: [Sipping] URIs for Gateways
> > > > > > 
> > > > > > 
> > > > > > 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
> > > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > > > 
> > > > _______________________________________________
> > > > 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
> > > > 
> > > 
> > 
> 
_______________________________________________
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: Wed, 08 Jan 2003 18:12:30 -0500

This is interesting. I wonder how many SIP UAs do anything with the 
Reply-To header?

At a minimum, I think there is a *lot* of best-practice to work out so 
that phone displays of who is calling, and automatic callback functions 
on phones "do the right thing" with all the various combinations of 
From, Reply-To, NAI, etc. Perhaps Brian is doing the right thing by 
starting down this path.

In your example, if I am the recipient of the call, I will want my phone 
to display the Reply-To address, and use that for any kind of automated 
callback it might do. I probably have no interest in seeing the From 
address at all.

But I have the feeling there are other (non-gateway) use cases where 
this may not be the case. For instance, I may be able to provide 
credentials that authenticate my From address, but want callbacks to go 
someplace else that I can't authenticate. The recipient may be unwilling 
to display an unauthenticated caller identity.

	Paul