RE: [Sipping] Re: Concrete examples fortodraft-vanelburg-sipping-served-user-01.txt

["Hans Erik van Elburg (RY/ETM)" <[e-mail]>]

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:[e-mail]] 
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:[e-mail]]
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,

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:[e-mail]]
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:[e-mail]]
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

Jeroen, Hans Erik, inline comments:

Jeroen van Bemmel wrote:
> 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

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

>
> 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

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



>
> Regards,
> Jeroen
>
>     ----- Original Message -----
>     *From:* Hans Erik van Elburg (RY/ETM)
>     <mailto:[e-mail]>
>     *To:* Jeroen van Bemmel <mailto:[e-mail]>
>     *Cc:* sipping <mailto:[e-mail]>
>     *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
>
>
------------------------------------------------------------------------
>     *From:* Jeroen van Bemmel [mailto:[e-mail]]
>     *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 
> [e-mail] for questions on current sip Use 
> [e-mail] for new developments of core SIP

--
Miguel A. Garcia           tel:[phone]
Nokia Siemens Networks     Espoo, Finland



_______________________________________________
Sipping mailing list  https://www1.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://www1.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://www1.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