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

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 Jun 2006 19:53:46 +0100

Christer,

You wrote: "It has been agreed on the list that it should not cause any harm
to 3261 compliant nodes because the To header is not used as a transaction
identifier." I don't think this is agreed. I think there may have been
acceptance that the transaction model does not appear to be broken, but
there are other concerns, especially those expressed in the past by Jon
Peterson.

Regards,

John

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 01 June 2006 17:46
> To: Paul Kyzivat; Jesske, R
> Cc: [email-masked]; [email-masked]; Elwell, John; [email-masked]
> Subject: RE: AW: AW: [Sip] Connected-identity and changing 
> the To header field ina response
> 
> 
> Hi Paul,
> 
> One suggestion has been to modify the To header in the 
> response. It has been agreed on the list that it should not 
> cause any harm to 3261 compliant nodes because the To header 
> is not used as a transaction identifier. As, for the dialog 
> identifier, only the tag parameter is used (and that would 
> not be modified).
> 
> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 1. kesäkuuta 2006 16:43
> To: Jesske, R
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; Christer Holmberg (JO/LMF)
> 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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 07 Jun 2006 20:34:39 +0100

Cullen,

Yes, with option 3 it would indeed be UPDATE normally.

John

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 07 June 2006 15:00
> To: Elwell, John
> Cc: Jesske, R; [email-masked]; [email-masked]; 
> the To header f ield ina response
> 
> 
> In the reverse direction, why not use UPDATE?
> 
> On Jun 6, 2006, at 12:17 PM, Elwell, John wrote:
> 
> > The requirements have indeed been described in the 
> tispan-requirements
> > draft, but clearly there is still some misunderstanding. 
> Let me try  
> > to shed
> > some light, although my background is enterprise rather than  
> > carrier and I
> > don't pretend to understand all practices of PSTN or NGN.
> >
> > A PSTN carries two identities in each direction - one that has been
> > "authenticated" or "screened" by the PSTN and one that has been  
> > received
> > from outside the PSTN and has not been screened. The first type of  
> > identity
> > is used for billing, authorisation etc. within the PSTN, and may  
> > also be
> > delivered to the customer premises equipment. The second type of  
> > identity is
> > used only for delivery to the customer premises equipment. 
> What the  
> > customer
> > premises equipment does with the two types of identities is 
> not really
> > specified, but I think enterprise networks (e.g., based on 
> QSIG) would
> > normally use only the first type of identity for passing through the
> > enterprise network to the end user.
> >
> > I believe TISPAN has ambitions to support these two types of  
> > identity in
> > NGN, so this leads to the question how to carry the two identities  
> > in SIP.
> >
> > For the INVITE request, the first caller identity is carried in the
> > P-Asserted-Identity header, the first node in the NGN having  
> > authenticated
> > the source of the request by some means (e.g., through the 
> certificate
> > supplied during TLS handshake). The second caller identity is  
> > carried in the
> > From header. Obviously the latter is open to falsification unless  
> > supported
> > by an Identity header. With the Identity header, the second caller  
> > identity
> > would be far more useful to the destination customer premises  
> > equipment.
> >
> > For the reverse direction, the first callee identity is 
> carried in the
> > P-Asserted-Identity header, I believe. There are fewer 
> authentication
> > options, but I guess TLS-based authentication is still a  
> > possibility. So the
> > question is how to supply the second callee identity.
> >
> > Option 1. Modify the To header in the INVITE response. 
> There have been
> > objections to this. Also it would not be authenticated, so 
> it would  
> > not be
> > nearly as useful as the second identity in the request, which can be
> > authenticated by the Identity header.
> >
> > Option 2. Use the Reply-To header or some new header in the INVITE  
> > response.
> > The objections concerning modifying the To header go away, but  
> > again it
> > would not be authenticated, so it would not be nearly as 
> useful as the
> > second identity in the request.
> >
> > Option 3. Use the From header in conjunction with the Identity  
> > header in a
> > request in the reverse direction, as specified in the Connected- 
> > Identity
> > draft. This seems to solve the problem, except that it may make  
> > interworking
> > with PSTN signalling more difficult since PSTN expects the second  
> > identity
> > in the "answer" message. If a solution to this signalling  
> > interworking can
> > be found, I think option 3 would clearly be the best solution.
> >
> > John
> >
> >> From: Jesske, R [mailto:[email-masked]]
> >> Sent: 01 June 2006 09:42
> >> To: [email-masked]
> >> Cc: [email-masked]; [email-masked]; Elwell, John;
> >> Subject: AW: AW: AW: [Sip] Connected-identity and changing
> >> the To header f ield ina response
> >>
> >> The two identities are used for PBX services.
> >> Example
> >> If a user calls a special hotline for e.G. Computer Services.
> >> +496151830.
> >> This is the main number of a PBX with several extensions. The
> >> user will be at least connected to an Service Expert
> >> (Extension No: +496151831111).
> >> So now there is a Public Id (+496151830) that is trusted and
> >> the all billing is bind to. (TISPAN uses the P-Asserted-Identity)
> >> and a private not secure id of the Expert. Advantage is that
> >> the Caller has now the ability to see the real connected
> >> number where the expert can now called directly.
> >>
> >> This service is widely used within the PSTN/ISDN world and is
> >> known as COLP (Connected Line Identification Presentation)
> >> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free
> >> downloadable at portal.etsi.org).
> >>
> >> We have described the Requirements in
> >> draft-jesske-sipping-tispan-requirements-01 and did some
> >> analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt
> >>
> >> Best Regards
> >>
> >> Roland
> >>
> >>
> >>> Gesendet: Donnerstag, 1. Juni 2006 09:11
> >>> An: Jesske, Roland
> >>> Cc: [email-masked]; [email-masked];
> >>> [email-masked]; [email-masked];
> >>> [email-masked]
> >>> Betreff: Re: AW: AW: [Sip] Connected-identity and changing
> >>> What things use these two identities, what do they get used
> >> for, and
> >>> what security assumptions come around them. That type of
> >> information
> >>> would help people on this list understand the problem.
> >>>
> >>> On May 31, 2006, at 10:28 PM, Jesske, R wrote:
> >>>
> >>>> Paul,
> >> connected.
> >>>> So it is not in each case the real conected identity. But
> >> the COLP
> >>>> (TIP) service could be used in the same way.
> >> 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
> >>>>
> >>>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To
> >>>>> header field ina response
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Jesske, R wrote:
> >>>>> OK response is sufficient. So that avoids confusion within
> >>>>> forking cases.
> >>>>>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Cc: John Elwell; [email-masked]; Roland Jesske; Christer
> >>>>>>> Holmberg (JO/LMF)
> >>>>>>> Betreff: Re: [Sip] Connected-identity and changing the To
> >>>>>>> header field ina response
> >>>>>>>
> >>>>>>>
> >>>>>>>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Jun 2006 16:52:55 +0100

