[Serusers] session duration accounting

Java Rockx javarockx at gmail.com
Tue Jul 5 16:01:50 CEST 2005


No so. We only charge if the INVITE has a matching BYE, which means
that the other end when off hook or went to voice mail or was call
forwarded to another number.

In any event, a CANCEL would not be billable because of the 486 reply
that was accounted for.

Regards,
Paul

On 7/5/05, Olivier Taylor <olivier.taylor at gmail.com> wrote:
> Hi Paul,
> 
> Well, in this case, I must agree, in my case I am charged only from the
> ACKs, I use B2bua for accounting, but I have no diffrence between ACC
> standard table, Radacct(radius accounting) and my pstn provider, that's why
> I use ACKs and not Invites.
> 
> In your case, you will charge the caller even if the callee is away and even
> if the caller decides to cancel the call before the callee answers.
> 
> What's the meaning of life ;)
> 
> Regards,
> Olivier
> 
> -----Message d'origine-----
> De : Java Rockx [mailto:javarockx at gmail.com]
> Envoyé : mardi 5 juillet 2005 15:44
> À : Olivier Taylor
> Cc : Iqbal; Ryan Pagquil; serusers at lists.iptel.org
> Objet : Re: RE : [Serusers] session duration accounting
> 
> 
> I understand what you're saying, however, I disagree with your suggestion
> because me (as a PSTN gateway owner) will be charged tolls based on the
> INVITE-to-BYE duration from my carriers for completed calls.
> 
> So if I'm only billing durations from ACK to BYE, then :
> 
> 1) How would I accurately determine which ACK to account against considering
> that many ACKs can happen during any call? For instance, if you get put on
> hold or a re-INVITE.
> 
> 2) Why should I give the customer 30 seconds of free platform time when my
> carriers bill me toll charges for that period?
> 
> Regards,
> Paul
> 
> On 7/5/05, Olivier Taylor <olivier.taylor at gmail.com> wrote:
> > Hi Iqbal,
> > I think the query u gave is not really correct, the INVITES are the
> > beginning of the sessions, I think we must use the ACKs for a real
> > accounting of the call. Just think, if it takes 30 seconds to the
> > callee to hang on, u will overcharge him.
> > I just suggest to replace the INVITES by ACKs.
> >
> > Regards.
> >
> > Olivier
> >
> > -----Message d'origine-----
> > De : serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] De
> > la part de Iqbal Envoyé : mardi 5 juillet 2005 13:28
> > À : Ryan Pagquil
> > Cc : serusers at lists.iptel.org
> > Objet : Re: [Serusers] session duration accounting
> >
> >
> > put those queries in mysql and it should lookup your acc table
> >
> > Iqbal
> >
> > Ryan Pagquil wrote:
> >
> > > Hi,
> > >       So the only concept on how will I account for duration is to
> > > account for INVITE and BYE methods...BTW, where will I put those
> > > queries? Sorry, I'm in a stage of discovering SER.=)
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Java Rockx wrote:
> > >
> > >> Ryan,
> > >>
> > >> This MySQL query should do the trick. It joins the acc table to
> > >> itself. One side grabs INVITE messages and the other side grabs BYE
> > >> messages.
> > >>
> > >> NOTE: This will not work if you account for re-INVITE messages
> > >> because you will then have multple INVITEs for the same call.
> > >>
> > >> Regards,
> > >> Paul
> > >>
> > >> SELECT t1.from_uri as orig_number,  t1.to_uri as term_number,
> > >> TIMEDIFF(t2.time, t1.time) as duration,  t1.timestamp as calldate
> > >> FROM acc t1, acc t2  WHERE t1.sip_callid = t2.sip_callid AND
> > >> ((t1.fromtag = t2.fromtag and t1.totag = t2.totag) OR (t1.fromtag =
> > >> t2.totag and t1.totag = t2.fromtag)) AND t1.sip_method='INVITE' AND
> > >> t2.sip_method='BYE'
> > >>
> > >> On 7/4/05, Iqbal <iqbal at gigo.co.uk> wrote:
> > >>
> > >>
> > >>> its records the INVITE and BYE, so fro there you can work out the
> > >>> session duration
> > >>>
> > >>> Iqbal
> > >>>
> > >>> Ryan Pagquil wrote:
> > >>>
> > >>>
> > >>>
> > >>>> guys,
> > >>>>      just want to ask if i can make ser to account session
> > >>>> durations for billing purposes?
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> Serusers mailing list
> > >>> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> >
> 
>




More information about the sr-users mailing list