[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