Subject: [Sipping] New I-D for P-Served-User header

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 17 Apr 2007 14:11:34 +0200

I uploaded a new draft for the P-Served-User Private-Header, until it
gets available on the online Internet-Drafts directory you can retrieve
it here:
http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user
-00.txt 

Abstract

   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.

Best Regards,

/Hans Erik

_______________________________________________
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: Tue, 17 Apr 2007 09:29:57 -0400

Unlike the proposal for the service id, this proposal seems benign. 
(While I could quibble about how things are done in IMS, this sort of 
thing is their business, not ours.)

I would make a small comment about the ABNF: as written the specifically 
defined parameters must appear in a particular order, and prior to any 
extension parameters. That is pretty limiting and contrary to common 
practice. So I would suggest instead making the syntax something like:

P-Served-User            = "P-Served-User" HCOLON PServedUser-value
                                            *(SEMI served-user-param)
served-user-param        = sessioncase-param
                            / registration-state-param
                            / generic-param )
PServedUser-value        = name-addr / addr-spec
sessioncase-param        = "sescase" EQUAL "orig" / "term"
registration-state-param = "regstate" EQUAL "unreg" / "reg"

	Paul

Hans Erik van Elburg (RY/ETM) wrote:
> ___http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user-00.txt_ 
> 
> 
> Abstract
> 
> */Hans Erik*
> ------------------------------------------------------------------------
>

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 17 Apr 2007 16:27:24 +0200

Yes I think that is a good suggestion I will take this change in the
next version.
Thanks,
/Hans Erik 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 3:30 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: [email-masked]
Subject: Re: [Sipping] New I-D for P-Served-User header

	Paul

Hans Erik van Elburg (RY/ETM) wrote:
> gets available on the online Internet-Drafts directory you can 
> retrieve it here:
> 
> 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: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Tue, 17 Apr 2007 08:11:34 -0700

Hans

Will it be correct to assert that there is no requirement to use this
header in the absence of diversion?

The  ServiceInfo in the iFC could convey the session case which, in
turn, implicitly indicate whether the served user is in the PAID or
ReqUri.

Until I read the (very well-written) diversion sections, I was
unconvinced about the need for this header.

Perhaps, you could add a note indicating as much. This will help keep
the message size from becoming larger with redundant information.

Perhaps it may be useful to point out the reg state needs to be sent
only if the AS is not getting triggered out (by an iFC) for REGISTERs.

Regards

Venkat

________________________________

