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:
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?
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.
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?
Why not use SessiontTimers (RFC 4028) ? 99% of phones replies 200 to a re-INVITE.
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:
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
Are you talking, i.e. Asterisk?
but you need a UAS sending the re-INVITE's
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ó:
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.
No one. The mos similar function in OpenSer is the registrar module sending NOT in-dialog OPTIONS to mantain NAT keepalive.
There is not that function/module for now. :(
On Thursday 12 June 2008, Iñaki Baz Castillo 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.
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.
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 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:
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.
-
Bogdan-Andrei Iancu -
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
rabs＠dimension-virtual.com -
Robert Dyck