In my view, yes.

Keith

> Sent: 07 June 2006 16:41
> To: David R Oran
> Cc: Jesske, R; [email-masked]; [email-masked]; Elwell, John;
> What I am starting to discern here is a desire for multiple 
> identities 
> in the same message that are asserted by different authorities. 
> P-Asserted-Identity clearly can't do that. I guess there potentially 
> could be multiple instances of sip identity, though the logistics of 
> getting that asserted could be difficult. It has been suggested here 
> that P-Asserted-ID and sip identity could be used together to provide 
> two identities.
> 
> In any case, the value proposition is different if the multiple 
> identities are all authenticated to the satisfaction of the 
> recipient, 
> rather than one of them being untrustworthy.
> 
> So, am I right in thinking the goal is for multiple identities, 
> authenticated by different parties?
> 
> 	Thanks,
> 	Paul
> 
> David R Oran wrote:
> > 
> > On Jun 6, 2006, at 3:17 PM, Elwell, John wrote:
> > 
> Let me try to 
> >> shed
> >> some light, although my background is enterprise rather 
> than carrier 
> >> and I
> >> "authenticated" or "screened" by the PSTN and one that has 
> been received
> >> is used for billing, authorisation etc. within the PSTN, 
> and may also be
> >> premises equipment does with the two types of identities 
> is not really
> >> I believe TISPAN has ambitions to support these two types 
> of identity in
> >> NGN, so this leads to the question how to carry the two 
> identities in 
> >> SIP.
> >>
> >> supplied during TLS handshake). The second caller identity 
> is carried 
> >> in the
> >> would be far more useful to the destination customer 
> premises equipment.
> >>
> possibility. 
> >> So the
> >> The objections concerning modifying the To header go away, 
> but again it
> >> Option 3. Use the From header in conjunction with the 
> Identity header 
> >> in a
> >> request in the reverse direction, as specified in the 
> Connected-Identity
> >> can
> > Option 4: Use a Body, since this is strictly end-to-end and various 
> > forms of connected identity may be useful.
> > 
> >> John
> > 
>