Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Jun 2006 15:17:27 +0100

So how would you deal with the interworking scenario with something like the Reply-To header.

For calling identity.

An enterprise network at the calling side has an asserted identity for the calling user (be it in Identity or P-Asserted-Identity). It wishes to to send the call to the called user via the public network, and ensure that the called user receives the asserted identity. The public network uses P-Asserted-Identity but the enterprise network is not part of the trust domain for P-Asserted-Identity.

For connected identity.

The enterprise network receives a call from the public network and sends it to one of its users. The enterprise network has an asserted identity for the called user (be it in Identity or P-Asserted-Identity). It wishes to to ensure that the calling user receives the asserted identity. The public network uses P-Asserted-Identity but the enterprise network is not part of the trust domain for P-Asserted-Identity.

regards

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 01 June 2006 14:43
> To: Jesske, R
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: AW: AW: [Sip] Connected-identity and changing 
> the To header
> field ina response
> 
> 
> I don't know if Reply-To would be any better for your schedule than a 
> new header. It will still require an RFC to make it legal to use in 
> responses. But it would avoid bringing yet another new header 
> into the 
> world.
> 
> IMO, if the semantics are right, then it is better to reuse 
> it than to 
> invent something new. If the semantics are wrong, then it 
> shouldn't be 
> used. Based on my limited understanding of the usage, the 
> semantics seem 
> about right to me.
> 
> 	Paul
> 
> Jesske, R wrote:
> > Paul,
> > in the past we lookes also on the Reply-to header. But per 
> definition it is the address where the user want to be 
> connected. So it is not in each case the real conected 
> identity. But the COLP (TIP) service could be used in the same way.
> > So if it would be possible to use Reply-to header in 
> Responses, if people are willing and we as TISPAN can narrow 
> it then only to the real connected identity (within our 
> walled garden service definition) I would be happy.
> > 
> > Best Regards
> > 
> > Roland
> > 
> >> -----Ursprüngliche Nachricht-----
> >> Von: Paul Kyzivat [mailto:[email-masked]] 
> >> Gesendet: Mittwoch, 31. Mai 2006 17:04
> >> An: Jesske, Roland
> >> Cc: [email-masked]; [email-masked]; [email-masked]; 
> >> [email-masked]; [email-masked]
> >> Betreff: Re: AW: [Sip] Connected-identity and changing the To 
> >> header field ina response
> >>
> >>
> >>
> >>
> >> Jesske, R wrote:
> >>> These are the requirements we already expressed in our 
> >> draft draft-jesske-sipping-tispan-requirements-02:
> >>>    REQ-TIP-1: In addition to any network asserted identity, 
> >> it must be
> >>>               possible for the callee to indicate in a SIP 
> >> response an
> >>>               additional identity where the user is 
> >> reachable for future
> >>>               direct communications.  Note that the 
> >> requirement refers
> >>>               to the user, not to the same instance of the 
> >> User Agent.
> >>>    REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be 
> >> formatted as a
> >>>               SIP URI [2] or TEL URL [3].  A translation 
> >> between SIP URI
> >>>               and TEL URL by the network is not requested.
> >>>    REQ-TIP-3: The identity mentioned in REQ-TIP-1 is 
> >> considered an end
> >>>               user supplied information that is not 
> asserted by the
> >>>               network.
> >>>
> >>>
> >>> As you can see we do not need any authenticated identity in 
> >> the response. For the authenticated identity we are using the 
> >> P-Asserted-Identity. So we have two identities in a Response.
> >>> For our purposes the user provided identity in a final 200 
> >> OK response is sufficient. So that avoids confusion within 
> >> forking cases.
> >>
> >> I haven't been paying close attention to this. What header are you 
> >> planning to use to carry this callee provided identity?
> >>
> >> The Reply-To header would seem to be appropriate for this 
> >> purpose, but 
> >> unfortunately, according to table 2 of 3261, it is only 
> >> allowed in INVITE.
> >>
> >> 	Paul
> >>
> >>> Roland
> >>>
> >>>
> >>>
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Cullen Jennings [mailto:[email-masked]] 
> >>>> Gesendet: Montag, 22. Mai 2006 17:32
> >>>> An: Jesske, Roland
> >>>> Cc: John Elwell; [email-masked]; Roland Jesske; Christer 
> >>>> Holmberg (JO/LMF)
> >>>> Betreff: Re: [Sip] Connected-identity and changing the To 
> >>>> header field ina response
> >>>>
> >>>>
> >>>>
> >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote:
> >>>>
> >>>>> John,
> >>>>> it is that we don't can get an connected identity within 
> >> the final  
> >>>>> response of the initial INVITE.
> >>>>> Your draft proposes a mid dialog request for getting this 
> >>>> information.
> >>>>> That is not usable for the TIP service.
> >>>> I think this is part of what I am not understanding. 
> What is the  
> >>>> requirement here?
> >>>>
> >>> _______________________________________________
> >>> 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
> >>>
> >> _______________________________________________
> >> 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
> >>
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Jun 2006 11:35:16 -0400

