Subject: Re: [Sipping] draft-vanelburg-sipping-served-user-01.txt

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 10 Aug 2007 19:30:46 +0200

Hans Erik,

In your draft you state that the problem is that P-Asserted-Identity has an 
overload meaning of both "call originator" and "served user", which causes 
scenario 3.3 to fail

Another way to look at this, is the following: suppose the AS in scenario 
3.3 would also rewrite the P-Asserted-Identity header. Then everything would 
work as expected, except that the information about the call originator is 
now lost. As a consequence, the Originating Identity Presentation (OIP) 
service as defined in 3GPP 24.173 which you refer to no longer works (i.e. 
callee sees "wrong" caller information).

So one could also say that OIP is broken in case of call diversion. If it 
would use the From header as its basis for call originator information, then 
there would be no problem

One of the problems I have with P-Served-User, is that it adds to the 
already too long list of URIs representing some role of some entity involved 
in the session (From, To, P-AID, P-PID, Diversion, History-Info, and various 
others defined elsewhere such as RFC3603). Just because SIP is extensible 
does not mean that extending it is the solution to every problem. Try using 
what's already defined

Regards,
Jeroen

Hans Erik van Elburg (RY/ETM) wrote:
> Just to notify you that a new version of this draft is available,
> taking into account  the received comments.
> Best Regards,
> /Hans Erik
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 22, 2007 9:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-vanelburg-sipping-served-user-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : The Session Initiation Protocol (SIP)
> P-Served-User Private-Header (P-Header)
> Author(s) : H. van Elburg
> Filename : draft-vanelburg-sipping-served-user-01.txt
> Pages : 14
> Date : 2007-6-22
>
> This document specifies the SIP P-Served-User P-header.  This header
>    field addresses an issue that was found in the 3rd-Generation
>    Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an
>    S-CSCF (Serving Call Session Control Function) and an AS
>    (Application Server) on the ISC (IMS Subsystem Service Control)
>    interface to convey the identity of the served user and the
>    session case that applies to this particular communication session
>    and application invocation.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vanelburg-sipping-served-user-
> 01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-vanelburg-sipping-served-user-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE
> /internet-drafts/draft-vanelburg-sipping-served-user-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
>
>> _______________________________________________
>> 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: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Mon, 13 Aug 2007 11:47:14 +0200

If the requirement is that the asserted identity needs to be delivered
to the terminating network, whether the call is diverted or not then
doing as you say makes that impossible.

I understand your concern about yet another header carrying an identity,
but we have to see that this is only very limited between an S-CSCF and
an AS. This header is never passed on outside the network of the served
user, so it is not an end-to-end identity header. UE's for example will
never see it.

/Hans Erik

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:31 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: Re: [Sipping] draft-vanelburg-sipping-served-user-01.txt 

Hans Erik,

In your draft you state that the problem is that P-Asserted-Identity has
an overload meaning of both "call originator" and "served user", which
causes scenario 3.3 to fail

Another way to look at this, is the following: suppose the AS in
scenario
3.3 would also rewrite the P-Asserted-Identity header. Then everything
would work as expected, except that the information about the call
originator is now lost. As a consequence, the Originating Identity
Presentation (OIP) service as defined in 3GPP 24.173 which you refer to
no longer works (i.e. 
callee sees "wrong" caller information).

So one could also say that OIP is broken in case of call diversion. If
it would use the From header as its basis for call originator
information, then there would be no problem

One of the problems I have with P-Served-User, is that it adds to  with local (Exim 4.43)
	id 1IKWW5-0008Od-R3 for [email-masked];
	Mon, 13 Aug 2007 05:47:17 -0400
Content-class: urn:content-classes:message
Subject: RE: [Sipping] draft-vanelburg-sipping-served-user-01.txt 
Date: Mon, 13 Aug 2007 11:47:14 +0200
From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>,
	<[email-masked]>
Cc: 

If the requirement is that the asserted identity needs to be delivered
to the terminating network, whether the call is diverted or not then
doing as you say makes that impossible.

I understand your concern about yet another header carrying an identity,
but we have to see that this is only very limited between an S-CSCF and
an AS. This header is never passed on outside the network of the served
user, so it is not an end-to-end identity header. UE's for example will
never see it.

/Hans Erik

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 7:31 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: Re: [Sipping] draft-vanelburg-sipping-served-user-01.txt 

Hans Erik,

In your draft you state that the problem is that P-Asserted-Identity has
an overload meaning of both "call originator" and "served user", which
causes scenario 3.3 to fail

Another way to look at this, is the following: suppose the AS in
scenario
3.3 would also rewrite the P-Asserted-Identity header. Then everything
would work as expected, except that the information about the call
originator is now lost. As a consequence, the Originating Identity
Presentation (OIP) service as defined in 3GPP 24.173 which you refer to
no longer works (i.e. 
callee sees "wrong" caller information).

So one could also say that OIP is broken in case of call diversion. If
it would use the From header as its basis for call originator
information, then there would be no problem

One of the problems I have with P-Served-User, is that it adds to the
already too long list of URIs representing some role of some entity
involved in the session (From, To, P-AID, P-PID, Diversion,
History-Info, and various others defined elsewhere such as RFC3603).
Just because SIP is extensible does not mean that extending it is the
solution to every problem. Try using what's already defined

Regards,
Jeroen

Hans Erik van Elburg (RY/ETM) wrote:
> Title : The Session Initiation Protocol (SIP) P-Served-User 
> Private-Header (P-Header)

> logging in, type "cd internet-drafts" and then "get 
> draft-vanelburg-sipping-served-user-01.txt".
>
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> MIME-encoded form by using the "mpack" utility.  To use this feature, 
> insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or a 
> MIME-compliant mail reader.  Different MIME-compliant mail readers 
> exhibit different behavior, especially when dealing with "multipart" 
> MIME messages (i.e. documents which have been split up into multiple 
> messages), so check your local documentation on how to manipulate 
> these messages.
>
>> 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

the
already too long list of URIs representing some role of some entity
involved in the session (From, To, P-AID, P-PID, Diversion,
History-Info, and various others defined elsewhere such as RFC3603).
Just because SIP is extensible does not mean that extending it is the
solution to every problem. Try using what's already defined

Regards,
Jeroen

Hans Erik van Elburg (RY/ETM) wrote:
> Title : The Session Initiation Protocol (SIP) P-Served-User 
> Private-Header (P-Header)

> logging in, type "cd internet-drafts" and then "get 
> draft-vanelburg-sipping-served-user-01.txt".
>
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> MIME-encoded form by using the "mpack" utility.  To use this feature, 
> insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or a 
> MIME-compliant mail reader.  Different MIME-compliant mail readers 
> exhibit different behavior, especially when dealing with "multipart" 
> MIME messages (i.e. documents which have been split up into multiple 
> messages), so check your local documentation on how to manipulate 
> these messages.
>
>> 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