Re: [Sipping-tispan] Advice of Charge (AoC)
Miguel Garcia <Miguel.An.Garcia@nokia.com> Mon, 30 January 2006 12:22 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Y37-0005Nr-VP; Mon, 30 Jan 2006 07:22:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Y32-0005NR-H3 for sipping-tispan@megatron.ietf.org; Mon, 30 Jan 2006 07:22:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18328 for <sipping-tispan@ietf.org>; Mon, 30 Jan 2006 07:20:35 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3YDd-0001fg-D8 for sipping-tispan@ietf.org; Mon, 30 Jan 2006 07:33:18 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0UCH1rS013572; Mon, 30 Jan 2006 14:17:02 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 14:22:01 +0200
Received: from [127.0.0.1] ([172.21.35.110]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Jan 2006 14:22:01 +0200
Message-ID: <43DE04E8.90303@nokia.com>
Date: Mon, 30 Jan 2006 14:22:00 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: darshanb@huawei.com
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)
References: <001501c62596$020cc030$8a03120a@china.huawei.com>
In-Reply-To: <001501c62596$020cc030$8a03120a@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-OriginalArrivalTime: 30 Jan 2006 12:22:01.0417 (UTC) FILETIME=[C5B91B90:01C62597]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext03.nokia.com id k0UCH1rS013572
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org
So how are you going to create a post-paid application, which requires to send the information after the session is dismissed, with the in-dialog approach? Once the BYE is sent, there aren't more messages to receive, so this comes back to one my problems: you need to artificially twist here and there to get more session messages for something that is unrelated. I don't bye the argument of the performance either. /Miguel Darshan Bildikar wrote: > Would it not be better to use an "in-dialog" "piggybacking" approach as > suggested? > > Creating a side dialog and using an HTTP GET might create an unnecessary > performance over head. > > As an example, I'm thinking of an IP post paid application (for which AoC > would be really useful!) with a 1 million user database that needs to > support 200 BHCA. > > Getting the AoC information without any extra signaling would be helpful to > say the least! > > > > -----Original Message----- > From: sipping-tispan-bounces@ietf.org > [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Miguel Garcia > Sent: Monday, January 30, 2006 5:00 PM > To: GARCIN Sebastien RD-CORE-ISS > Cc: sipping-tispan@ietf.org > Subject: Re: [Sipping-tispan] Advice of Charge (AoC) > > Inline discussion. > > GARCIN Sebastien RD-CORE-ISS wrote: >> Miguel, >> >> First it may be true that there has been some discussion in the past about > this but I think it is still interesting to list the conclusions of those > discussions in order for readers (including me) to understand if there was > indeed a real problem with piggy-backing solution. Please note the solution > is not exaclty "piggy-backing" because in some flows (e.g. AoC-S service) > the AS generates the 183 answer and does not wait for a 183 answer from the > terminating side (see figure 1/ WI3030). >> Looking at your points: >> >> 1/ IMS Charging problem and creating artificial SIP message >> ------------------------------------------------------------ >> I am not sure to undertand the problem. The AS is perfectly entitled to > create and send 183 answers downstream, such message is needed anyway for > the service and this has nothing to do with "preconditions or sending > charging information". Could you please clarify ? > > So here we go... the AS need to create artificial 183 messages when > there might not be a need to send 183 at all. Think for example that you > call someone who happens to be an automata, such as an answering > machine, you will get 200 OK immediately. This does not require a 183, > but you need to create it artificially and delay the session just for > sending the AoC information. It would be more natural to create a > separate side-by dialog for sending the required information. > > Second: 183, as any other provisional responses, apply only to INVITE > transactions. So you would never be able to apply the AoC service than > any INVITE generated service, that is, video, voice, and MSRP sessions. > >> 2/ Breaking end-to-end signalling >> --------------------------------- >> The AS does not break anything, it simply adds service information to > messages. This behaviour is very common in the work we are doing in TISPAN. > > If the 183 has to split the dialog between the calling and the called > party, it is breaking the end-to-end signalling. While this situation > can't be avoided in some cases, in general it is desired to get away > from it. It breaks any possible end-to-end security, as a starting > point. If the service can be implemented while the AoC AS behaves as a > proxy, that would be an advantage for the implementation of the service > and the future compatibility of services. > > > BR, > > > > Miguel > >> Regards >> sebastien >> >> >> >> -----Message d'origine----- >> De : Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >> Envoyé : lundi 30 janvier 2006 09:55 >> À : GARCIN Sebastien RD-CORE-ISS >> Cc : sipping-tispan@ietf.org >> Objet : Re: [Sipping-tispan] Advice of Charge (AoC) >> >> GARCIN Sebastien RD-CORE-ISS wrote: >>> Hi Miguel >>> >>> First I have some problems with the service definition as expressed in > the draft-jesske-requirements-draft. The draft seems to indicated the AoC > service is always invoked by the served user. Although this might be a valid > case, this is not the only way to invoke the service since it can be a > permantent invocation. I suggest that you copy and past the service > definition as documented by TISPAN in WI3030 instead of the text at the > beginning of §3.4. >> >> True, there is a permanent service indication that does not require any > SIP signalling, thus, it does not have any protocol impact. In the > requirements we listed only those which we believe they may have protocol > impact. >>> In other words the requirement "to signal to a network that the service > is invoked" is optional. Additionnal I believe that it should be optional > for the UA to indicate whether it is capable of understanding an AoC > information sent by the network (note that this is different from "invoking" > the service). It is important that the capabilities required from terminal > is kept to a minimum so as to make the AoC service possible for a wide range > of terminals. >> I agree. >> >>> With regards to the delivery of the information, I don't agree the piggy > backing solution has been demonstrated as "bad", in my view it is the most > elegant way I have seen and has the advantage to require minimum capability > to terminals. >> Here I disagree. I am aware of two contexts where piggyback has been >> discussed: one is the IMS charging information, and you know what? When >> 3GPP wanted to remove the usage of preconditions, all the problems where >> around the fact that "hmmmm... if we remove preconditions, there >> aren't enough messages to transport charging information, so we can't >> remove preconditions". This is crap: creating artificial SIP messages >> just to transfer required information. >> >> The other context where this was discussed was in the Session-dependent >> policies. After some comparisons and analysis, the SIP WG decided to >> create a sideby channel for providing information of the policies (the >> slides were presented in an IETF meeting, perhaps in Seoul, don't quite >> remember exactly). >> >> Additionally, breaking the end-to-end signalling just to provide sideby >> information is, in general, a bad idea. It should be avoided. >> >> >>> Also I am surprised that you don't mention "MESSAGE" as solution since > you advocated this solution in TISPAN meeting ?? >> Yes, MESSAGE is also an alternative to transport the information. So we >> have the SUB/NOT, REFER, and MESSAGE. >> >>> Regards >>> sebastien >> BR; >> >> Miguel >> >> >>> >>> >>> >>> >>> >>> >>> >>> -----Message d'origine----- >>> De : sipping-tispan-bounces@ietf.org > [mailto:sipping-tispan-bounces@ietf.org] De la part de Miguel Garcia >>> Envoyé : lundi 30 janvier 2006 08:41 >>> À : 'sipping-tispan@ietf.org' >>> Objet : [Sipping-tispan] Advice of Charge (AoC) >>> >>> Hi all in the list. >>> >>> I would like to get opinions on solutions for implementing the Advice of > Charge service. >>> Requirements for this service are listed in the TISPAN requirements I-D, > Section 3.4: > http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-requirements > -02.txt >>> When we discussed this service in Vancouver, Jonathan suggested to take a > look at the SIP Interaction Framework to get ideas. They are very good ideas > in the SIP Interaction Framework, but still I would like to get opinions. >>> This service presents two problems to be solved: >>> >>> 1) How to signal to a network node that the service is invoked >>> >>> 2) How to transport the required information to the User Agent. >>> >>> >>> According to the interaction framework, invocation could be signal by a > combination of protocol elements, specifically: Allow REFER, Accept-Types > with some specific XML format, Contact with schemes: http, Contact with > GRUU, Supported with "tdialog", ... don't know what else. >>> While that is valid, I think it presents three problems. First, it is not > possible to distinguish between "this is what the UA supports" from "this is > the invocation to the service". Second. it makes the configuration of the > initial filter criteria (to trigger to the AoC Application server) a > nightmare, because instead of searching for one "item", we need to create > comparisons for four or five items. Third, this works as long as there is > some unique item to the service, which could be the type of body declared in > the Accept-Types, but as soon as we wanted to reuse this body for some other > service, we would run into trouble. >>> One proposal to invoke the service was to define a new specific header, > let's call it P-AoC, that contains some parameters that define the service > behavior. For example, it could contain some preference of the reporting > time or something like that. Another alternative could be to use a > subscription to an event package, in which case, we are determining not to > use a REFER to an HTTP URI for conveying the information. A third > possibility is to define a specific feature tag, but I think this isn't > really a feature, but a whole service. >>> On the delivery of information, we can think of a REFER to an HTTP URI or > a SUB/NOT type of notification. Some folks have been thinking of > piggy-backing the information to SIP requests or responses that "happens to > pass by", but this solution is bad, as it has been demonstrated with the > charging stuff in IMS, besides it does not meet the requirement of > delivering information "a few seconds after the communication has ended" >>> (REQ-AoC-1). So I guess the choices are just REFER + HTTP URI or SUB/NOT. >>> >>> I am willing to hear comments that can provide the needed guidance to > TISPAN. >>> Best regards, >>> >>> Miguel >>> > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping-tispan mailing list Sipping-tispan@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-tispan
- [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- RE: [Sipping-tispan] Advice of Charge (AoC) GARCIN Sebastien RD-CORE-ISS
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- RE: [Sipping-tispan] Advice of Charge (AoC) Bemmel, Jeroen van (Jeroen)
- RE: [Sipping-tispan] Advice of Charge (AoC) Darshan Bildikar
- RE: [Sipping-tispan] Advice of Charge (AoC) Avasarala Ranjit-A20990
- RE: [Sipping-tispan] Advice of Charge (AoC) GARCIN Sebastien RD-CORE-ISS
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- RE: [Sipping-tispan] Advice of Charge (AoC) Avasarala Ranjit-A20990
- RE: [Sipping-tispan] Advice of Charge (AoC) Darshan Bildikar
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia
- RE: [Sipping-tispan] Advice of Charge (AoC) Christer Holmberg (JO/LMF)
- RE: [Sipping-tispan] Advice of Charge (AoC) GARCIN Sebastien RD-CORE-ISS
- RE: [Sipping-tispan] Advice of Charge (AoC) Michael Hammer (mhammer)
- Re: [Sipping-tispan] Advice of Charge (AoC) Dean Willis
- RE: [Sipping-tispan] Advice of Charge (AoC) Elwell, John
- RE: [Sipping-tispan] Advice of Charge (AoC) Alf Heidermark (AL/EAB)
- RE: [Sipping-tispan] Advice of Charge (AoC) Nachum Frid
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Elwell, John
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Michael Hammer (mhammer)
- RE: [Sipping-tispan] Advice of Charge (AoC) Drage, Keith (Keith)
- RE: [Sipping-tispan] Advice of Charge (AoC) Michael Hammer (mhammer)
- RE: [Sipping-tispan] Advice of Charge (AoC) Hans Erik van Elburg (RY/ETM)
- RE: [Sipping-tispan] Advice of Charge (AoC) Avasarala Ranjit-A20990
- Re: [Sipping-tispan] Advice of Charge (AoC) Miguel Garcia