12 Jun
2008
12 Jun
'08
3:27 a.m.
Hello all,
Question: I know BYE messages aren't gusranteed to be delivered as far
as accounting is concerned. BUT, Could Dialog and TM modules be used in the
following way:
Setting a timeout on the dialog to receive the first message, i.e. 100 or
180.
Instruct the UAC to send a message every 60 senconds to our server, and
reseting that timer when we receive it, so that we know that the call hasn't
ended.
If we don't receive that "keep-alive" message we end the dialog with a BYE
(from an outside script) so that, even if the caller or calle dropped out of
the internet, we have a START and END for this call, maybe loosing a few
senconds.
Is this possible at all?
Thanks a lot!
David
12 Jun
12 Jun
10:47 a.m.
Hi David,
This should work, if you manage to convince the UAC to periodically send
some with-in the dialog requests.
When sending the BYE via MI command, you could use a local_route to
catch the BYE and do accounting for it from the script.
Regards,
Bogdan
David Villasmil wrote:
Hello all,
Question: I know BYE messages aren't gusranteed to be delivered
as far as accounting is concerned. BUT, Could Dialog and TM modules be
used in the following way:
Setting a timeout on the dialog to receive the first message, i.e. 100
or 180.
Instruct the UAC to send a message every 60 senconds to our server,
and reseting that timer when we receive it, so that we know that the
call hasn't ended.
If we don't receive that "keep-alive" message we end the dialog with a
BYE (from an outside script) so that, even if the caller or calle
dropped out of the internet, we have a START and END for this call,
maybe loosing a few senconds.
Is this possible at all?
Thanks a lot!
David
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:04 a.m.
El Thursday 12 June 2008 02:27:05 David Villasmil escribió:
Instruct the UAC to send a message every 60 senconds
to our server,
And how will you do it?
and
reseting that timer when we receive it, so that we know that the call
hasn't ended.
If we don't receive that "keep-alive"
message we end the dialog with a BYE
(from an outside script)
How will you know when the keep-alive is not received?
This is, OpenSer will receive a keepalive and if it's not received an external
script should call a MI command to generate the BYE. How will you do it?
Best regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
3:06 p.m.
Instruct the UAC to send a message every 60
senconds to our server,
And how will you do it?
and
reseting that timer when we receive it, so that we know that the call
hasn't ended.
If we don't receive that
"keep-alive" message we end the dialog with a
BYE
(from an outside script)
How will you know when the keep-alive is not received?
This is, OpenSer will receive a keepalive and if it's not received an
external
script should call a MI command to generate the BYE. How will you do it?
Regarding this, I know we could simply use the Dialog module to store al
3:22 p.m.
El Thursday 12 June 2008 14:06:22 David Villasmil escribió:
Regarding this, I know we could simply use the Dialog
module to store al
dialogs on the dialog table, and use an external script to end the dialog
How knows the external script where to generate the BYE?
On the other hand, Bogdan says it should work. Even if
not ALL UACs do sent
the in-dialog-keep-alive, most of the should, as most adhere to RFCs. We
should try to get this working as it would solve not only mine, but a lot
of people's problems of calls dropped that can't be properly rated.
Why not use SessiontTimers (RFC 4028) ?
99% of phones replies 200 to a re-INVITE.
I'm writing to the users list because I'm NOT
that well versed on TM and
DIALOG's inner workings, and really wouldn't know where to start. Though
I'll start investigating on this.... Anyone wants to help?
The problem is that you are addressing the problem in a privative way while
there are RFC's and techniques for that. For your proposal using Session
Timers should be the best option, but you need a UAS sending the re-INVITE's
(at last one of both endpoinds). OpenSer cannot send it since it is a proxy
so a B2BUA or gateway should doit.
IMHO you are addressing the problem in the wrong place (but it could work of
course).
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
3:38 p.m.
On Thu, Jun 12, 2008 at 2:22 PM, Iñaki Baz Castillo <ibc(a)in.ilimit.es>
wrote:
Are you talking, i.e. Asterisk?
but you need a UAS sending the re-INVITE's
El Thursday 12 June 2008 14:06:22 David Villasmil
escribió:
Its very easy to do that, I understand that expired dialogs are reported on
the syslog, with that and openser fifo you can end a dialog by sending a BYE
Regarding this, I know we could simply use the
Dialog module to store al
dialogs on the dialog table, and use an external script to end the dialog
How knows the external script where to generate the BYE?
On the other hand, Bogdan says it should work.
Even if not ALL UACs do
sent
the in-dialog-keep-alive, most of the should, as
most adhere to RFCs. We
should try to get this working as it would solve not only mine, but a lot
of people's problems of calls dropped that can't be properly rated.
Why not use SessiontTimers (RFC 4028) ?
99% of phones replies 200 to a re-INVITE.
I'm writing to the users list because I'm
NOT that well versed on TM and
DIALOG's inner workings, and really wouldn't know where to start. Though
I'll start investigating on this.... Anyone wants to help?
The problem is that you are addressing the problem in a privative way while
there are RFC's and techniques for that. For your proposal using Session
Timers should be the best option, (at last one of both endpoinds). OpenSer cannot send
it since it is a proxy
so a B2BUA or gateway should doit.
IMHO you are addressing the problem in the wrong place (but it could work
of
course).
I see what you're saying, problem with this is I don't WANT to HAVE to use
an asterisk or whatever... I want to depend only on Openser.
I believe I can be done with session timers, as you say. What I Don't KNOW
is whether there is a timer to ask the UAC to send us a kind of "keep-alive"
message. I don't know what that message is called, or what module creates
it.
The thing is:
What module's function to use to make the UAC send uns a "keep-alive"
whilst
in a dialog every X senconds, setting a timeout for that keep-alive to be
sent and resetting it everytime it's received.
thanks to all.
David
4:33 p.m.
El Thursday 12 June 2008 14:38:44 David Villasmil escribió:
No, Asterisk is a bad example for this case since doesn't provide
SessionTimers functions and so.
In fact I'm not suggesting a specific product, but you could try other B2BUA
more SIP compliants and develop a B2BUA between OpenSer and gateways that
implements SessionTimers. Of course it's not an easy task.
You can take a look at those projects:
http://www.b2bua.org/
http://www.resiprocate.org/Main_Page
https://sailfin.dev.java.net/
http://www.opensipstack.org/sbc_man_content.html
OpenSer is a statefull proxy, it shouldn't control dialogs. With "dialog"
module you can do things but obviously is not so complete as you need.
The problem is
that you are addressing the problem in a privative way
while there are RFC's and techniques for that. For your proposal using
Session Timers should be the best option,
Are you talking, i.e. Asterisk? (at last one
of both endpoinds). OpenSer cannot send it since it is a
proxy so a B2BUA or gateway should doit.
IMHO you are addressing the problem in the wrong place (but it could work
of
course).
I see what you're saying, problem with this is I don't WANT to HAVE to use
an asterisk or whatever... I want to depend only on Openser. I believe I can be done with session timers, as you
say. What I Don't KNOW
is whether there is a timer to ask the UAC to send us a kind of
"keep-alive" message. I don't know what that message is called, or what
module creates it.
No one. The mos similar function in OpenSer is the registrar module sending
NOT in-dialog OPTIONS to mantain NAT keepalive.
The thing is:
What module's function to use to make the UAC send uns a "keep-alive"
whilst in a dialog every X senconds, setting a timeout for that keep-alive
to be sent and resetting it everytime it's received.
There is not that function/module for now. :(
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:38 p.m.
Iñaki Baz Castillo writes:
You can take a look at those projects:
http://www.b2bua.org/
http://www.resiprocate.org/Main_Page
https://sailfin.dev.java.net/
http://www.opensipstack.org/sbc_man_content.html
also sems supports session-timer.
-- juha
6:12 p.m.
El Thursday 12 June 2008 16:38:11 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
I forgot SEMS, sorry :)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
You can take a look at those projects:
http://www.b2bua.org/
http://www.resiprocate.org/Main_Page
https://sailfin.dev.java.net/
http://www.opensipstack.org/sbc_man_content.html
also sems supports session-timer. 
7:39 p.m.
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 16:38:11 Juha Heinanen
escribió:
This all seems very disorganized. Co-operation is needed to build a
comprehensive solution. Perhaps a modular session border controller where one
module is Openser and the others are a B2BUA and a media proxy. They would
be optimized to work well together, possibly using non-sip communication.
They could also be used independently. The building blocks are available they
just need to be tweaked.
Iñaki Baz Castillo writes:
I forgot SEMS, sorry :) You can take a look at those projects:
http://www.b2bua.org/
http://www.resiprocate.org/Main_Page
https://sailfin.dev.java.net/
http://www.opensipstack.org/sbc_man_content.html
also sems supports session-timer.
7:48 p.m.
El Thursday 12 June 2008 18:39:33 Robert Dyck escribió:
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
OpenSer + MediaProxy + Radius + CDRTool provides a complete and integrated
solution (except Sessiontimers).
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
El Thursday 12 June 2008 16:38:11 Juha Heinanen
escribió:
This all seems very disorganized. Co-operation is needed to build a
comprehensive solution. Perhaps a modular session border controller where
one module is Openser and the others are a B2BUA and a media proxy. They
would be optimized to work well together, possibly using non-sip
communication. They could also be used independently. The building blocks
are available they just need to be tweaked. Iñaki Baz Castillo writes:
I forgot SEMS, sorry :) You can take a look at those projects:
http://www.b2bua.org/
http://www.resiprocate.org/Main_Page
https://sailfin.dev.java.net/
http://www.opensipstack.org/sbc_man_content.html
also sems supports session-timer.
8:05 p.m.
This all seems very disorganized. Co-operation is
needed to build a
comprehensive solution. Perhaps a modular session border controller where
one module is Openser and the others are a B2BUA and a media proxy. They
would be optimized to work well together, possibly using non-sip
communication. They could also be used independently. The building blocks
are available they just need to be tweaked.
OpenSer + MediaProxy + Radius + CDRTool provides a complete and integrated
solution (except Sessiontimers).
10:29 p.m.
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David Villasmil wrote:
What's your call limit? what is the maximun calls you can take with one
media-proxy? 100?
MediaProxy support more than 3000 flows on a normal mid-range server,
take into account that mediaproxy only forward packets in and out ..
it's more a matter of a good NIC's election than real CPU power or
memory.
So .. 3000 flows for less than 1500€ it's no so bad ;-)
--
Saludos
Raúl Alexis Betancor Santana
Dimensión virtual S.L.
This all seems very disorganized. Co-operation is
needed to build a
comprehensive solution. Perhaps a modular session border controller where
one module is Openser and the others are a B2BUA and a media proxy. They
would be optimized to work well together, possibly using non-sip
communication. They could also be used independently. The building blocks
are available they just need to be tweaked.
OpenSer + MediaProxy + Radius + CDRTool provides a complete and integrated
solution (except Sessiontimers).
10:48 p.m.
What exactly is 3000 flows?
1500 calls?
On Thu, Jun 12, 2008 at 9:29 PM, <rabs(a)dimension-virtual.com> wrote:
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David
Villasmil wrote:
MediaProxy support more than 3000 flows on a normal mid-range server,
take into account that mediaproxy only forward packets in and out ..
it's more a matter of a good NIC's election than real CPU power or
memory.
So .. 3000 flows for less than 1500€ it's no so bad ;-)
--
Saludos
Raúl Alexis Betancor Santana
Dimensión virtual S.L.
>
> > This all seems very disorganized. Co-operation is needed to build a
> > comprehensive solution. Perhaps a modular session border controller
where
> > one module is Openser and the others
are a B2BUA and a media proxy.
They
> > would be optimized to work well
together, possibly using non-sip
> > communication. They could also be used independently. The building
blocks
> > are available they just need to be
tweaked.
>
> OpenSer + MediaProxy + Radius + CDRTool provides a complete and
integrated
solution
(except Sessiontimers).
What's your call limit? what is the maximun calls you can take with one
media-proxy? 100?
11:22 p.m.
Now I have the following question:
to be able to make sure you get ALL accounting info with media-proxy, you
need to use it on ALL CALLS, is this correct?
cheers,
David
On Thu, Jun 12, 2008 at 9:48 PM, David Villasmil <
david.villasmil.work(a)gmail.com> wrote:
What exactly is 3000 flows?
1500 calls?
On Thu, Jun 12, 2008 at 9:29 PM, <rabs(a)dimension-virtual.com> wrote:
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David
Villasmil wrote:
MediaProxy support more than 3000 flows on a normal mid-range server,
take into account that mediaproxy only forward packets in and out ..
it's more a matter of a good NIC's election than real CPU power or
memory.
So .. 3000 flows for less than 1500€ it's no so bad ;-)
--
Saludos
Raúl Alexis Betancor Santana
Dimensión virtual S.L.
>
> > This all seems very disorganized. Co-operation is needed to build a
> > comprehensive solution. Perhaps a modular session border controller
where
> > one module is Openser and the others
are a B2BUA and a media proxy.
They
> > would be optimized to work well
together, possibly using non-sip
> > communication. They could also be used independently. The building
blocks
> > are available they just need to be
tweaked.
>
> OpenSer + MediaProxy + Radius + CDRTool provides a complete and
integrated
solution
(except Sessiontimers).
What's your call limit? what is the maximun calls you can take with one
media-proxy? 100?
13 Jun
13 Jun
2:26 a.m.
On Thu, Jun 12, 2008 at 09:48:17PM +0200, David Villasmil wrote:
What exactly is 3000 flows?
1500 calls?
No, speaking on "media-proxy context" 1 flow = 1 call, because there
is no transcoding, only traffic flowing in and out
--
Saludos
Raúl Alexis Betancor Santana
Dimensión virtual S.L.
14 Jun
14 Jun
9:57 p.m.
2008/6/12 David Villasmil <david.villasmil.work(a)gmail.com>om>:
You can add so MediaProxies as you need in different hosts all of them
controlled by the single "mediaproxy" module in OpenSer. It's very
easy and scalable.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
OpenSer +
MediaProxy + Radius + CDRTool provides a complete and integrated
solution (except Sessiontimers).
What's your call limit? what is the maximun calls you can take with one
media-proxy? 100?
12 Jun
12 Jun
8:14 p.m.
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 18:39:33 Robert Dyck
escribió:
I have not yet tried to integrate these applications but judging from this
mailing list it would appear to be a major challenge.
On Thursday 12 June 2008, Iñaki Baz Castillo
wrote:
OpenSer + MediaProxy + Radius + CDRTool provides a complete and integrated
solution (except Sessiontimers). El Thursday 12 June 2008 16:38:11 Juha Heinanen
escribió:
This all seems very disorganized. Co-operation is needed to build a
comprehensive solution. Perhaps a modular session border controller where
one module is Openser and the others are a B2BUA and a media proxy. They
would be optimized to work well together, possibly using non-sip
communication. They could also be used independently. The building blocks
are available they just need to be tweaked. Iñaki Baz Castillo writes:
> You can take a look at those projects:
>
> http://www.b2bua.org/
> http://www.resiprocate.org/Main_Page
> https://sailfin.dev.java.net/
> http://www.opensipstack.org/sbc_man_content.html
also sems supports session-timer.
I forgot SEMS, sorry :)
6007
days inactive
6009
days old
17 comments
7 participants
participants (7)
-
Bogdan-Andrei Iancu -
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
rabs＠dimension-virtual.com -
Robert Dyck