[Serusers] Assure a BYE is received ??
Hoa Thai Duy
hoathai at vngt.vn
Fri Jun 30 10:07:46 CEST 2006
Ryan
If we use mediaproxy for relay the RTP, it always works fine with missing
BYE (timeout with no RTP activity mechanism).
However, the question here is: How to deal with missing BYE for closing the
billing record, without RTP going thru' RTP/Mediaproxy? I heard that there's
a clue using re-INVITE method (schduled re-INVITE, if we got OK from Uas,
the call is still alive).
Any other idea?
Brgds
Hoa
-----Original Message-----
From: serusers-bounces at lists.iptel.org
[mailto:serusers-bounces at lists.iptel.org] On Behalf Of Ryan Pagquil
Sent: Friday, June 30, 2006 8:49 AM
To: Adrian Georgescu
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] Assure a BYE is received ??
Hi Adrian,
I got it worked. I edited the accounting.py i removed the fields
from the sql query that my radacct don't have. And now it is working fine.
It closes the radacct entries that don't have been terminated by a BYE
message. I noticed that it always wait for a UA to send a BYE before sending
the accounting record, is it possible to make mediaproxy terminate a session
when there is no RTP traffic passing to through it? In this manner I could
avoid crashed UA to leave an active session.
BTW here is the code that I changed to fit my need:
*** means old
--- means new
xxx means removed
>>> means retained
UPDATE
%(table)s
SET
*** %(durationField)s = %(durationField)s +
IF(%(stopInfoField)s IS NULL, %%(callDuration)s, 0),
--- %(durationField)s = %(durationField)s + %%(callDuration)s,
>>> %(stopTimeField)s = DATE_ADD(%(startTimeField)s, INTERVAL
%(durationField)s SECOND),
xxx %(callerBytesField)s = %(callerBytesField)s + %%(callerBytes)s,
xxx %(calledBytesField)s = %(calledBytesField)s + %%(calledBytes)s,
xxx %(userAgentField)s = %%(userAgent)s,
xxx %(codecTypesField)s = %%(codecs)s,
xxx %(streamTypeField)s = %%(streamType)s,
xxx %(mediaInfoField)s = %%(mediaInfo)s,
xxx %(normalizedField)s = '0'
WHERE
%(sessionIdField)s = %%(id)s AND %(fromTagField)s =
%%(fromTag)s AND %(toTagField)s = %%(toTag)s
""" % DatabaseConfig.__dict__
Upon editing these codes, would there be any effect on the functionality of
mediaproxy?
Thanks,
Ryan
At 02:40 PM 6/29/2006, Adrian Georgescu wrote:
>Hi Ryan,
>
>The computation is based on the last moment RTP was received, if no RTP
>is received for a predefined timeout it will substract the timeout and
>update the duration accordingly. At this moment the sql query is
>hardcoded, which I know is not a very clever thing so a future version
>will have it more flexible.
>
>Adrian
>
>On Jun 29, 2006, at 8:35 AM, Ryan Pagquil wrote:
>
>>Hi Adrian,
>> I installed mediaproxy 1.7.2 and it is working fine. The
>>account is also enabled. But just a few question, can I edit the sql
>>query on accounting.py just to make it compatible with my existing
>>radacct table? How does it compute for the AcctSessionTime for every
>>session that it closes?
>>
>>Thanks,
>>Ryan
>>
>>
>>At 10:57 PM 6/28/2006, Adrian Georgescu wrote:
>>>I do now know your setup but you only need to add some extra columns
>>>to your radacct table. Except for the time required to apply the sql
>>>changes (your table will lock and you cannot write to it) I am not
>>>aware of any impact on a standard freeradius installation.
>>>
>>>Adrian
>>>
>>>
>>> >>>>
>>>
>>>Ok, it means that I'll just make the RTP pass through mediaproxy by
>>>enabling the use of it on non-NATed UA's. Just a question, I have an
>>>existing RADIUS accounting setup, would there be a problem if I
>>>implemented the accounting feature of mediaproxy? I'm afraid because
>>>written in the docs in the distro i need to patch the radacct table,
>>>will it affect the existing one or alter something?
>>>
>>>Thanks,
>>>Ryan
>>>
>>>_______________________________________________
>>>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