> So how would you deal with the interworking scenario with something like the Reply-To header.

Keith - I am not at all certain I fully understand all the nuances of 
the case or what you would like to happen.

> An enterprise network at the calling side has an asserted identity for the calling user (be it in Identity or P-Asserted-Identity). It wishes to to send the call to the called user via the public n…

I guess you are saying that calling enterprise network is one trust 
domain that uses P-Asserted-ID, and the public network is a separate 
trust domain that also uses P-Asserted-ID. And I suppose the enterprise 
network trusts the public network, but not visa versa.

In this case the public network will presumably want to assert *some* 
identity for the request once it is received from the enterprise 
network. The question is: how does the public network decide what to assert?

When crossing the trust domain boundary this way, according to RFC 3325, 
the enterprise network should use P-Preferred-ID. Then the public 
network should authenticate the request in some way, and insert a 
P-Asserted-ID, ideally with the same value as found if the 
P-Preferred-ID if the authentication permits that.

So, one answer would be for a proxy in the enterprise network to remove 
the P-Asserted-ID header that is valid in its network, and replace it 
with a P-Preferred-Identity having the same value, and then forward to 
the public network. If the public network is aware of the full range of 
addresses valid in the enterprise network, and has authenticated the 
request (possibly just the previous hop), it may then go ahead and 
convert the P-Preferred-ID back into a P-Asserted-ID. In that case no 
Refer-To is needed.

Alternatively, proxy in the enterprise network could remove the 
P-Asserted-ID and insert a P-Preferred-ID containing a single address 
for the entire enterprise network. The public network would then still 
need to authenticate to determine whether to replace that P-Preferred-ID 
with the corresponding P-Asserted-ID again. The difference is that then 
the public network doesn't have to know the full range of addresses the 
enterprise network is allowed to use. It only needs to know one.

If the caller knows its enterprise network behaves this way, and wants 
to communicate its own address, it could put it into a Reply-To header. 
(Or some other header that isn't authenticated.) The callee then MAY use 
that, rather than the P-Asserted-ID it receives, to identify the caller 
and to send subsequent requests to the caller. But no matter how you cut 
it, this technique is pretty weak in the guarantees it provides. (I may 
just decide to put "Reply-To: sip:[email-masked]" in all my calls.)

If I was the recipient of such a call, using a UA with a form factor 
like a phone, I don't know what I would expect it to do with such an 
incoming call. If it can only display one callerid, then I think it 
should display what is asserted. Only if it can display two numbers, and 
show confidence levels for them, would I be inclined to show the 
Reply-To number. And its complicates all features that are based on the 
identity of the caller, since those are predicated on knowing a single 
address when in fact there is a choice of two addresses with different 
confidence levels. You end up needing two variants of the feature, e.g. 
"safe but maybe not useful callback" vs "unsafe but probably useful 
callback".

So this approach is of questionable utility to me. IMO it would make way 
more sense for the public network to have enough data to validate that 
the address the enterprise network wants to assert is in fact one that 
it is permitted to assert.

> For connected identity.

Much the same issues as above.

	Paul