OK, this extension brings you one step closer, but I still think that
using acc for this purpose is still not a viable solution. Consider that you
would have to dump both CSeqs, Contacts, and full route set into the
table. It would be also necessary to update the information with every
SIP message within the dialog which means that every transaction within
that dialog would have to be accounted. This can be a lot of data,
especially if one of the sides is a PSTN gateway that uses session timer
to find out whether the remote end point is still alive.
Processing all the rows in acc table would be quite complex too (and
from my experience one could hardly avoid full table scans there).
So, in my opinion, it would be easier to hack a simple B2BUA on top of
dialog support in tm than using acc for this purpose. I hate telling
people that they really need a b2bua, but that's how it is, unfortunately.
Jan.
On 13-02 16:42, Marian Dumitru wrote:
Hi Jan,
You can use the acc extension developed by Voice System ( see
http://www.voice-system.ro/downloads/acc ). This will allow you to log
whatever header or AVP into your accounting backend.
Best regards,
Marian
Jan Janak wrote:
acc table does not contain enough information to
generate BYE -- CSeq is
missing. You would also need to update the information in the table with
every mid-dialog request (re-INVITE, for example).
Jan.
On 10-02 23:14, Hans Eriksson wrote:
>But isn't there enough info in the acc table to "fake" some BYEs to the
>end-points?
>
>I would send 2 pairs of BYEs. One pair would go to the gateway and ser
>faking that it came from the client. The other pair would go to the
>client and ser faking that it came from the gateway. This hack should
>be outside of ser, i.e. a billing system realize that there is no money
>left, checks the acc table for callids, tags etc, generates the BYEs
>and wait for call completion to show up in acc.
>
>Or maybe just make the gateway close the call with a BYE and then
>update the acc table. ser don't need to know as it is not
>dialogue-stateful. The client will eventually hang-up by himself.
>
>a hack, I know, But the alternative is a integrated real-time proxy and
>billing system and that costs $$$s.
>
>But a b2bua is also a hack...
>
>/hans
>
>
>2005-02-10 kl. 19.45 skrev Marian Dumitru:
>
>
>>Hi Tom,
>>
>>SER is transaction statefull, not dialog/call statefull; it has not
>>the ability to terminate a call in progress. For this you need a b2bua
>>(like vovida)
>>
>>Best regards,
>>Marian
>>
>>Tom Gaudasinski wrote:
>>
>>>Greetings,
>>> Another question from me. I need to be able to liberally
>>>disconnect a call that's in progress at any time. Is there any way to
>>>do this. I want to implement a pseudo prepaid billing, and I need
>>>something that will allow for call termination once credits have been
>>>used up. Is there any way i can send SER a message or anything else?
>>>Or maybe set a timer for maximum call duration so that the call will
>>>be killed after it passes?
>>>Thank you.
>>>_______________________________________________
>>>Serusers mailing list
>>>serusers(a)lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
>>
>>--
>>Voice System
>>http://www.voice-system.ro
>>
>>_______________________________________________
>>Serusers mailing list
>>serusers(a)lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Voice System
http://www.voice-system.ro