Subject: [Sipping] RE: Concrete examples for to draft-vanelburg-sipping-served-user-01.txt

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Fri, 3 Aug 2007 10:35:29 +0200

Hi Jeroen,
 
The concrete example that triggered this is the 3GPP supplementary
service Communication Diversion. You would expect that when a call is
forwarded that the forwarded leg is originated by the forwarding user
and hence is treated as an originating leg also to be able to provide
originating services for the forwarding user. That is scenario 3.3. It
turned out not even to be possible to do that in IMS using the current
procedures. This draft provides part of the solution for that. The other
scenarios are added to show that solving the overloading problem, also
allows other scenarios.
 
Regarding service interaction: That is always an issue that need to be
looked at the specific cases. If one as an application deployer chooses
to allow continuation of iFC processing then all the additional
interaction cases have to be considered. 
 
I think the suggestion from Miguel to add a parameter whereby the
applications can control whether iFC processing continues or not is a
useful addition in this persective as well.
 
Best Regards,
 
/Hans Erik  
 
________________________________

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 10:06 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: sipping
Subject: Concrete examples for to
draft-vanelburg-sipping-served-user-01.txt

Hi Hans Erik,
 
Could you provide some more concrete examples of the scenarios described
in draft-vanelburg-sipping-served-user-01.txt section 3?
 
For example, 3.2 currently states "Imagine a service scenario where a
user B has a terminating service that diverts the call to a different
destination, but it is required that subsequent terminating services for
the same user are still executed.". I'm having trouble imagining such a
scenario, in particular what kind of subsequent terminating services you
have in mind here. On the other side, I can easily imagine examples
where the service interaction that results from continuening iFC
execution would be undesirable (for example: diversion followed by
anonymous call rejection)
 
Same question for 3.3 and 3.4. There appear to be several implicit
reasons which the reader is expected to know, from which apparently
these requirements follow.
 
Regards,
Jeroen
 
_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 5 Aug 2007 20:27:22 +0200

Hans Erik,

The way current IMS implementations deal with the case you mention is (to my 
knowledge) as follows: they look for a Diversion header in the INVITE 
(coming from the AS), if it is present it overrides the P-Asserted-Identity. 
This is not a standard procedure (yet) though, AFAIK

Is this the only concrete service scenario, or are there more?

Note that there are more aspects to diversion that are not well defined (for 
example: should the ICID remain the same or be generated anew?)

Regarding adding a parameter to give an AS control over aborting iFC 
processing: the AS does not know what other services follow, so how can it 
decide whether or not continuing makes sense? I think such a parameter would 
add more complexity and interop issues than it would solve

Regards,
Jeroen
  ----- Original Message ----- 
  From: Hans Erik van Elburg (RY/ETM)
  To: Jeroen van Bemmel
  Cc: sipping
  Sent: Friday, August 03, 2007 10:35 AM
  Subject: RE: Concrete examples for to 

  Hi Jeroen,

  The concrete example that triggered this is the 3GPP supplementary service 
Communication Diversion. You would expect that when a call is forwarded that 
the forwarded leg is originated by the forwarding user and hence is treated 
as an originating leg also to be able to provide originating services for 
the forwarding user. That is scenario 3.3. It turned out not even to be 
possible to do that in IMS using the current procedures. This draft provides 
part of the solution for that. The other scenarios are added to show that 
solving the overloading problem, also allows other scenarios.

  Regarding service interaction: That is always an issue that need to be 
looked at the specific cases. If one as an application deployer chooses to 
allow continuation of iFC processing then all the additional interaction 
cases have to be considered.

  I think the suggestion from Miguel to add a parameter whereby the 
applications can control whether iFC processing continues or not is a useful 
addition in this persective as well.

  Best Regards,

  /Hans Erik

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

  Hi Hans Erik,

  For example, 3.2 currently states "Imagine a service scenario where a user 
B has a terminating service that diverts the call to a different 
destination, but it is required that subsequent terminating services for the 
same user are still executed.". I'm having trouble imagining such a 
scenario, in particular what kind of subsequent terminating services you 
have in mind here. On the other side, I can easily imagine examples where 
the service interaction that results from continuening iFC execution would 
be undesirable (for example: diversion followed by anonymous call rejection)

  Same question for 3.3 and 3.4. There appear to be several implicit reasons 
