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

[Darshan Bildikar <[e-mail]>]

Why not transfer the required AoC information as body in the SIP BYE message
when the session ends?



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bemmel, Jeroen van
(Jeroen)
Sent: Monday, January 30, 2006 2:39 PM
To: 'Miguel Garcia'; GARCIN Sebastien RD-CORE-ISS
Cc: [e-mail]
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: [e-mail]
> [mailto:[e-mail]]On Behalf Of Miguel Garcia
> Sent: Monday, January 30, 2006 9:55 AM
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: [e-mail]
> 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 : [e-mail] 
> [mailto:[e-mail]] De la part de Miguel Garcia
> > Envoyé : lundi 30 janvier 2006 08:41
> > À : '[e-mail]'
> > Objet : [Sipping-tispan] Advice of Charge (AoC)
> > 
> > Hi all in the list.
> > 
> > I would like to get opinions on solutions for implementing 
> the Advice of Charge service.
> > 
> > Requirements for this service are listed in the TISPAN 
> requirements I-D, Section 3.4:
> > 
> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispa
> n-requirements-02.txt
> > 
> > When we discussed this service in Vancouver, Jonathan 
> suggested to take a look at the SIP Interaction Framework to 
> get ideas. They are very good ideas in the SIP Interaction 
> Framework, but still I would like to get opinions.
> > 
> > This service presents two problems to be solved:
> > 
> > 1) How to signal to a network node that the service is invoked
> > 
> > 2) How to transport the required information to the User Agent.
> > 
> > 
> > According to the interaction framework, invocation could be 
> signal by a combination of protocol elements, specifically: 
> Allow REFER, Accept-Types with some specific XML format, 
> Contact with schemes: http, Contact with GRUU, Supported with 
> "tdialog", ... don't know what else.
> > 
> > While that is valid, I think it presents three problems. 
> First, it is not possible to distinguish between "this is 
> what the UA supports" from "this is the invocation to the 
> service". Second. it makes the configuration of the initial 
> filter criteria (to trigger to the AoC Application server) a 
> nightmare, because instead of searching for one "item", we 
> need to create comparisons for four or five items. Third, 
> this works as long as there is some unique item to the 
> service, which could be the type of body declared in the 
> Accept-Types, but as soon as we wanted to reuse this body for 
> some other service, we would run into trouble.
> > 
> > One proposal to invoke the service was to define a new 
> specific header, let's call it P-AoC, that contains some 
> parameters that define the service behavior. For example, it 
> could contain some preference of the reporting time or 
> something like that. Another alternative could be to use a 
> subscription to an event package, in which case, we are 
> determining not to use a REFER to an HTTP URI for conveying 
> the information. A third possibility is to define a specific 
> feature tag, but I think this isn't really a feature, but a 
> whole service.
> > 
> > On the delivery of information, we can think of a REFER to 
> an HTTP URI or a SUB/NOT type of notification. Some folks 
> have been thinking of piggy-backing the information to SIP 
> requests or responses that "happens to pass by", but this 
> solution is bad, as it has been demonstrated with the 
> charging stuff in IMS, besides it does not meet the 
> requirement of delivering information "a few seconds after 
> the communication has ended" 
> > (REQ-AoC-1). So I guess the choices are just REFER + HTTP 
> URI or SUB/NOT.
> > 
> > I am willing to hear comments that can provide the needed 
> guidance to TISPAN.
> > 
> > Best regards,
> > 
> >            Miguel
> > 
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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


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