RE: [Sipping] Re: Concrete examples for todraft-vanelburg-sipping-served-user-01.txt
Srivatsa Srinivasan <srivats@exchange.microsoft.com> Wed, 15 August 2007 23:16 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILS6S-0005xZ-1N; Wed, 15 Aug 2007 19:16:40 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1IKdYJ-0000LY-R2 for sipping-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:18:03 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdYJ-0000LQ-Et for sipping@ietf.org; Mon, 13 Aug 2007 13:18:03 -0400
Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKdYI-0005au-7t for sipping@ietf.org; Mon, 13 Aug 2007 13:18:03 -0400
Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.177.1; Mon, 13 Aug 2007 10:18:01 -0700
Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Mon, 13 Aug 2007 10:18:01 -0700
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: "Hans Erik van Elburg (RY/ETM)" <hanserik.van.elburg@ericsson.com>, Miguel Garcia <Miguel.Garcia@nsn.com>, Jeroen van Bemmel <jbemmel@zonnet.nl>
Date: Mon, 13 Aug 2007 10:17:58 -0700
Subject: RE: [Sipping] Re: Concrete examples for todraft-vanelburg-sipping-served-user-01.txt
Thread-Topic: [Sipping] Re: Concrete examples for todraft-vanelburg-sipping-served-user-01.txt
Thread-Index: AcfZhAmcfBnLPB3hSRGu28/BKOJ90QB5YBGQAIhLVpAAD7tecA==
Message-ID: <C916C5C17067EA4A93577D163338D137010F397227C8@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <C916C5C17067EA4A93577D163338D137010F397223BA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <CAC481363DB73049924DDDCFC1AC60A6044F8654@esealmw109.eemea.ericsson.se>
In-Reply-To: <CAC481363DB73049924DDDCFC1AC60A6044F8654@esealmw109.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -100.0 (---------------------------------------------------)
X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df
X-Mailman-Approved-At: Wed, 15 Aug 2007 19:16:37 -0400
Cc: sipping <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
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:hanserik.van.elburg@ericsson.com] 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:srivats@exchange.microsoft.com] 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:Miguel.Garcia@nsn.com] 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:hanserik.van.elburg@ericsson.com> > *To:* Jeroen van Bemmel <mailto:jbemmel@zonnet.nl> > *Cc:* sipping <mailto:sipping@ietf.org> > *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:jbemmel@zonnet.nl] > *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 > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP -- Miguel A. Garcia tel:+358-50-4804586 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Concrete examples for to draft-vanelbur… Jeroen van Bemmel
- [Sipping] RE: Concrete examples for to draft-vane… Hans Erik van Elburg (RY/ETM)
- [Sipping] Re: Concrete examples for to draft-vane… Jeroen van Bemmel
- [Sipping] RE: Concrete examples for to draft-vane… Hans Erik van Elburg (RY/ETM)
- Re: [Sipping] Re: Concrete examples for to draft-… Miguel Garcia
- RE: [Sipping] Re: Concrete examples forto draft-v… colin.pons
- Re: [Sipping] Re: Concrete examples forto draft-v… Miguel Garcia
- RE: [Sipping] Re: Concrete examples forto draft-v… colin.pons
- Re: [Sipping] Re: Concrete examples forto draft-v… Miguel Garcia
- RE: [Sipping] Re: Concrete examples forto draft-v… colin.pons
- RE: [Sipping] Re: Concrete examplesforto draft-va… Hans Erik van Elburg (RY/ETM)
- RE: [Sipping] Re: Concreteexamplesforto draft-van… DRAGE, Keith (Keith)
- RE: [Sipping] Re: Concrete examples for to draft-… Srivatsa Srinivasan
- RE: [Sipping] Re: Concrete examples fortodraft-va… Hans Erik van Elburg (RY/ETM)
- RE: [Sipping] Re: Concrete examples for todraft-v… Srivatsa Srinivasan