RE: [Sipping-tispan] Advice of Charge (AoC)
"Alf Heidermark \(AL/EAB\)" <alf.heidermark@ericsson.com> Tue, 31 January 2006 10:34 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 1F3spm-0000Nd-QG; Tue, 31 Jan 2006 05:34:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3spi-0000Mf-W6 for sipping-tispan@megatron.ietf.org; Tue, 31 Jan 2006 05:34:02 -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 FAA03147 for <sipping-tispan@ietf.org>; Tue, 31 Jan 2006 05:32:15 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3t0X-0005m2-8t for sipping-tispan@ietf.org; Tue, 31 Jan 2006 05:45:10 -0500
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6EBC6BA3; Tue, 31 Jan 2006 11:33:43 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 11:33:43 +0100
Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 11:33:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
Date: Tue, 31 Jan 2006 11:33:42 +0100
Message-ID: <4AFFBE68BCD2C04EB6EEA03FBC9CF4BE03030E9C@esealmw115.eemea.ericsson.se>
Thread-Topic: [Sipping-tispan] Advice of Charge (AoC)
Thread-Index: AcYmTbIHw2zlJVEmRayNeCNj/CgmIAABAcog
From: "Alf Heidermark (AL/EAB)" <alf.heidermark@ericsson.com>
To: "Martinez-Rebordosa, Anna" <Anna.Martinez-Rebordosa@t-com.net>, john.elwell@siemens.com, mhammer@cisco.com, sebastien.garcin@francetelecom.com, Miguel.An.Garcia@nokia.com
X-OriginalArrivalTime: 31 Jan 2006 10:33:43.0039 (UTC) FILETIME=[CECD10F0:01C62651]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285
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
Anna So there is no option to receive it after the call? Alf -----Original Message----- From: sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Martinez-Rebordosa, Anna Sent: den 31 januari 2006 10:25 To: john.elwell@siemens.com; mhammer@cisco.com; sebastien.garcin@francetelecom.com; Miguel.An.Garcia@nokia.com Cc: sipping-tispan@ietf.org Subject: AW: [Sipping-tispan] Advice of Charge (AoC) John, Aoc is defined on three types: - AOC-S: served user received the information at the time of establischment the session. - AOC-D: served user received the information during the session. Every t seconds. t is a network operator option. -AOC-E: served user received the information at the end of the session. I hope this clarifies a little bit more. Anna -----Ursprüngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens.com] Gesendet: Montag, 30. Januar 2006 22:29 An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel Garcia Cc: sipping-tispan@ietf.org Betreff: RE: [Sipping-tispan] Advice of Charge (AoC) Michael, It seems to me that HTTP/GET would be a good choice if a single immediate response can be expected. SUBSCRIBE/NOTIFY has some clear benefits if there is likely to be a delay before the information is available (so the subscriber will receive a 2xx response and await a NOTIFY request) or if the information might need to be updated during the subscription period (multiple NOTIFY requests). Can TISPAN people please clarify what is required? John > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: 30 January 2006 14:58 > To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia > Cc: sipping-tispan@ietf.org > Subject: RE: [Sipping-tispan] Advice of Charge (AoC) > > All, > > A comment from the peanut gallery. > > I am concerned that precedents from a single media type > service might unduly constrain a solution that uses multiple > media types simultaneously, some of which could be > session-oriented, some of which might be "connectionless". > All this talk of piggy-backing and use of 183 does not seem > to be generally useful in all situations. > > I would suggest that a solution that is general to all types > of services and attempts to be as decoupled as possible from > those services would minimize the possibility of feature > interactions between AoC and other features/services. > > That said, the essence of AoC is a request for information > that seems to be a natural fit for a Subscribe/Notify type of > operation for request and delivery. A particular dialog or > message will likely need to have an associated address from > which this information can be requested. One or more > values/addresses can be added to message/INVITE to enable a > UA to know where to send the Subscribe. The accounting > element will need to be able to identify the dialog or > message and bind that to the charge or charge rate, which > seems to be the nature of an Event package. > > I suspect that AoC will not be the last type of "Event" that > will be needed for SIP. Leveraging a general mechanism would > be better than reinventing event reporting for each of N > "features" that will arise. Talk of performance needs to > keep a broad perspective on the overall system. > > Mike > > > > -----Original Message----- > > From: sipping-tispan-bounces@ietf.org > > [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of GARCIN > > Sebastien RD-CORE-ISS > > Sent: Monday, January 30, 2006 8:56 AM > > To: Miguel Garcia > > Cc: sipping-tispan@ietf.org > > Subject: RE: [Sipping-tispan] Advice of Charge (AoC) > > > > Miguel, > > > > Please see answers below [SG] > > > > Regards, > > sebastien > > > > -----Message d'origine----- > > De : Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > Envoyé : lundi 30 janvier 2006 12:30 > > À : GARCIN Sebastien RD-CORE-ISS > > Cc : sipping-tispan@ietf.org > > Objet : 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. > > > > [SG: Why is 183 more artificial than MESSAGE / INFO / or > > anything else ? The 183 does not delay the session in my view > > since it relies on a separate early dialog (as documented > > currently in WI3030). > > > > 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. > > > > [SG: I agree. The idea is that 183 would be used for AoC-S > > (INVITE) in addition to INFO/BYE/200OK BYE in case of AoC-D > > and AoC-E. If you need to send AoC for a non-INVITE > > transaction (e.g. MESSAGE,PUBLISH...), you would use 200 OK > > response to those transactions MESSAGE/PUBLISH to convey the > > AoC information.] > > > > > > > > > > 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. > > > > [SG: I agree with Christer's answer here.] > > > > 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-requi > > >> rements-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 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 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