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

[Srivatsa Srinivasan <[e-mail]>]

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