which the reader is expected to know, from which apparently these 
requirements follow.

  Regards,
  Jeroen

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Mon, 6 Aug 2007 13:01:35 +0200

Jeroen,
 
The Diversion header as you say is non standard as it is described in an
expired draft, the History-Info header is documented in RFC4244. Both
3GPP, ETSI and other bodies have adopted the History-Info header for the
diversion service. The served-user draft contains an annex explaining
why that one does not solve the problem that the served-user draft seeks
to solve.
 
I have not finalised my thoughts yet on the addition of such a parameter
controlling continuation or not of iFC processing, one problem I see is
that it does not represent a property of the served-user but an
instruction on how to continue the iFC processing. This is maybe more of
a thing for 3GPP to sort out, but another option might be to extend the
iFC parameters this makes it more of a configuration/deployment time
issue. Then the only thing that needs to be corrected in the current
draft is to remove the suggestion that the presence of the P-Served-User
header controls whether iFC processing continues or not.
 
Best Regards,
/Hans Erik

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Sunday, August 05, 2007 8:27 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: sipping
Subject: Re: Concrete examples for to
draft-vanelburg-sipping-served-user-01.txt

Hans Erik,
 
The way current IMS implementations deal with the case you mention is
(to my knowledge) as follows: they look for a Diversion header in the
INVITE (coming from the AS), if it is present it overrides the
P-Asserted-Identity. This is not a standard procedure (yet) though,
AFAIK

Note that there are more aspects to diversion that are not well defined
(for example: should the ICID remain the same or be generated anew?)
 
Regarding adding a parameter to give an AS control over aborting iFC
processing: the AS does not know what other services follow, so how can
it decide whether or not continuing makes sense? I think such a
parameter would add more complexity and interop issues than it would
solve
 
Regards,
Jeroen

	----- Original Message ----- 
	From: Hans Erik van Elburg (RY/ETM)
<mailto:[email-masked]>  
	To: Jeroen van Bemmel <mailto:[email-masked]>  
	Cc: sipping <mailto:[email-masked]>  
	Sent: Friday, August 03, 2007 10:35 AM
	Subject: RE: Concrete examples for to
draft-vanelburg-sipping-served-user-01.txt

	Hi Jeroen,
	 
	The concrete example that triggered this is the 3GPP
supplementary service Communication Diversion. You would expect that
when a call is forwarded that the forwarded leg is originated by the
forwarding user and hence is treated as an originating leg also to be
able to provide originating services for the forwarding user. That is
scenario 3.3. It turned out not even to be possible to do that in IMS
using the current procedures. This draft provides part of the solution
for that. The other scenarios are added to show that solving the
overloading problem, also allows other scenarios.
	 
	Regarding service interaction: That is always an issue that need
to be looked at the specific cases. If one as an application deployer
chooses to allow continuation of iFC processing then all the additional
interaction cases have to be considered. 
	 
	I think the suggestion from Miguel to add a parameter whereby
the applications can control whether iFC processing continues or not is
a useful addition in this persective as well.
	 
	Best Regards,
	 
	/Hans Erik  

	Hi Hans Erik,
	 
	Could you provide some more concrete examples of the scenarios
described in draft-vanelburg-sipping-served-user-01.txt section 3?
	 
	For example, 3.2 currently states "Imagine a service scenario
where a user B has a terminating service that diverts the call to a
different destination, but it is required that subsequent terminating
services for the same user are still executed.". I'm having trouble
imagining such a scenario, in particular what kind of subsequent
terminating services you have in mind here. On the other side, I can
easily imagine examples where the service interaction that results from
continuening iFC execution would be undesirable (for example: diversion
followed by anonymous call rejection)
	 
	Same question for 3.3 and 3.4. There appear to be several
implicit reasons which the reader is expected to know, from which
apparently these requirements follow.
	 
	Regards,
	Jeroen

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 08 Aug 2007 09:18:32 +0300

Jeroen, Hans Erik, inline comments:

Jeroen van Bemmel wrote:
> P-Asserted-Identity. This is not a standard procedure (yet) though, AFAIK

