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
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 deliveredas 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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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.
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
dialogs on the dialog table, and use an external script to end the dialog
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.
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?
Thanks to all
David
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).
On Thu, Jun 12, 2008 at 2:22 PM, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
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?
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
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,
Are you talking, i.e. Asterisk?
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 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
El Thursday 12 June 2008 14:38:44 David Villasmil escribió:
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?
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
(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.
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.
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 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
El Thursday 12 June 2008 16:38:11 Juha Heinanen escribió:
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 :)
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 16:38:11 Juha Heinanen escribió:
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 :)
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.
El Thursday 12 June 2008 18:39:33 Robert Dyck escribió:
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 16:38:11 Juha Heinanen escribió:
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 :)
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).
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?
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David Villasmil wrote:
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?
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.
What exactly is 3000 flows? 1500 calls?
On Thu, Jun 12, 2008 at 9:29 PM, rabs@dimension-virtual.com wrote:
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David Villasmil wrote:
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?
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.
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@gmail.com> wrote:
What exactly is 3000 flows? 1500 calls?
On Thu, Jun 12, 2008 at 9:29 PM, rabs@dimension-virtual.com wrote:
On Thu, Jun 12, 2008 at 07:05:07PM +0200, David Villasmil wrote:
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?
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.
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.
2008/6/12 David Villasmil david.villasmil.work@gmail.com:
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?
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.
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 18:39:33 Robert Dyck escribió:
On Thursday 12 June 2008, Iñaki Baz Castillo wrote:
El Thursday 12 June 2008 16:38:11 Juha Heinanen escribió:
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 :)
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).
I have not yet tried to integrate these applications but judging from this mailing list it would appear to be a major challenge.
-
Bogdan-Andrei Iancu -
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
rabs＠dimension-virtual.com -
Robert Dyck