From: Hans Erik van Elburg (RY/ETM)
[mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 7:12 AM
To: [email-masked]
Subject: [Sipping] New I-D for P-Served-User header

http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user
-00.txt
<http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-use
r-00.txt>  

Abstract

Best Regards, 

/Hans Erik

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 17 Apr 2007 18:10:00 +0200

Hi Venkat,
 
I think that there are two approaches:
1. Only include it when needed. Leads to slightly smaller messages in
the normal case.
2. Always include it, making the served user determination for the AS a
trivial task. And is a cleaner solution in general. 
 
Both approaches have their merits. I prefer to say nothing at all and
let 3GPP decide upon the usage when they design the procedures around
this.
 
Regarding your last point similar applies, further I am hesitant to
introduce such cross iFC dependencies.
 
Best Regards,
/Hans Erik

From: Arunachalam Venkatraman (arunvenk) [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 5:12 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: RE: [Sipping] New I-D for P-Served-User header

Hans

Regards

Venkat

Abstract

Best Regards, 

/Hans Erik

---

From: "adi" <[email-masked]>
Date: Wed, 18 Apr 2007 17:35:05 +0300

In the case of call out of the blue, is the responsibility to add the
P-Served-User is on the AS 

Adi 

  _____  

From: Hans Erik van Elburg (RY/ETM)
[mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 3:12 PM
To: [email-masked]
Subject: [Sipping] New I-D for P-Served-User header

I uploaded a new draft for the P-Served-User Private-Header, until it gets
available on the online Internet-Drafts directory you can retrieve it here:

<http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user-00
.txt>
http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user-00.
txt 

Abstract

Best Regards, 

/Hans Erik

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Wed, 18 Apr 2007 17:19:16 +0200

Yes.
/Hans Erik

From: adi [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 4:35 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: RE: [Sipping] New I-D for P-Served-User header

Adi 

Abstract

Best Regards, 

/Hans Erik

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 29 Apr 2007 22:46:20 +0200

New I-D for P-Served-User headerHans,

A colleague of mine pointed out sections 6.5.1 and 6.5.2 in TS 23.218, third 
bullet:
-     in case the Request-URI changes when visiting an Application Server, 
terminate the checking of filter criterias, route the request based on the 
changed value of the Request-URI and do not execute the subsequent steps;

In other words, what you describe in your section 3.2 (diversion while 
continueing on terminating leg) would not occur for an S-CSCF that follows 
the standards

Regarding section 3.3: if the AS converts the incoming terminating request 
to a new originating request for user B, shouldn't it also update the 
P-Asserted-Identity header to reflect the new originating user?

Regards,
Jeroen
  ----- Original Message ----- 
  From: Hans Erik van Elburg (RY/ETM)
  To: [email-masked]
  Sent: Tuesday, April 17, 2007 2:11 PM
  Subject: [Sipping] New I-D for P-Served-User header

  http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user-00.txt

  Abstract

  Best Regards,

  /Hans Erik

------------------------------------------------------------------------------

---

From: "adi" <[email-masked]>
Date: Mon, 30 Apr 2007 10:54:48 +0300

Jeroen,

P-Asserted-Identity it needs to remain the originator of the call and to use
history-info or diversion to pass the redirector address.

Look at VM redirection or any Call Forwarding for example.

Adi

  _____  

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 11:46 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: Re: [Sipping] New I-D for P-Served-User header

Hans,

-               in case the Request-URI changes when visiting an Application
Server, terminate the checking of filter criterias, route the request based
on the changed value of the Request-URI and do not execute the subsequent
steps;

Regards,

Jeroen

----- Original Message ----- 

From: Hans Erik van Elburg (RY/ETM)
<mailto:[email-masked]>  

To: [email-masked] 

Abstract

Best Regards, 

/Hans Erik 

  _____

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Mon, 30 Apr 2007 21:37:50 +0200

Hi Jeroen,
 
When a call is forwarded the originator of the call does not change,
therefore it is required that the P-Asserted-Identity remains the same.
 
Regarding your other comment, it is true that it is not possible now as
this scenario was not envisioned in 3GPP, when th e procedures where
written. The P-Served-User header makes it possible, but still there are
changes required to the 3GPP procedures. You spotted one place. What we
need to do is make these changes in a backward compatible manner. For
example when the P-Served-User header is not included, the existing
behaviour prevails. 
 
So the scenario is kind of a what-if, then what is needed to make it
work. I got similar commments before and I added a note to section 3.2
clarifying this:
http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user
-01-presubmission-rev2.txt
 
Best Regards,
 
/Hans Erik

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 10:46 PM
To: Hans Erik van Elburg (RY/ETM); [email-masked]
Subject: Re: [Sipping] New I-D for P-Served-User header

Hans,
 
A colleague of mine pointed out sections 6.5.1 and 6.5.2 in TS 23.218,
third bullet:
-     in case the Request-URI changes when visiting an Application
Server, terminate the checking of filter criterias, route the request
based on the changed value of the Request-URI and do not execute the
subsequent steps;
 
In other words, what you describe in your section 3.2 (diversion while
continueing on terminating leg) would not occur for an S-CSCF that
follows the standards
 
Regarding section 3.3: if the AS converts the incoming terminating
request to a new originating request for user B, shouldn't it also
update the P-Asserted-Identity header to reflect the new originating
user?
 
Regards,
Jeroen

	----- Original Message ----- 

	I uploaded a new draft for the P-Served-User Private-Header,
until it gets available on the online Internet-Drafts directory you can
retrieve it here:

	Abstract
	
	   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.
	
	Best Regards, 

	/Hans Erik 

	

	_______________________________________________
	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