The Diversion header does not exist. At least it is not documented 
anywhere, so it is a sign of non-existence.

> parameter would add more complexity and interop issues than it would solve

There are two aspects here. One is whether the addition of such 
parameter represents an interoperability problem or not. I believe it 
doesn't.

The other aspect is whether it makes sense and solves something. This is 
a complex aspect, because it is going to the heart of the service 
interaction. Here we have an Application Server indicating that it has 
executed a service, and on doing so, the result has been such a dramatic 
change that it makes no sense for the S-CSCF to continue executing the 
filter criteria. The S-CSCF receives this hint and has to take another 
decision: does it make sense to follow the hint? It may make sense to 
stop the filter criteria evaluation, because the remaining services are 
bogus after the execution of the first service, or there might be 
services that still need to be executed after all. I reckon this is a 
complex issue, and I am willing to hear opinions.

Without the parameter to give the hint, the S-CSCF will always have to 
either abort the FC evaluation or continue, but it does not have any 
input to take a decision. With the parameter, it has input from the AS, 
which can be overruled of course.

/Miguel

>     *From:* Hans Erik van Elburg (RY/ETM)
>     *To:* Jeroen van Bemmel <mailto:[email-masked]>
>     *Cc:* sipping <mailto:[email-masked]>
>     *Sent:* Friday, August 03, 2007 10:35 AM
>     *Subject:* RE: Concrete examples for to
>     service Communication Diversion. You would expect that when a call
>     is forwarded that the forwarded leg is originated by the forwarding
>     user and hence is treated as an originating leg also to be able to
>     provide originating services for the forwarding user. That is
>     scenario 3.3. It turned out not even to be possible to do that in
>     IMS using the current procedures. This draft provides part of the
>     solution for that. The other scenarios are added to show that
>     Regarding service interaction: That is always an issue that need to
>     be looked at the specific cases. If one as an application deployer
>     chooses to allow continuation of iFC processing then all the
>     additional interaction cases have to be considered.
>      
>     the applications can control whether iFC processing continues or not
>     is a useful addition in this persective as well.
>      
>     Best Regards,
>      
>     /Hans Erik  
>      
>     ------------------------------------------------------------------------
>     *From:* Jeroen van Bemmel [mailto:[email-masked]]
>     *Sent:* Thursday, July 19, 2007 10:06 PM
>     *To:* Hans Erik van Elburg (RY/ETM)
>     *Cc:* sipping
>     *Subject:* Concrete examples for to
>     For example, 3.2 currently states "Imagine a service scenario where
>     a user B has a terminating service that diverts the call to a
>     different destination, but it is required that subsequent
>     terminating services for the same user are still executed.". I'm
>     having trouble imagining such a scenario, in particular what kind of
>     subsequent terminating services you have in mind here. On the other
>     side, I can easily imagine examples where the service interaction
>     that results from continuening iFC execution would be undesirable
>     (for example: diversion followed by anonymous call rejection)
>      
> ------------------------------------------------------------------------
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: <[email-masked]>
Date: Thu, 9 Aug 2007 15:28:49 +0200

Miguel, Has Erik,

I foresee large interoperability issues with the proposed parameter with
which an AS could control continuation of iFC processing. You state it
is needed to deal with service interaction issues. Service interaction
is a voice and call control centric issue, which is well known in PSTN
(circuit switched) Intelligent Networks, and deals with the coordinated
execution of potentially conflicting call control -related services. 
But IMS is not a voice and call control centric architecture, instead we
require transparancy IMS in simply routing SIP messages. I believe SIP
has intrinsic features which may have solved or at least mitigated
largely most 'classical service interaction' issues.  

- IMS is a multimedia network which will multiply the means to
communicate between users. This may impact the need for call management
services.
- SIP forking permits the network to search for a user on various
devices. This will make 'traditional' call control less relevant than
before. Also, it would provide a better solution to the traditional
supplementary service use cases such as call forwarding.
- Presence will permit more intelligent call management services at UAC
level, and will certainly reduce the number of applications within one
SIP transaction, dialogue or session and the need for supporting service
interaction management between them. 
- IMS applications can more easily interact with users, possibly asking
them (caller, callee) how they wish to handle a call. This is in
contrast with circuit-switched networks, which have poor user interfaces
and therefore need to essentially work autonomously.
- The iFC allows routing of SIP messages to applications (servers), but
not to services. In circuit-switched the service was created in the
network entities. In SIP the 'service' is created in the UAC not in the
application server. This largely reduces the need for service
interaction management at IMS or application level.

