Subject: [Sipping-tispan] Advice of Charge (AoC)

From: Miguel Garcia <[email-masked]>
Date: Mon, 30 Jan 2006 09:41:08 +0200

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:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 30 Jan 2006 11:09:03 +0100

We have different service capabilities when the AoC information will be sent.

1. before the call starts 
2. during the call 
3. with the end of the call 

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Darshan Bildikar [mailto:[email-masked]] 
> Gesendet: Montag, 30. Januar 2006 10:21
> An: 'Bemmel, Jeroen van (Jeroen)'; 'Miguel Garcia'; 'GARCIN 
> Sebastien RD-CORE-ISS'
> Cc: [email-masked]
> Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> 
> Why not transfer the required AoC information as body in the 
> SIP BYE message
> when the session ends?
> 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bemmel, 
> Jeroen van
> (Jeroen)
> Sent: Monday, January 30, 2006 2:39 PM
> To: 'Miguel Garcia'; GARCIN Sebastien RD-CORE-ISS
> Cc: [email-masked]
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> 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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Miguel Garcia
> > Sent: Monday, January 30, 2006 9:55 AM
> > To: GARCIN Sebastien RD-CORE-ISS
> > Cc: [email-masked]
> > 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 : [email-masked] 
> > [mailto:[email-masked]] De la part de Miguel Garcia
> > > Envoyé : lundi 30 janvier 2006 08:41
> > > À : [email-masked]'
> > > 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:
> > > 
> > > 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.
> > > 
> > > 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" 
> > > I am willing to hear comments that can provide the needed 
> > guidance to TISPAN.
> > > 
> > > Best regards,
> > > 
> > >            Miguel
> > > 
> > 
> > --

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 30 Jan 2006 19:31:04 +0800

Hi Miguel

By XCAP I mean using HTTP. Yes we could use HTTP GET operation to get the AoC document. 

Regards
Ranjit

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, January 30, 2006 4:53 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; Bemmel, Jeroen van (Jeroen); GARCIN Sebastien RD-CORE-ISS; [email-masked]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

I agree we would need an XML document that conveys the information that, eventually, it is interpreted and displayed to the user.

The other thing: are you suggesting to use XCAP for convey the AoC XML document? I think XCAP is nice for doing XML document manipulation, but not for displaying information. Specifically, we would need to do GET operations of the full XML document, in which case, I don't think we need XCAP at all, but just a pure HTTP GET.

/Miguel

Avasarala Ranjit-A20990 wrote:
> Hi
> 
> I feel there needs a format for AoC message, like an XML package. Then this info can be sent either in NOTIFY if the served user subscribes to the AoC service or Aoc XML doc can be sent using XCAP instead of putting it any SIP message. 
> 
> 
> Regards
> Ranjit
> 
> [mailto:[email-masked]] On Behalf Of Darshan Bildikar
> Sent: Monday, January 30, 2006 2:51 PM
> To: 'Bemmel, Jeroen van (Jeroen)'; 'Miguel Garcia'; 'GARCIN Sebastien RD-CORE-ISS'
> Why not transfer the required AoC information as body in the SIP BYE message when the session ends?
> 
> 
> 
> [mailto:[email-masked]] On Behalf Of Bemmel, Jeroen 
> van
> (Jeroen)
> 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
> 
>> 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.
>>
>> 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.
>>
>> 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
>> aren't enough messages to transport charging information, so we can't 
>> remove preconditions". This is crap: creating artificial SIP messages 
>> 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.
>>
>>
>> Yes, MESSAGE is also an alternative to transport the information. So 
>> we have the SUB/NOT, REFER, and MESSAGE.
>>
>>> Regards
>>> sebastien
>> BR;
>>
>>      Miguel
>>
>>
>>>  
>>>
>>>
>>>
>>>
>>>  
>>>
>>> Envoyé : lundi 30 janvier 2006 08:41 À : [email-masked]'
>> 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.
>> Allow REFER, Accept-Types with some specific XML format, Contact with 
>> schemes: http, Contact with GRUU, Supported with "tdialog", ... don't 
>> know what else.
>> 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 
>> Accept-Types, but as soon as we wanted to reuse this body for some 
>> other service, we would run into trouble.
>> 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.
>> 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"

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Jan 2006 13:24:26 +0100

