RE: [Sipping-tispan] Advice of Charge (AoC)
"Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com> Mon, 30 January 2006 09:09 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 1F3V24-0000IB-7Q; Mon, 30 Jan 2006 04:09:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3V22-0000Gg-9Y for sipping-tispan@megatron.ietf.org; Mon, 30 Jan 2006 04:09:06 -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 EAA07707 for <sipping-tispan@ietf.org>; Mon, 30 Jan 2006 04:07:27 -0500 (EST)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3VCg-0004uq-QJ for sipping-tispan@ietf.org; Mon, 30 Jan 2006 04:20:07 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k0U98hC1021629; Mon, 30 Jan 2006 03:08:45 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <DVB4FXTG>; Mon, 30 Jan 2006 10:08:35 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577E2EB@nl0006exch001u.nl.lucent.com>
From: "Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com>
To: 'Miguel Garcia' <Miguel.An.Garcia@nokia.com>, GARCIN Sebastien RD-CORE-ISS <sebastien.garcin@francetelecom.com>
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
Date: Mon, 30 Jan 2006 10:08:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
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
Miguel, It seems that the INFO method (RFC2976) could be used for this purpose too. I would argue that it matches better than MESSAGE (RFC3428), which is not intended for this kind of service Regards, Jeroen > -----Original Message----- > From: sipping-tispan-bounces@ietf.org > [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Miguel Garcia > Sent: Monday, January 30, 2006 9:55 AM > To: GARCIN Sebastien RD-CORE-ISS > Cc: sipping-tispan@ietf.org > Subject: 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-tispa > n-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 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