13 Feb
2008
13 Feb
'08
12:53 p.m.
Hi Dan/List,
I was reading the post below and trying to understand how your config
works. If
you are implementing this with something like a Cisco PSTN then you need all
of
these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does
the RTP
stream have to route via Yate and mediaproxy? :S
thanks for any help! cheers Andy.
Hey Marc,
I use Yate for doing that. It is simple and works out of the box (with
adding few
lines in configs of course).
I take Session timeout returned from connector and pass it to yate in a sip
header
Process that header in regex routing and define the
value as timeout for
session.
Yate knows by default that when a session has a
parameter "timeout"
returned
from routing to disconnect the call when timeout is
hit.
Let me know if you need further info, so I can send you some config files
if you
want to. You can contact me on IRC for live support
(DanB).
All the best,
DanB
________________________________________________
Message sent using UK Grid Webmail 2.7.9
13 Feb
13 Feb
1:07 p.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
Hi Andy,
The original config was built with Yate in mind due to openser incapacity
(before release 1.3) of disconnecting the calls. Since 1.3.0 the dialog
module should be able to timeout the calls, in theory you should no longer
need extra software like Yate.
I would still recommend using Yate combined with OpenSER in the case you are
doing some sort of "Carrier business", for the following reasons:
1. It creates two different legs for your call (in and out) same as Cisco
does, and hides one side from the other (eg. removes the via headers and any
revealing ip information inside SDP - so your partners should not know where
the traffic comes from).
2. You have more protocols available in.
3. Accounting it is bit more accurate (you have the session total duration
inside the accounting packets), so radius will be no longer responsible of
calculating the session durations from timestaps.
4. Yate can work in rtp_forward mode, therefore no extra overhead given by
rtp processing.
So basically what the connector does (as specified in the documentation),
for each call which is authorized by radius, the connector will ask
permission from cdrtool. If permission is granted, it will return in a avp
to openser the maximum duration allowed for the call (timeout value) plus
credit available, for the case of special uas able to display that.
By receiving accounting stop packet, the connector will inform cdrtool about
call disconnection therefore clearing the lock and debiting the balance
inside cdrtool. The rtp stream has nothing to do with this scenario, so you
don't need to touch your NAT support configuration, it's all in the
signaling.
Let me know if you need further info.
Cheers,
DanB
On Feb 13, 2008 12:53 PM, A.smith <a.smith(a)ukgrid.net> wrote:
Hi Dan/List,
I was reading the post below and trying to understand how your config
works. If
you are implementing this with something like a Cisco PSTN then you need
all
of
these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does
the RTP
stream have to route via Yate and mediaproxy? :S
thanks for any help! cheers Andy.
Hey Marc,
I use Yate for doing that. It is simple and works out of the box (with
adding few
lines in configs of course).
I take Session timeout returned from connector and pass it to yate in a
sip
header
Process that header in regex routing and define
the value as timeout for
session.
Yate knows by default that when a session has a
parameter "timeout"
returned
from routing to disconnect the call when timeout
is hit.
Let me know if you need further info, so I can send you some config files
if you
want to. You can contact me on IRC for live
support (DanB).
All the best,
DanB
________________________________________________
Message sent using UK Grid Webmail 2.7.9
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6:06 p.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
Hi Dan,
one other query on the below, regarding Yate providing more accuarate accounting, if
OpenSER is used with mediaproxy will this not provide the same level of accuracy (as
Mediaproxy actually sits in the RTP stream)?
thanks Andy.
----- Original Message -----
From: Dan-Cristian Bogos
To: A.smith
Cc: users(a)lists.openser.org
Sent: Wednesday, February 13, 2008 1:07 PM
Subject: Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
Hi Andy,
The original config was built with Yate in mind due to openser incapacity (before
release 1.3) of disconnecting the calls. Since 1.3.0 the dialog module should be able to
timeout the calls, in theory you should no longer need extra software like Yate.
I would still recommend using Yate combined with OpenSER in the case you are doing some
sort of "Carrier business", for the following reasons:
1. It creates two different legs for your call (in and out) same as Cisco does, and
hides one side from the other (eg. removes the via headers and any revealing ip
information inside SDP - so your partners should not know where the traffic comes from).
2. You have more protocols available in.
3. Accounting it is bit more accurate (you have the session total duration inside the
accounting packets), so radius will be no longer responsible of calculating the session
durations from timestaps.
4. Yate can work in rtp_forward mode, therefore no extra overhead given by rtp
processing.
So basically what the connector does (as specified in the documentation), for each call
which is authorized by radius, the connector will ask permission from cdrtool. If
permission is granted, it will return in a avp to openser the maximum duration allowed for
the call (timeout value) plus credit available, for the case of special uas able to
display that.
By receiving accounting stop packet, the connector will inform cdrtool about call
disconnection therefore clearing the lock and debiting the balance inside cdrtool. The rtp
stream has nothing to do with this scenario, so you don't need to touch your NAT
support configuration, it's all in the signaling.
Let me know if you need further info.
Cheers,
DanB
On Feb 13, 2008 12:53 PM, A.smith <a.smith(a)ukgrid.net> wrote:
Hi Dan/List,
I was reading the post below and trying to understand how your config
works. If
you are implementing this with something like a Cisco PSTN then you need all
of
these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does
the RTP
stream have to route via Yate and mediaproxy? :S
thanks for any help! cheers Andy.
Hey Marc,
I use Yate for doing that. It is simple and works out of the box (with
adding
few
lines in configs of course).
I take Session timeout returned from connector and pass it to yate in a sip
header
Process that header in regex routing and define the
value as timeout for
session.
Yate knows by default that when a session has a
parameter "timeout"
returned
from routing to disconnect the call when timeout is
hit.
Let me know if you need further info, so I can send you some config files
if
you
want to. You can contact me on IRC for live support
(DanB).
All the best,
DanB
________________________________________________
Message sent using UK Grid Webmail 2.7.9
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16
7:26 p.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
Andy,
I would say both methods are having disadvantages and advantages.
1. The mediaproxy timeout is a plus if this turns to be stable . I had some
not so good experiences in the past and not really responsive support for my
issues, so I have dropped the idea. I will need to recheck, perhaps the
issues were solved.
2. Yate has no rtp detection, therefore will not detect your dead sessions.
I preferred to use it due to prepaid stuff and automatic header masking
features I told you about.
Accounting issues were discussed and rediscussed over and over on this list,
so I will not pop up the subject again.
I think the best accounting technique would be still the last device which
is in touch with your carrier which charges you, so if you send it to PSTN,
then I would say use accounting provided by your PSTN gateway.
Cheers,
DanB
On Feb 13, 2008 6:06 PM, Andy Smith <a.smith(a)ukgrid.net> wrote:
Hi Dan,
one other query on the below, regarding Yate providing more accuarate
accounting, if OpenSER is used with mediaproxy will this not provide the
same level of accuracy (as Mediaproxy actually sits in the RTP stream)?
thanks Andy.
----- Original Message -----
*From:* Dan-Cristian Bogos <danb.lists(a)googlemail.com>
*To:* A.smith <a.smith(a)ukgrid.net>
*Cc:* users(a)lists.openser.org
*Sent:* Wednesday, February 13, 2008 1:07 PM
*Subject:* Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1Released
Hi Andy,
The original config was built with Yate in mind due to openser incapacity
(before release 1.3) of disconnecting the calls. Since 1.3.0 the dialog
module should be able to timeout the calls, in theory you should no longer
need extra software like Yate.
I would still recommend using Yate combined with OpenSER in the case you
are doing some sort of "Carrier business", for the following reasons:
1. It creates two different legs for your call (in and out) same as Cisco
does, and hides one side from the other (eg. removes the via headers and any
revealing ip information inside SDP - so your partners should not know where
the traffic comes from).
2. You have more protocols available in.
3. Accounting it is bit more accurate (you have the session total duration
inside the accounting packets), so radius will be no longer responsible of
calculating the session durations from timestaps.
4. Yate can work in rtp_forward mode, therefore no extra overhead given by
rtp processing.
So basically what the connector does (as specified in the documentation),
for each call which is authorized by radius, the connector will ask
permission from cdrtool. If permission is granted, it will return in a avp
to openser the maximum duration allowed for the call (timeout value) plus
credit available, for the case of special uas able to display that.
By receiving accounting stop packet, the connector will inform cdrtool
about call disconnection therefore clearing the lock and debiting the
balance inside cdrtool. The rtp stream has nothing to do with this scenario,
so you don't need to touch your NAT support configuration, it's all in the
signaling.
Let me know if you need further info.
Cheers,
DanB
On Feb 13, 2008 12:53 PM, A.smith <a.smith(a)ukgrid.net> wrote:
Hi Dan/List,
I was reading the post below and trying to understand how your config
works. If
you are implementing this with something like a Cisco PSTN then you need
all
of
these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route?
Does
the RTP
stream have to route via Yate and mediaproxy? :S
thanks for any help! cheers Andy.
------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date:
11/02/2008 08:16
Hey Marc,
I use Yate for doing that. It is simple and works out of the box (with
adding few
lines in configs of course).
I take Session timeout returned from connector and pass it to yate in a
sip
header
Process that header in regex routing and define
the value as timeout
for
session.
Yate knows by default that when a session has a
parameter "timeout"
returned
from routing to disconnect the call when timeout
is hit.
Let me know if you need further info, so I can send you some config
files
if you
want to. You can contact me on IRC for live
support (DanB).
All the best,
DanB
________________________________________________
Message sent using UK Grid Webmail 2.7.9
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
14 Feb
14 Feb
9:33 a.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
El Wednesday 13 February 2008 19:26:16 Dan-Cristian Bogos escribió:
1. The mediaproxy timeout is a plus if this turns to
be stable . I had some
not so good experiences in the past and not really responsive support for
my issues, so I have dropped the idea. I will need to recheck, perhaps the
issues were solved.
Hi Dan, I'm testing right now CDRTool + MediaProxy + FreeRadius. I hope this
to be in production in few time.
For now, it seems to work OK but I've discovered some issues related to
the "slq.conf" file that uses Radius for actions "START, UPDATE (by
MediaProxy) and STOP". I've made fix them by improving a bit the SQL queries.
Anyway, yesterday I did a call to an Asterisk through MediaProxy and after 6
seconds I received an UPDATE "mediatimeout" from MediaProxy. The audio was
working perfectly before and after that event!! so finally it caused a
eternal "in progress" CDR.
Have you experimented things like that?
You are right when say that there is not really responsive support for all
those problems, but if you want we could speak about them (if you are
interested in try it again, of course).
Best regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
10:04 a.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
Hey Iñaki,
Sure I can help (at least I have will to do so :) ).
There could be some time until some of my projects will get sorted, but
otherwise it's just a question of priorities on my side.
On the non responsive side, I understand Adrian and his folks about how hard
is to run a business and also give support for it, so perhaps somewhere
could be also the community 's fault since the design of his software is
clean and the software is not hard to be understood.
When it comes to problems I had with mediaproxy in the past, the issues were
in not properly detecting the media timeout (I have just killed the client
on one side without sending any bye and the media timeout was never
detected), so not really your scenario but perhaps on the same place in
code.
DanB.
On Thu, Feb 14, 2008 at 9:33 AM, Iñaki Baz Castillo <ibc(a)in.ilimit.es>
wrote:
El Wednesday 13 February 2008 19:26:16 Dan-Cristian
Bogos escribió:
1. The mediaproxy timeout is a plus if this turns
to be stable . I had
some
not so good experiences in the past and not
really responsive support
for
my issues, so I have dropped the idea. I will
need to recheck, perhaps
the
issues were solved.
Hi Dan, I'm testing right now CDRTool + MediaProxy + FreeRadius. I hope
this
to be in production in few time.
For now, it seems to work OK but I've discovered some issues related to
the "slq.conf" file that uses Radius for actions "START, UPDATE (by
MediaProxy) and STOP". I've made fix them by improving a bit the SQL
queries.
Anyway, yesterday I did a call to an Asterisk through MediaProxy and after
6
seconds I received an UPDATE "mediatimeout" from MediaProxy. The audio was
working perfectly before and after that event!! so finally it caused a
eternal "in progress" CDR.
Have you experimented things like that?
You are right when say that there is not really responsive support for all
those problems, but if you want we could speak about them (if you are
interested in try it again, of course).
Best regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
10:17 a.m.
New subject: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
El Thursday 14 February 2008 10:04:23 Dan-Cristian Bogos escribió:
On the non responsive side, I understand Adrian and
his folks about how
hard is to run a business and also give support for it, so perhaps
somewhere could be also the community 's fault since the design of his
software is clean and the software is not hard to be understood.
Yes, sure, in fact I meant that it seems that there is not enought community
movement about this project (not many questions, not many replies...), when
it's obviously a very important part in any SIP provider project.
Of course nothing to object to CDRTool authors, they have done a very very
good software.
When it comes to problems I had with mediaproxy in the
past, the issues
were in not properly detecting the media timeout (I have just killed the
client on one side without sending any bye and the media timeout was never
detected), so not really your scenario but perhaps on the same place in
code.
I have done some tests like that, by cutting the RTP in the client (via
iptables) and the timeout is properly detected (of course I need more
testing).
Best regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6134
days inactive
6135
days old
6 comments
4 participants
participants (4)
-
A.smith -
Andy Smith
-
Dan-Cristian Bogos -
Iñaki Baz Castillo