Hi,

A few issues:

1.

I haven't really been involved in this discussion so much, so maybe this is a stupid question, but what does end-to-end security has to do with this? This is not end-to-end signalling, and I don't think it prevents you from sending secure data end-to-end, does it?

IF you mean (which I think you do) that no intermediate node (not even a B2BUA) is allowed to touch (add/modify/remove) anything in a SIP message I don't think AoC is the only problem. You already have SDP modification (e.g. due to controlled NATs), header modification in the AS, header/body screening etc etc etc... I KNOW what some people think of that, but the point is that I don't think that AoC is going to change the fact whether such behavior exist in the network or not...

2.

A couple of other questions, related to the usage of MESSAGE (again, I am sorry if it's been discussed):

1. How do you associate the MESSAGE with the dialog you are providing information about? Do you use some specific header?

2. How do you make sure the MESSAGE will reach the same physical entity(ies) that are involved in the dialog it is providing information about?

3.

If 183 is used (assuming it could be used from a use-case perspective), I presented a solution once, where you would use "simulated forking", i.e. the AS would generate a 18x with a separate To tag than the one used by the remote terminal. So, no piggy-backing, no break of end-to-end security, and no delaying of the session setup...

4.

Assume you get a call from PSTN, and send an INVITE. A while after you get AoC information from PSTN, and send a MESSAGE. Now, is it now sure that the MESSAGE, sent outside of the INVITE dialog, will reach the same AS as the INVITE. Is the trigger criteria the same? 

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: 30. tammikuuta 2006 13:30
To: GARCIN Sebastien RD-CORE-ISS
Cc: [email-masked]
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

> De : Miguel Garcia [mailto:[email-masked]]
> Envoyé : lundi 30 janvier 2006 09:55
> À : GARCIN Sebastien RD-CORE-ISS
> Cc : [email-masked]
> Objet : Re: [Sipping-tispan] Advice of Charge (AoC)
> 
>> 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.
> 
> When 3GPP wanted to remove the usage of preconditions, all the problems where
> 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).
> 
>> Also I am surprised that you don't mention "MESSAGE" as solution since you advocated this solution in TISPAN meeting ??
>>
> 
>> 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:
>> 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.
>>
>> 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" 
>> I am willing to hear comments that can provide the needed guidance to TISPAN.
>>
>> Best regards,
>>
>>            Miguel
>>
>

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Mon, 30 Jan 2006 14:55:55 +0100

Miguel,

Please see answers below [SG]

Regards,
sebastien 

-----Message d'origine-----
De : Miguel Garcia [mailto:[email-masked]] 
Envoyé : lundi 30 janvier 2006 12:30
À : GARCIN Sebastien RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [Sipping-tispan] Advice of Charge (AoC)

Inline discussion.

[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). 

[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

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 30 Jan 2006 09:57:50 -0500

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

> [mailto:[email-masked]] On Behalf Of GARCIN 
> Sebastien RD-CORE-ISS
> Sent: Monday, January 30, 2006 8:56 AM
> To: Miguel Garcia
> > 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: 
> >  
> > 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.]
> 
> 
> > 
> > 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
> > 
> > 
> > 
> 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.
> > 
> information. So 
> >> 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.
> >>

---

From: "Martinez-Rebordosa, Anna" <[email-masked]>
Date: Mon, 30 Jan 2006 16:32:21 +0100

Hi all,

I see we have some different ideas and views on which could be the best method to solve the transporting mechanism for the charging information to the served user. I hope all this discussion can clarify some questions. I will try to add this discussion to my contribution, which tries to summarieses all the discussion had since TISPAN#5 about this issue. May be for the people who was not involved in all the discussion the contribution will help to understand a little bit more all the problems we identify. 