The proposed parameter would make the faily simple iFC functionality
much more complex. Also this parameter would suggest that 'the network'
is in control and the Application chaining is done at 'network' level.
This could however also be done at UAC level. Interactions could than be
handled at UAC or as suggested above by explicitly requesting the user
on how to proceed. 

Hence,I do not see a need for your proposed parameter.

Colin Pons
Senior Architect
WSO Innovation Management
KPN

-----Oorspronkelijk bericht-----
Van: Miguel Garcia [mailto:[email-masked]] 
Verzonden: woensdag 8 augustus 2007 8:19
Aan: Jeroen van Bemmel
CC: sipping
Onderwerp: Re: [Sipping] Re: Concrete examples forto

AFAIK

solve

/Miguel

>     Regarding service interaction: That is always an issue that need
to
>     For example, 3.2 currently states "Imagine a service scenario
where

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 09 Aug 2007 17:43:35 +0300

Hi Colin:

I didn't understand what you are proposing in the absence of the 
parameter. Are you proposing that:

a) The S-CSCF always aborts Filter Criteria evaluation after the request 
bounces back to the S-CSCF.

b) The S-CSCF never aborts the FC evaluation after getting the request back.

c) The behavior of the S-CSCF is unspecified.

Thanks,

     Miguel

---

From: <[email-masked]>
Date: Fri, 10 Aug 2007 09:53:35 +0200

Hi Miguel

I am proposing that the S-CSCF does as little as possible other than
just sioimply routing SIP messages.

In case a SIP request bounces, i.e. the request could not be processed
properly, the next logical thing for the S-CSCF to do is to pass this on
to the UAC. Hence abort any iFC evaluation.

In the use case you referred to the App Server has 'changed'
dramatically the SIP session it makes no sense for S-CSCF to continue
iFC evaluation. I would think such a dramatic change would need to be
signaled (and agreed) with the UAC anyhow. So I do not see why a
parameter should be included to terminate iFC evaluation. The only
relevant case I can think of is the PSTN emulation service were the UAC
is 'dumb' (old black telephony is re-used) and would not be informed of
such dramatic change because an application more or less represents such
an UAC.

My personal opinion is that SIP (and hence IMS) are not voice and call
control centric. And we should not recreate the old telephony services
in IMS where they make less (if any at all) sense. In SIP the service is
created between user agents and anty significant change should be
negotiated between these user agents. I strongly feel that the parameter
you propose very well could break that model.
 
Colin Pons
Senior Architect

-----Oorspronkelijk bericht-----
Van: Miguel Garcia [mailto:[email-masked]] 
Verzonden: donderdag 9 augustus 2007 16:44
Aan: Pons, C.A. (Colin) (W O IM Service Innovatie)
CC: [email-masked]; [email-masked]
Onderwerp: Re: [Sipping] Re: Concrete examples forto

Hi Colin:

b) The S-CSCF never aborts the FC evaluation after getting the request
back.

Thanks,

     Miguel

>>     The concrete example that triggered this is the 3GPP
supplementary
>>     Same question for 3.3 and 3.4. There appear to be several
implicit

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 12:54:53 +0300

Hi Colin:

When I wrote "bounces back" I was referring when the S-CSCF is getting a 
request from the AS, after the same S-CSCF previously forwarded to the AS.

So, if you say the S-CSCF shouldn't interrupt the FC evaluation, then 
you may get into trouble as well. For example, if there are services 
that will be invoked after, e.g., a call forwarding. Assume a service 
reads the Request-URI or does some other action on a user who already 
diverted the session.

I agree service interaction is a complex issue. Because of this, I think 
the protocol needs to signal those cases where it does not make sense 
with the FC evaluation.

