Re: [Sipping] P-Served-User contents

["Ian Elz" <[e-mail]>]

Rocio,

The values which will be used in the P-Served-User will depend upon scenario.

If the S-CSCF and AS are acting for the originating subscriber the P-Served-User URI would normally be obtained from the P-Asserted-Identity.

For a called subscriber the URI would be taken from the R-URI.

These are the normal ways of identifying the served user.

For a diverting subscriber the P-Served-User URI would be taken from the R-URI when the terminating call is received. After diversion the R-URI is modified and some of the originating services for the diverting subscriber may need to be performed. This is the most obvious case for the requirement for the P-Served-User header as following the diversion neither the P-Asserted-Identity nor the R-URI contains the identity of the served user.

There is still one piece missing from the jigsaw however. Following the diversion some of the originating services may operate differently depending upon what has happened to the INVITE. E.g. OIR should now operate based upon the fact that the INVITE has been diverted, e.g. the OIR service should not modify the Privacy header as this is the privacy values relating to the originating user. In the diversion case the OIR service of the diverting, served user, should protect the diverting users privacy and should therefore either insert a History tag into the Privacy header if necessary of add history privacy to specific History-Info headers.

I don't believe that this new requirement should be included in the P-Served-User header however as the PSU is normally controlled by the S-CSCF and is only set by the AS in cases where the INVITE has not been passed via the S-CSCF. As a result there is a requirement for a new header which can be inserted by the AS and removed by the CSCF. 

This requirement is still to be considered. 

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: [phone]
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Rocío Collado
Sent: 14 October 2008 08:18
To: 'sipping'
Cc: [e-mail]
Subject: [Sipping] P-Served-User contents

Hi, all!!


	After having read I-D draft-vanelburg-sipping-served-user-07.txt
there is something unclear to me:

Where are the P-Served-User header field contents extracted from? (in
particular, in the session establishment procedure)

Is this header field filled in with some other header value (Request-URI,
P-Asserted-Id...)? Is perhaps the value taken from some previously stored
information (from registration or subscription procedure)? Does it depend on
the scenario? Do the S-CSCF and the AS extract it from the same origin?

	Thank you very much for your help!!


Rocío Collado Collado
eXperience Ingeniería y Servicios - Boecillo
Tlf.:     983 54 98 48
Móvil: 659 74 57 91
[e-mail]

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] En nombre de
DRAGE, Keith (Keith)
Enviado el: jueves, 18 de septiembre de 2008 19:51
Para: Paul Kyzivat; sipping
Asunto: Re: [Sipping] I-D Action:draft-vanelburg-sipping-served-user-07.txt

Paul wrote:

> >  o The next hop proxy supports the P-Served-User header.	
> >  o The next hop proxy requires the served user information
> >    for its proper operation.	
> 
> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
>

The normal way of dealing with this is that if the next hop does not
support the header, it is configured to not form part of the same trust
domain, and therefore it would be removed by those rules.

That I believe is consistent with your final comment, and indeed has the
same effect.

It is also the way we've defined it is defined in IMS (I think)!

Keith



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Monday, September 08, 2008 11:37 PM
> To: sipping
> Subject: Re: [Sipping] I-D 
> Action:draft-vanelburg-sipping-served-user-07.txt
> 
> I haven't looked at this since version -00. Compared to that, 
> this is much improved.
> 
> This is clearly very focused for IMS usage, and not 
> meaningful in anything much different from that. But it is a 
> P- header, and so that scoping is ok.
> 
> Just a couple of comments:
> 
> Section 7.1 says:
> 
> >  o The next hop proxy is part of the same Trust Domain
> >    for P-Served-User.	
> 
> Its not good to talk about the "next hop proxy". While you 
> can tell the address of the next hop, whether it is a proxy 
> or not is not determinable by examining the address. So I 
> think it is better to simply 
> say: "the next hop is part of the same Trust Domain", etc.	
> 
> >  o The next hop proxy supports the P-Served-User header.	
> >  o The next hop proxy requires the served user information
> >    for its proper operation.	
> 
> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
> 
> Section 7.2 says:
> 
> > A proxy that supports the header, MUST remove the header 
> from requests 
> > or responses before further
> > forwarding the message.	
> > 				
> > When the next hop might requires served user information, then the 
> > procedure as in Section 7.1 MUST apply before
> > forwarding the message.	
> 
> Combined with 7.1, this means that the strategy for keeping 
> this header from leaking out into the wild is to insert if 
> for exactly one hop, and depend on the recipient to remove 
> it. This puts a dependency on a lot of nodes.
> 
> Wouldn't it be more consistent to treat this more like 
> P-Asserted-Identity? Namely, remove the header when leaving 
> the trust domain. This only requires the last element in the 
> trust domain to remove it.
> 
> For this header there is the added complication that the role 
> can change from originating to terminating without leaving 
> the trust domain. So it would also be necessary to 
> remove/replace the (old) header when changing roles. But it 
> still need only be done by select elements.
> 
> This would mean that one could always insert the header when 
> sending to 
> an AS, without regard for whether the AS supports it or not.	
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [e-mail] for questions on current 
> sip Use [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

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