I get now for the discussion on the  sipping-tispan group that there is no clear posision. There are 4 alternatives, namely: SUBSCRIBE/NOTIFY, MESSAGE, piggy-backing methods with INFO, and REFER/HTTP, as possible solution fro providing the served user with the AOC information.  

I would encourage the people involved to bring contributions for the next week meeting to get a good discussion and a desicion at the end of TISPAN#10. 

See you next week!
Best Regards,
Anna Martinez Rebordosa

Deutsche Telekom AG
T-Com Zentrale, Technik, Technik Einführung (TE)
T332-7Signaling Gateways and Switching Systems
Hausadresse: Deutsche-Telekom-Alle 1, 64307 Darmstadt, Germany 
Tel.:  +49 6151/83-3549
Fax.: +49 6151/83-4577
e-mail: [email-masked] 

-----Ursprüngliche Nachricht-----
Von: Christer Holmberg (JO/LMF) [mailto:[email-masked]] 
Gesendet: Montag, 30. Januar 2006 13:24
An: Miguel Garcia; GARCIN Sebastien RD-CORE-ISS
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Hi,

A few issues:

1.

2.

3.

4.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: 30. tammikuuta 2006 13:30
To: GARCIN Sebastien RD-CORE-ISS
Cc: [email-masked]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

Inline discussion.

BR,

     Miguel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Jan 2006 21:28:58 +0000

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

> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: 30 January 2006 14:58
> To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
> 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
> 
>

---

From: "Martinez-Rebordosa, Anna" <[email-masked]>
Date: Tue, 31 Jan 2006 10:24:31 +0100

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:[email-masked]] 
Gesendet: Montag, 30. Januar 2006 22:29
An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Michael,

John

---

From: "Alf Heidermark \(AL/EAB\)" <[email-masked]>
Date: Tue, 31 Jan 2006 11:33:42 +0100

Anna 

So there is no option to receive it after the call?

Alf 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martinez-Rebordosa, Anna
Sent: den 31 januari 2006 10:25
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: [Sipping-tispan] Advice of Charge (AoC)

John,

Anna 

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]]
Gesendet: Montag, 30. Januar 2006 22:29
An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Michael,

John

---

From: "Nachum Frid" <[email-masked]>
Date: Tue, 31 Jan 2006 13:32:05 +0200

As far as we know in ISDN, the AOC-E is send as Facility IE in Q.931 DISCONNECT  or in Q.931 RELEASE messages. It is possible to wait for these messages and include the AOC-E data in new AOC header, either in sip BYE message or in 200OK response to BYE. 

Nachum

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alf Heidermark (AL/EAB)
Sent: Tuesday, January 31, 2006 12:34 PM
To: Martinez-Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)

Anna 

Alf 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martinez-Rebordosa, Anna
Sent: den 31 januari 2006 10:25
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: [Sipping-tispan] Advice of Charge (AoC)

John,

Anna 

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]]
Gesendet: Montag, 30. Januar 2006 22:29
An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Michael,

John

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 31 Jan 2006 12:36:16 +0100

This is not required so the solution does not need to solve that problem.

We are talking about delivering the information beginning, during and at the end of the call.

/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: Monday, January 30, 2006 1:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

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!
> 
> 
> 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: Monday, January 30, 2006 5:00 PM
>> 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: 
>>  
>> 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 
> 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.
> 
>> 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
>>
>>
>>
>>> 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.
>>
>> any
>>> 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.
>>> Also I am surprised that you don't mention "MESSAGE" as solution 
>>> since
> you advocated this solution in TISPAN meeting ??
> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-requir
> ements
> -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.
> 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 
> we wanted to reuse this body for some other service, we would run into trouble.
>>> 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"

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 31 Jan 2006 12:38:10 +0100

inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darshan Bildikar
Sent: Monday, January 30, 2006 1:09 PM
To: 'Miguel Garcia'; 'GARCIN Sebastien RD-CORE-ISS'
Cc: [email-masked]
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)

Would it not be better to use an "in-dialog" "piggybacking" approach as suggested?
HansErik> Agree

Creating a side dialog and using an HTTP GET might create an unnecessary performance over head. 
HansErik> Agree

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. 
HansErik> Im not sure that this is what we are after.

Getting the AoC information without any extra signaling would be helpful to say the least!
HansErik> Agree

-----Original Message-----

Inline discussion.

> First it may be true that there has been some discussion in the past 
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).
> 1/ IMS Charging problem and creating artificial SIP message
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 ?

BR,

     Miguel

>> First I have some problems with the service definition as expressed 
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 
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 
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.
>> With regards to the delivery of the information, I don't agree the 
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.
Charge service.
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 
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.
>> According to the interaction framework, invocation could be signal by 
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.
>> 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 
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 
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" 
TISPAN.

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 31 Jan 2006 12:40:06 +0100

Inline... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: Monday, January 30, 2006 12:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

There is a requirement that the AoC information can be delivered even a few seconds after the session has ended. You tell me how to send a BYE when a BYE has been already sent to dismiss the session.
HansErik> This is not required. Your confuisning with activation of MCID.

Second: don't be constrain to INVITE requests, this should be a general mechanism that is applicable not only to INVITE-initiated sessions. For instance, it could be used for PUBLISH requests, SUB/NOTIFY or MESSAGE services.
HansErik> A new P-header would not constrain to INVITE requests.

BR,

       Miguel

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 31 Jan 2006 12:46:33 +0100

Support statements from Sebastien fully. 
/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GARCIN Sebastien RD-CORE-ISS
Sent: Monday, January 30, 2006 11:27 AM
To: Miguel Garcia
Cc: [email-masked]
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)

Miguel,

Looking at your points: 

Regards
sebastien

-----Message d'origine-----
De : Miguel Garcia [mailto:[email-masked]]
Envoyé : lundi 30 janvier 2006 09:55
À : GARCIN Sebastien RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [Sipping-tispan] Advice of Charge (AoC)

I agree.

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.

BR;

     Miguel

> De : [email-masked] [mailto:[email-masked]] De la part de Miguel Garcia

---

From: "Martinez-Rebordosa, Anna" <[email-masked]>
Date: Tue, 31 Jan 2006 13:32:00 +0100

Alf,

No, at the end of the call, the charging information should be send within the "dialog". The BYE or the answer 200OK of the BYE may indicate to the AS to send the charging information to the served user. In the descripiton of the AOC-D by PSTN/ISDN, the AoC information ist send to the served user once the REL is received.

Anna

-----Ursprüngliche Nachricht-----
Von: Alf Heidermark (AL/EAB) [mailto:[email-masked]] 
Gesendet: Dienstag, 31. Januar 2006 11:34
An: Martinez Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Anna 

Alf 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martinez-Rebordosa, Anna
Sent: den 31 januari 2006 10:25
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: [Sipping-tispan] Advice of Charge (AoC)

John,

Anna 

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]]
Gesendet: Montag, 30. Januar 2006 22:29
An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Michael,

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 31 Jan 2006 12:54:46 +0000

Anna,

Thanks, so the middle option (AOC-D) would tend to steer us in the direction
of SUBSCRIBE/NOTIFY rather than HTTP GET, because there can be multiple
notifications.

These three types of AOC are all session-related, yet there was some recent
discussion about AOC applied to other SIP messaging, not just
session-related. Can we assume that AOC is indeed limited to session-related
charges?