In any case, I would expect that this is further discussed and agreed in 
3GPP and the draft reflects 3GPP's needs. The IETF shouldn't take a 
position on the need of the parameter. Perhaps we got into the 
discussion when we tried to understand all the consequences, but as I 
said, it is not the SIPPING mission.

/Miguel

---

From: <[email-masked]>
Date: Fri, 10 Aug 2007 15:50:14 +0200

Miguel,

But by submitting such a draft to IETF you make it a SIPPING issue. In
fact by allowing such a parameter, SIPPING in my view would jeopardize
the end-to-end principle. The parameter would possibly adapt or modify
service behavior at SIP Proxy level (S-CSCF). 

To be frank, this parameter looks to me as badly conceived as the
original 3GPP draft on the 'Communication Services Identifier'. My
problem with these sorts of activities is twofold. First is that 3GPP
thinks too much in the old circuit-switched paradigms. As representative
of a converged telco I do not see the need you refer to (as a neither do
for the original 3GPP draft on the 'communication service identifier').
Although, I admit Call Forwarding would be implemented differently if
you would do it using SIP, why not just do that instead of shoe-horning
old solutions into new architectures.

Secondly, the proposed parameter as well as the mentioned 'communication
service identifier' are attempts to correct for bad architectural
designs and implementations. As listed earlier in these thread SIP
intrinsically has the capabilities to deal with the use cases you refer
to. Just use them! 

Colin Pons
Senior Architect
WO Innovation Management
KPN

-----Oorspronkelijk bericht-----
Van: Miguel Garcia [mailto:[email-masked]] 
Verzonden: vrijdag 10 augustus 2007 11:55
Aan: Pons, C.A. (Colin) (W O IM Service Innovatie)
CC: [email-masked]; [email-masked]
Onderwerp: Re: [Sipping] Re: Concrete examples forto

Hi Colin:

request from the AS, after the same S-CSCF previously forwarded to the
AS.

/Miguel

>>>     having trouble imagining such a scenario, in particular what
kind
>> of

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Fri, 10 Aug 2007 16:37:07 +0200

Colin,

This is extension is strictly ment as an extension on the ISC interface.
A well designed /implemented AS should not break end-to-end qualities of
SIP. This extension does not break that end-to-end principle in any way,
more then the linking in of an AS over ISC does. What the draft does is
fix a flaw in the 3GPP architecture that is correct.

Now the addition of the discussed parameter would not break the
end-to-end principle either. 

Since it is the need for such parameter is not identified by 3GPP I will
not add it to the draft. I think that this allows us to close that
discussion for the moment.

Best Regards,
/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Re: Concrete examplesforto

Miguel,

Colin Pons
Senior Architect
WO Innovation Management
KPN

-----Oorspronkelijk bericht-----
Van: Miguel Garcia [mailto:[email-masked]]
Verzonden: vrijdag 10 augustus 2007 11:55
Aan: Pons, C.A. (Colin) (W O IM Service Innovatie)
CC: [email-masked]; [email-masked]
Onderwerp: Re: [Sipping] Re: Concrete examples forto

Hi Colin:

/Miguel

kind
>>> 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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 10 Aug 2007 18:54:45 +0200

Just to point out that while there have been discussion documents in
3GPP identifying that there are some problems to fix, this document has
not yet been discussed by 3GPP, nor has the solution contained within it
been endorsed.

There are actually a number of interrelated issues here, and this
solution would appear to make some of them worse.

Regards

Keith 

