>Насчет байтов я согласен, мне меня бы устроил один аттрибут Acct-Session-Time.
>
>Дело в том, что биллинг обновляет информацию о текущей сессии на основании
>аттрибута Acct-Session-Time. У меня тоже в voice аккаунтинге нет Acct-Session-Time в update пакетах.
Биллинг поддерживает только один метод трекинга сессии? Можно, например,
для промежуточного подсчета продолжительности звонка, использовать vsa аттрибут h323-connect-time
и вычислять разницу между приходом update пакета по данной сессии и временем в атрибуте. Конечно,
при этом VGW и радиус сервера должный быть синхронизированы с общими ntp серверами.
>Бывают случаи, когда сессии зависают. В таком случае звонка
>по факту нет на железе, но сессия присутствует в биллинге. Если
>клиент позвонит в такой момент биллинг не даст ему установить соединение,
>поскольку с точки зрения биллинга он уже говорит (есть текущая сессия).
>
>
>Вот чтобы отличить зависшую сессию от долгой, нужна информация из аттрибута update
>пакета. Если его получить нет возможности, придется изменить биллинг.
Чтобы отличить зависшую сессию от продолжительной можно считать update пакеты по данной сессии.
Если не пришло N пакетов в течении заданного промежутка времени, то тогда считать сессию зависшей и
кильнуть ее либо через POD, либо через SNMP. POD, конечно, предпочтительней, т.к. не привязывается к оборудованию.
Именно так, в настоящее время, работает наш купленный биллинг.