Some postings to this list have been discussing sending the charge
information in the context of the INVITE-initiated dialog for the session.
An intermediary would insert the charge information, and this then gives
rise to questions about security. What are the authentication requirements
for the charge information? Depending on requirements, insertion of this
information by a proxy may be problematic. A proxy can't insert a body. It
can insert a header, of course, but that header would not be covered by the
integrity protection that the Identity header provides. SUBSCRIBE/NOTIFY can
draw upon standard security measures much more easily than in-dialog
information.

John

> From: Martinez-Rebordosa, Anna 
> [mailto:[email-masked]] 
> Sent: 31 January 2006 09:25
> To: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]
> - AOC-D: served user received the information during the 
> session. Every t seconds. t is a network operator option.

---

From: "Hans Erik van Elburg \(RY/ETM\)" <[email-masked]>
Date: Tue, 31 Jan 2006 14:46:04 +0100

AOC information header is inserted by an AS in the trust domain. Further it does not reveal any identity information, only tariff informatrion that is applicable for the receiving user. It is the AS of the served user that inserts this information for the served users UE or access gateway to render to the user and for bookkeeping purposes.

False information received from untrusted networks should either be removed or rejected at the border of the trust domain.

This is the same kind of trust relations that are used to know that for example P-Asserted-Identity is authenticated by the network and by nobody else.

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, January 31, 2006 1:55 PM
To: Martinez-Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)

Anna,

Thanks, so the middle option (AOC-D) would tend to steer us in the direction of SUBSCRIBE/NOTIFY rather than HTTP GET, because there can be multiple notifications.

These three types of AOC are all session-related, yet there was some recent discussion about AOC applied to other SIP messaging, not just session-related. Can we assume that AOC is indeed limited to session-related charges?

Some postings to this list have been discussing sending the charge information in the context of the INVITE-initiated dialog for the session.
An intermediary would insert the charge information, and this then gives rise to questions about security. What are the authentication requirements for the charge information? Depending on requirements, insertion of this information by a proxy may be problematic. A proxy can't insert a body. It can insert a header, of course, but that header would not be covered by the integrity protection that the Identity header provides. SUBSCRIBE/NOTIFY can draw upon standard security measures much more easily than in-dialog information.

John

> - AOC-D: served user received the information during the session. 
> Every t seconds. t is a network operator option.
> 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
> > 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
> > 
> > 
> > > Envoyé : lundi 30 janvier 2006 12:30 À : GARCIN Sebastien 
> > > RD-CORE-ISS Cc : [email-masked] Objet : Re: 
> > > [Sipping-tispan] Advice of Charge (AoC)
> > > 
> > > Inline discussion.
> > > 
> > > 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: 
> > > >  
> > > 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".
> > > So here we go... the AS need to create artificial 183 messages 
> > > when there might not be a need to send 183 at all.
> > > 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.
> > > 
> > > (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.]
> > > 
> > > 
> > > > 
> > > > --------------------------------- 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 
> > > > Envoyé : lundi 30 janvier 2006 09:55 À : GARCIN Sebastien 
> > > > RD-CORE-ISS Cc : [email-masked] Objet : Re: 
> > > > [Sipping-tispan] Advice of Charge (AoC)
> > > > 
> > > expressed in the draft-jesske-requirements-draft. The draft seems 
> > > to indicated the AoC service is always invoked by the served user. 
> > > 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.
> > > > 
> > > > 
> > > 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.
> > > > 
> > > 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.
> > > > 
> > > 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.
> > > > 
> > > ideas. They are very good ideas in the SIP Interaction Framework, 
> > > but still I would like to get opinions.
> > > >>
> > > 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.
> > > >>
> > > 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.
> > > >>
> > > 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.
> > > >>
> > > 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"

---

From: "Martinez-Rebordosa, Anna" <[email-masked]>
Date: Tue, 31 Jan 2006 14:58:20 +0100

John,

Totally agree with Hans Erik about the trusted AOC information. 

Your other question about session-related charging information. Yes, I pressume that the charging information to be provided to the served user applies only to the session been stablished. The invocation of AoC service is also done at the session stablishment. 