> [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 3:37 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Re: Concreteexamplesforto 
> A well designed /implemented AS should not break end-to-end 
> qualities of SIP. This extension does not break that 
> end-to-end principle in any way, more then the linking in of 
> an AS over ISC does. What the draft does is fix a flaw in the 
> 3GPP architecture that is correct.
> 
> Now the addition of the discussed parameter would not break 
> the end-to-end principle either. 
> 
> Since it is the need for such parameter is not identified by 
> 3GPP I will not add it to the draft. I think that this allows 
> us to close that discussion for the moment.
> 
> Best Regards,
> /Hans Erik
> 
> But by submitting such a draft to IETF you make it a SIPPING 
> issue. In fact by allowing such a parameter, SIPPING in my 
> view would jeopardize the end-to-end principle. The parameter 
> would possibly adapt or modify service behavior at SIP Proxy 
> level (S-CSCF). 
> 
> To be frank, this parameter looks to me as badly conceived as 
> the original 3GPP draft on the 'Communication Services 
> Identifier'. My problem with these sorts of activities is 
> twofold. First is that 3GPP thinks too much in the old 
> circuit-switched paradigms. As representative of a converged 
> telco I do not see the need you refer to (as a neither do for 
> the original 3GPP draft on the 'communication service identifier').
> Although, I admit Call Forwarding would be implemented 
> differently if you would do it using SIP, why not just do 
> that instead of shoe-horning old solutions into new architectures.
> 
> Secondly, the proposed parameter as well as the mentioned 
> 'communication service identifier' are attempts to correct 
> for bad architectural designs and implementations. As listed 
> earlier in these thread SIP intrinsically has the 
> capabilities to deal with the use cases you refer to. Just use them! 
> 
> Colin Pons
> Senior Architect
> WO Innovation Management
> KPN
> 
> So, if you say the S-CSCF shouldn't interrupt the FC 
> evaluation, then you may get into trouble as well. For 
> example, if there are services that will be invoked after, 
> e.g., a call forwarding. Assume a service reads the 
> Request-URI or does some other action on a user who already 
> diverted the session.
> 
> the protocol needs to signal those cases where it does not 
> make sense with the FC evaluation.
> 
> 3GPP and the draft reflects 3GPP's needs. The IETF shouldn't 
> take a position on the need of the parameter. Perhaps we got 
> into the discussion when we tried to understand all the 
> consequences, but as I said, it is not the SIPPING mission.
> 
> /Miguel
> 
> > properly, the next logical thing for the S-CSCF to do is to 
> pass this
> on
> > in IMS where they make less (if any at all) sense. In SIP 
> the service
> is
> >> But IMS is not a voice and call control centric 
> architecture, instead
> > we
> >> This could however also be done at UAC level. Interactions 
> could than
> > be
> >>> processing: the AS does not know what other services 
> follow, so how
> >> can
> >> The other aspect is whether it makes sense and solves 
> something. This
> > is
> >>>     user and hence is treated as an originating leg also 
> to be able
> > to
> >>>     the applications can control whether iFC processing 
> continues or
> >> not
> >>>     described in 
> draft-vanelburg-sipping-served-user-01.txt section
> > 3?
> >>>      
> >>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Srivatsa Srinivasan <[email-masked]>
Date: Fri, 10 Aug 2007 09:40:59 -0700

Miguel,

Interesting draft that points out some of the shortcomings in 3GPP service interaction.

The most interesting question is how would this be used outside the scope of 3GPP? What guidelines do you have to systems outside the scope of 3GPP for its use?

It may be one thing to constrict this scenario to solve a service interaction hole present in 3GPP, however, as others have pointed out it may just be too generic to be used in an interoperable fashion unless there is a clear understanding of (and guidelines defined for) the non-3GPP uses.

For example, would a terminating service need to know the served user in the originating interaction? Are there cases where, perhaps, History-Info or something like it makes more sense and we end up implementing systems that use both (this proposal for the short-term and something else for the longer term)? Would this be bubbled up to the UE (for example, P-Asserted-Identity is in some systems) to indicate some action that has taken place that a user may want to see?

Regards,
Srivatsa.

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: Tuesday, August 07, 2007 11:19 PM
To: Jeroen van Bemmel
Cc: sipping
Subject: Re: [Sipping] Re: Concrete examples for to draft-vanelburg-sipping-served-user-01.txt

/Miguel

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Mon, 13 Aug 2007 11:42:48 +0200

Srivatsa,

The header is defined only to be applicable on the ISC interface as
defined by 3GPP as is clearly indicated in the draft. Saying that, there
are no guidelines to its use outside the context of 3GPP IMS.

For a terminating service the served user is the terminating user. The
originator of a session can be learned from the P-Asserted-Identity.
There may have been several forwardings, for which the different
diverting parties may be known to a terminating service from
History-Info header entries. Note that the draft contains an appendix
that explains why the History-Info header is not ideal for conveying
served user information. Now to your question, what do you mean with a
terminating service needing to know "the" served user of the originating
interaction? 

On your question regarding the UE, the UE would never see this
extension. But maybe I misunderstand your question?

Best Regards,
/Hans Erik 

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 6:41 PM
To: Miguel From [email-masked] Mon Aug 13 05:49:34 2007
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Re: Concrete examples
	for	todraft-vanelburg-sipping-served-user-01.txt
Date: Mon, 13 Aug 2007 11:42:48 +0200
To: "Srivatsa Srinivasan" <[email-masked]>,
	"Miguel Garcia" <[email-masked]>,
	"Jeroen van Bemmel" <[email-masked]>
Cc: sipping <[email-masked]>

Srivatsa,

The header is defined only to be applicable on the ISC interface as
defined by 3GPP as is clearly indicated in the draft. Saying that, there
are no guidelines to its use outside the context of 3GPP IMS.

For a terminating service the served user is the terminating user. The
originator of a session can be learned from the P-Asserted-Identity.
There may have been several forwardings, for which the different
diverting parties may be known to a terminating service from
History-Info header entries. Note that the draft contains an appendix
that explains why the History-Info header is not ideal for conveying
served user information. Now to your question, what do you mean with a
terminating service needing to know "the" served user of the originating
interaction? 

On your question regarding the UE, the UE would never see this
extension. But maybe I misunderstand your question?

Best Regards,
/Hans Erik 

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 6:41 PM
To: Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for
todraft-vanelburg-sipping-served-user-01.txt

Miguel,

Interesting draft that points out some of the shortcomings in 3GPP
service interaction.

The most interesting question is how would this be used outside the
scope of 3GPP? What guidelines do you have to systems outside the scope
of 3GPP for its use?

It may be one thing to constrict this scenario to solve a service
interaction hole present in 3GPP, however, as others have pointed out it
may just be too generic to be used in an interoperable fashion unless
there is a clear understanding of (and guidelines defined for) the
non-3GPP uses.

For example, would a terminating service need to know the served user in
the originating interaction? Are there cases where, perhaps,
History-Info or something like it makes more sense and we end up
implementing systems that use both (this proposal for the short-term and
something else for the longer term)? Would this be bubbled up to the UE
(for example, P-Asserted-Identity is in some systems) to indicate some
action that has taken place that a user may want to see?

Regards,
Srivatsa.

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: Tuesday, August 07, 2007 11:19 PM
To: Jeroen van Bemmel
Cc: sipping
Subject: Re: [Sipping] Re: Concrete examples for to

> Note that there are more aspects to diversion that are not well 
> defined (for example: should the ICID remain the same or be generated 
> anew?)
>
> processing: the AS does not know what other services follow, so how 
> can it decide whether or not continuing makes sense? I think such a 

/Miguel

>     serviGarcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for
todraft-vanelburg-sipping-served-user-01.txt

Miguel,

Interesting draft that points out some of the shortcomings in 3GPP
service interaction.

The most interesting question is how would this be used outside the
scope of 3GPP? What guidelines do you have to systems outside the scope
of 3GPP for its use?

It may be one thing to constrict this scenario to solve a service
interaction hole present in 3GPP, however, as others have pointed out it
may just be too generic to be used in an interoperable fashion unless
there is a clear understanding of (and guidelines defined for) the
non-3GPP uses.

For example, would a terminating service need to know the served user in
the originating interaction? Are there cases where, perhaps,
History-Info or something like it makes more sense and we end up
implementing systems that use both (this proposal for the short-term and
something else for the longer term)? Would this be bubbled up to the UE
(for example, P-Asserted-Identity is in some systems) to indicate some
action that has taken place that a user may want to see?

Regards,
Srivatsa.

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: Tuesday, August 07, 2007 11:19 PM
To: Jeroen van Bemmel
Cc: sipping
Subject: Re: [Sipping] Re: Concrete examples for to

> Note that there are more aspects to diversion that are not well 
> defined (for example: should the ICID remain the same or be generated 
> anew?)
>
> processing: the AS does not know what other services follow, so how 
> can it decide whether or not continuing makes sense? I think such a 

/Miguel

to
where

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Mon, 13 Aug 2007 19:37:35 +0200

Hi Srivatsa,

Regarding your first question as the P-Served-User header will not be
forwarded when the originating S-CSCF forwards it downstream to the
terminating S-CSCF, therefore such interaction can not occur.

For the same reason the UE will never see this as the S-CSCF removes the
P-Served-User header before forwarding the request downstream towards
the UE via the P-CSCF.

Hope this clarifies.

Best Regards,

/Hans Erik 

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 7:18 PM
To: Hans Erik van Elburg (RY/ETM); Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples
fortodraft-vanelburg-sipping-served-user-01.txt

Hi Hans,

Sorry I wasn't clear about the two questions. I have been assuming that
when a P-Served-User headed is sent on the ISC interface, that the proxy
(in the application server) would simply proxy it without the header
being removed after the request is handled. And the following questions
are based on that assumption.

To elaborate on the first question, I was referring to Section 3.4 where
you mention that the P-Asserted-Identity is overloaded with two meanings
in the originating interaction. I assume that the P-Served-User would be
used, in the originating interaction, to disambiguate this meaning. And
so, it wasn't clear to me what a P-Served-User inserted in the
originating interaction meant to the terminating interaction. I assume
that if the two sides are within the same trust domain that the header
would be carried forward from the originating side to the terminating
side. If the terminating interaction also needed the P-Served-User,
would the terminating interaction end up with two P-Served-Users at some
point?

With regards to the second question, you mention that the UE would never
see this response. Is that because the current use-cases do not warrant
it? Wouldn't they end up being sent anyway if there is no privacy
enforced and the UE is within the same trust domain?

Thanks,
Srivatsa.

-----Original Message-----
From: Hans Erik van Elburg (RY/ETM)
[mailto:[email-masked]]
Sent: Monday, August 13, 2007 2:43 AM
To: Srivatsa Srinivasan; Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for
todraft-vanelburg-sipping-served-user-01.txt

Srivatsa,

Best Regards,
/Hans Erik

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]]
Sent: Friday, August 10, 2007 6:41 PM
To: Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for

Miguel,

Regards,
Srivatsa.

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: Tuesday, August 07, 2007 11:19 PM
To: Jeroen van Bemmel
Cc: sipping
Subject: Re: [Sipping] Re: Concrete examples for to

/Miguel

to
where

---

From: Srivatsa Srinivasan <[email-masked]>
Date: Mon, 13 Aug 2007 10:17:58 -0700

Hi Hans,

Sorry I wasn't clear about the two questions. I have been assuming that when a P-Served-User headed is sent on the ISC interface, that the proxy (in the application server) would simply proxy it without the header being removed after the request is handled. And the following questions are based on that assumption.

To elaborate on the first question, I was referring to Section 3.4 where you mention that the P-Asserted-Identity is overloaded with two meanings in the originating interaction. I assume that the P-Served-User would be used, in the originating interaction, to disambiguate this meaning. And so, it wasn't clear to me what a P-Served-User inserted in the originating interaction meant to the terminating interaction. I assume that if the two sides are within the same trust domain that the header would be carried forward from the originating side to the terminating side. If the terminating interaction also needed the P-Served-User, would the terminating interaction end up with two P-Served-Users at some point?

With regards to the second question, you mention that the UE would never see this response. Is that because the current use-cases do not warrant it? Wouldn't they end up being sent anyway if there is no privacy enforced and the UE is within the same trust domain?

Thanks,
Srivatsa.

-----Original Message-----
From: Hans Erik van Elburg (RY/ETM) [mailto:[email-masked]]
Sent: Monday, August 13, 2007 2:43 AM
To: Srivatsa Srinivasan; Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for todraft-vanelburg-sipping-served-user-01.txt

Srivatsa,

Best Regards,
/Hans Erik

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]]
Sent: Friday, August 10, 2007 6:41 PM
To: Miguel Garcia; Jeroen van Bemmel
Cc: sipping
Subject: RE: [Sipping] Re: Concrete examples for

Miguel,

Regards,
Srivatsa.

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]]
Sent: Tuesday, August 07, 2007 11:19 PM
To: Jeroen van Bemmel
Cc: sipping
Subject: Re: [Sipping] Re: Concrete examples for to

/Miguel

to
where