For better understanding on AoC here some definitions from the ETS 300 182-1:

Three AOC supplementary services exist:
a)	Charging information at call set-up time (AOC-S)

	When the AOC-S supplementary service is activated, the network shall provide the user with information about the charging rates at call establishment. In addition, the network shall inform the served user if a change in charging rates takes place during the call.
The network shall provide the charging information during call establishment or at the latest at call connection. When there is a change in the charging rate during the call, the network shall send information about the new charging rate to the served user

b)	Charging information during the call (AOC-D)
When the AOC-D supplementary service is activated, the network shall provide the user with charging information for a call during the active phase of a call. The network shall provide the charging information and transfer it to the served user in an appropriate message. The supplied charging information shall be provided as a cumulative charge incurred so far for the call (i.e. charges recorded from the start of the call and until the moment the charging information is sent to the served user).
When the call is released, the network shall send the recorded charges for the call to the served user in one of the call control messages clearing the call.
If the network has determined that the call is free of charge, then the network shall send a free-of-charge indication in the first subsequent message sent to the served user. The network shall not send any further charging information during the call. When the call is released, the network shall send the charged amount (zero) in a call control message clearing the call.

c)	Charging information at the end of the call (AOC-E)

	When the AOC-E supplementary service is activated, the network shall provide the served user with charging information indicating the recorded charges for a call when the call is released. The network shall send the charging information to the served user in one of the call control messages clearing the call.

I hope that can clarify some questions.
BR,
Anna

-----Ursprüngliche Nachricht-----
Von: Hans Erik van Elburg (RY/ETM) [mailto:[email-masked]] 
Gesendet: Dienstag, 31. Januar 2006 14:46
An: Elwell, John; Martinez Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, January 31, 2006 1:55 PM
To: Martinez-Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)

Anna,

John

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 31 Jan 2006 10:13:02 -0500

Hmmm...  The core idea here is that the user needs to be informed. 

I think this statement from b. below got it absolutely right:  "The network shall provide the charging information and transfer it to the served user in an appropriate message."

But, can someone justify the additional statements:  (in b.) "the network shall send the charged amount (zero) in a call control message clearing the call." (in c.) "The network shall send the charging information to the served user in one of the call control messages clearing the call."  Why???

This seems to unnecessarily constrain the solution.  Could someone explain to me why this solution embedded in requirement is justified?  Or, can we upgrade this with the knowledge that other methods of solution are possible?

Mike

> Sent: Tuesday, January 31, 2006 8:58 AM
> To: [email-masked]; 
> [email-masked]; Michael Hammer (mhammer); 
> Your other question about session-related charging 
> information. Yes, I pressume that the charging information to 
> be provided to the served user applies only to the session 
> been stablished. The invocation of AoC service is also done 
> at the session stablishment. 
> 
> 	When the AOC-S supplementary service is activated, the 
> network shall provide the user with information about the 
> charging rates at call establishment. In addition, the 
> network shall inform the served user if a change in charging 
> rates takes place during the call.
> The network shall provide the charging information during 
> call establishment or at the latest at call connection. When 
> there is a change in the charging rate during the call, the 
> network shall send information about the new charging rate to 
> the served user
> 
> When the AOC-D supplementary service is activated, the 
> network shall provide the user with charging information for 
> a call during the active phase of a call. The network shall 
> provide the charging information and transfer it to the 
> served user in an appropriate message. The supplied charging 
> information shall be provided as a cumulative charge incurred 
> so far for the call (i.e. charges recorded from the start of 
> the call and until the moment the charging information is 
> sent to the served user).
> When the call is released, the network shall send the 
> recorded charges for the call to the served user in one of 
> the call control messages clearing the call.
> If the network has determined that the call is free of 
> charge, then the network shall send a free-of-charge 
> indication in the first subsequent message sent to the served 
> user. The network shall not send any further charging 
> information during the call. When the call is released, the 
> network shall send the charged amount (zero) in a call 
> control message clearing the call.
> 
> 	When the AOC-E supplementary service is activated, the 
> network shall provide the served user with charging 
> information indicating the recorded charges for a call when 
> the call is released. The network shall send the charging 
> information to the served user in one of the call control 
> messages clearing the call.
> 
> 
> 
> Von: Hans Erik van Elburg (RY/ETM) 
> [mailto:[email-masked]]
> An: Elwell, John; Martinez Rebordosa, Anna; 
> [email-masked]; [email-masked]; 
> [email-masked]
> AOC information header is inserted by an AS in the trust 
> domain. Further it does not reveal any identity information, 
> only tariff informatrion that is applicable for the receiving 
> user. It is the AS of the served user that inserts this 
> information for the served users UE or access gateway to 
> render to the user and for bookkeeping purposes.
> 
> False information received from untrusted networks should 
> either be removed or rejected at the border of the trust domain.
> 
> This is the same kind of trust relations that are used to 
> know that for example P-Asserted-Identity is authenticated by 
> the network and by nobody else.
> 
> /Hans Erik
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> To: Martinez-Rebordosa, Anna; [email-masked]; 
> Thanks, so the middle option (AOC-D) would tend to steer us 
> in the direction of SUBSCRIBE/NOTIFY rather than HTTP GET, 
> because there can be multiple notifications.
> 
> These three types of AOC are all session-related, yet there 
> was some recent discussion about AOC applied to other SIP 
> messaging, not just session-related. Can we assume that AOC 
> is indeed limited to session-related charges?
> 
> Some postings to this list have been discussing sending the 
> charge information in the context of the INVITE-initiated 
> dialog for the session.
> An intermediary would insert the charge information, and this 
> then gives rise to questions about security. What are the 
> authentication requirements for the charge information? 
> Depending on requirements, insertion of this information by a 
> proxy may be problematic. A proxy can't insert a body. It can 
> insert a header, of course, but that header would not be 
> covered by the integrity protection that the Identity header 
> provides. SUBSCRIBE/NOTIFY can draw upon standard security 
> measures much more easily than in-dialog information.
> 
> John
> 
> general it

---

From: "Martinez-Rebordosa, Anna" <[email-masked]>
Date: Tue, 31 Jan 2006 16:21:00 +0100

Hi Mike,

Thanks, Mike. Yes, sorry, that was my mistake to include this text here. This text is valid, only in the case of being in a PSTN/ISDN domain, which is not under our discussion issue. I just make a copy/paste requirements on the three types of Aoc from the PSTN/ISDN to clarify them. 

You are right, we should concentrate on the first statement of "The network shall provide the charging information and transfer it to the served user in an appropriate message.". The statements about the message clearing on the requirements below should be ingored for our purpose.

Anna

-----Ursprüngliche Nachricht-----
Von: Michael Hammer (mhammer) [mailto:[email-masked]] 
Gesendet: Dienstag, 31. Januar 2006 16:13
An: Martinez Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Mike

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 31 Jan 2006 17:27:36 +0100

Hello altogether

My understanding is following:

This constrains come from the interworking requirements with the AoC service in the ISDN. What this are trying to say is that the solution shall guarantee the synchronisation with the call-control procedures in order to interwork with the ISDN service.

I do not think that this shall prevent a non call-control bounded solution as long as the synchronisation is guaranteed.

Greetings,
Denis Alexeitsev
Deutsche Telekom AG
T-Com Zentrale, TE332-5
Services and Network Convergence
NGN Protocols
Deutsche-Telekom-Alle 1, 64307,
Darmstadt, Germany 
Tel:  +49 6151 83-2130
Fax: +49 6151 83-4577
mailto:[email-masked]

-----Ursprüngliche Nachricht-----
Von: Michael Hammer (mhammer) [mailto:[email-masked]] 
Gesendet: Dienstag, 31. Januar 2006 16:13
An: Martinez Rebordosa, Anna; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)

Mike