Hashing over call-id may work to some degree, and I'll investigate it more, but hashing over the From: means that the same caller will always get the same Asterisk box, and your redundancy goes down the toilet.
Actually I guess it's down the toilet anyway. The bottom line seems to be that it doesn't matter whether you use the dispatcher or SRV records to distribute load, OpenSER will never try to connect to anything else on failure and at least for us, that makes it use in a production system, not an option.
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
Sent: Thu 11/24/2005 12:19 PM
To: Douglas Garstang
Cc: users(a)openser.org
Subject: Re: [Users] Dispatcher module - Does it actually work?
On 11/24/05 19:53, Douglas Garstang wrote:
> The request URI from the phones is always going to be the same. Doesn't that mean that OpenSER will always just use the same Asterisk box then?
if you do hash over r-uri, then yes, all messages will go to same
destination.
> I'm trying to round-robin as evenly (as possible) and distribute call load amonst multiple Asterisk systems.
>
In this case hash over call-id or from is more indicated.
Cheers,
Daniel
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
> Sent: Thu 11/24/2005 10:25 AM
> To: Douglas Garstang
> Cc: users(a)openser.org
> Subject: Re: [Users] Dispatcher module - Does it actually work?
>
>
>
> On 11/24/05 01:37, Douglas Garstang wrote:
> > After many many fruitless hours spent on trying to get OpenSER to work with DNS SRV records (I made a post to the group earlier today on this), I stumbled across the dispatcher module, and have been trying to get it to work instead.
> >
> > The module was designed to load balance, right? It doesn't seem to have been designed very well, unless I am missing something.
> >
> If you read carefully the documentation of the module, you will see the
> scope and limitations of the module:
> http://openser.org/docs/modules/1.0.x/dispatcher.html
>
> If something is not according to the documentation, then it is a bug.
> Stateless means that the module does not keep any state, so it cannot
> select the same destination using algorithm 4 (round robin) after a
> authentication request, choose another algorithm (hashing r-uri,
> callid). Also, being stateless, it cannot try the next address if the
> selected destination fails.
>
> The module was not designed to be load balancer, but a request
> dispatcher. Load balancing is something more complex.
>
> In the last weeks I added destination failover support in dispatcher
> (serial forking within the destination set, with auto-detection of
> failed destinations). It will be on cvs very soon, I have to update the
> documentation and do some testing.
>
> Cheers,
> Daniel
>
> >
> > If you set the algorithm with ds_select_dst() to 4, round robin, it doesn't work! Here's what happens.
> >
> > 1. UA sends INVITE to OpenSER
> > 2. OpenSER forwards INVITE to the first proxy in the dispatcher list.
> > 3. Proxy sends back a digest challenge for authorisation credentials to OpenSER.
> > 4. OpenSER forwards the challenge back to the UA.
> > 5. The UA sends the INVITE again to OpenSER, this time with the requested credentials.
> > 6. OpenSER forwards the new INVITE to the _OTHER_ proxy in the dispatcher list.
> >
> > This is where things start to fall over. This proxy has not issued a challenge request yet so it _again_ sends a digest challenge back to the UA through OpenSER. The UA does not like to receive a second challenge to what it's already sent and gives up.
> >
> > If you set the algorithm to something else besides 4, say 0, to hash to the callid, then OpenSER tries to use an arbitrary proxy from the list. Given that it's hashed against the callid it doesn't switch proxies like it does above in mid call. However, if that proxy is down, it _NEVER_ tries another proxy, thus rending the dispatcher module as a load balancer completely useless.
> >
> > If this module was designed to be a load balancer, how have people gotten it to work? I find it incredibly hard to believe that the dispatcher module was not designed with the above scenarios in mind. I'm so frustrated because what I am trying to do is so simple (had issues with SRV behaving in a similar way). Send requests from OpenSER to another proxy/pbx in a redundant and load balanced fashion. If a system is down, simply go to the next! It's that simple!
> >
> > Btw, the 'proxy' that OpenSER is forwarding too is Asterisk (yeah ok so it isn't a proxy) and the UA's are Polycom 301/501/601 phones.
> >
> > Help very much appreciated!
> >
> > Thanks.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
Hi all!
Regarding SIP and TCP/TLS there are often discussions how many
concurrently TCP/TLS connections a server can handle.
Does some one of have experience with long living TCP connections? Are
there performance issues?
I also want to do some tests, loading ser with lots of TCP connections.
Do you know any test tools for this?
regards
klaus
Well, after 12 hours at this, my brain hurts.
Andreas, I've been trying to get the lcr module to work.
I'd really appreciate some pointers or help. :)
OpenSER is not attempting to contact the second gw. It just sits there forever trying to connect to the first. I even tried setting fr_inv_timer, but it has no effect. The openser.cfg is probably full of errors too, but I can definitely see it trying to connect to the first gw, and it never tries the second. I purposely shut Asterisk down on the first.
Here's my mysql database tables:
mysql> select * from lcr;
+--------+----------+--------+----------+
| prefix | from_uri | grp_id | priority |
+--------+----------+--------+----------+
| | % | 1 | 1 |
| | % | 2 | 2 |
+--------+----------+--------+----------+
2 rows in set (0.00 sec)
mysql> select * from gw;
+-----------+--------+-----------+------+------------+-----------+--------+
| gw_name | grp_id | ip_addr | port | uri_scheme | transport | prefix |
+-----------+--------+-----------+------+------------+-----------+--------+
| asterisk1 | 1 | 369797312 | 5060 | 1 | 1 | |
| asterisk2 | 2 | 386574528 | 5060 | 1 | 1 | |
+-----------+--------+-----------+------+------------+-----------+--------+
2 rows in set (0.00 sec)
And here's the relevant snippets from openser.cfg:
modparam("lcr","fr_inv_timer",1)
# Standard openser.cfg down to here
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
};
# I added the line below
route(2);
# More standard openser.cfg lines
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
append_hf("P-hint: usrloc applied\r\n");
#I added the route[2] block
route[2] {
if (!load_gws()) {
sl_send_reply("500", "Server Internal Error - Cannot load gateways");
xlog ("L_INFO","Not found");
return;
} else {
xlog ("L_INFO","Gateways loaded");
}
if (!next_gw()) {
sl_send_reply("503", "Service not available, no gateways found");
xlog ("L_INFO","No more gateways");
return;
} else {
xlog ("L_INFO","Found a gateway");
}
xlog ("L_INFO","Calling t_relay");
t_on_failure("2");
t_relay();
exit;
}
failure_route[2]
{
if(method == "INVITE" && t_check_status("408|500|503"))
{
if (!next_gw())
{
t_reply("503", "Service not available, no more gateways");
return;
}
t_on_failure("2");
t_relay();
}
}
-----Original Message-----
From: Andreas Granig [mailto:andreas.granig@inode.info]
Sent: Thu 11/24/2005 5:24 PM
To: Douglas Garstang
Cc: users(a)openser.org
Subject: Re: [Users] Dispatcher module - Does it actually work?
Douglas Garstang wrote:
> Andy, no. No one has suggested using the lcr module, and I wasn't even aware of it until you mentioned it just now. I took a look at the module docs, they're way beyond my current understanding. it. I'll have to do some reading. Does it allow you to try another route when one is not responding?
Yes. You have to define a set of destinations which you can load in the
script using load_gws(), and every call to next_gw() sets the ip/port of
another destination as ruri, until no more destinations are available.
You can find an example here:
http://linguin.org/ser/lcr_cap/lcr_config_example.txt
It's for a lcr-version which I have extended a little to be able to
group destinations according to their capabilities
(http://linguin.org/ser.php#lcr-cap), but you should at least get the
idea on how to do it with the vanilla lcr module (just leave out the
argument in load_gws()).
Andy
Andy (or anyone who cares to jump in here),
From the openser docs:
"A gateway matches a request if user part of Request-URI and "From" URI match the prefix and From pattern of the gateway. "
Does that mean that I need to have a gw table entry for every single possible combination of every user making calls and every number in the universe they may dial? That's insane! I must be missing something here.
Oh, and what is an 'RPID URI'???? Never heard of it and I can't find it mentioned anywhere outside the lcr module.
-----Original Message-----
From: Douglas Garstang
Sent: Thu 11/24/2005 7:45 PM
To: users(a)openser.org
Cc:
Subject: RE: [Users] Dispatcher module - Does it actually work?
Correct me if I am wrong here, but the sketchy docs at openser.org seem to imply that I am going to need to have multiple rows in my mysql table 'gw' for every single user who places calls? Is that correct? Is there some way to trim this down?
-----Original Message-----
From: Andreas Granig [mailto:andreas.granig@inode.info]
Sent: Thu 11/24/2005 5:24 PM
To: Douglas Garstang
Cc: users(a)openser.org
Subject: Re: [Users] Dispatcher module - Does it actually work?
Douglas Garstang wrote:
> Andy, no. No one has suggested using the lcr module, and I wasn't even aware of it until you mentioned it just now. I took a look at the module docs, they're way beyond my current understanding. it. I'll have to do some reading. Does it allow you to try another route when one is not responding?
Yes. You have to define a set of destinations which you can load in the
script using load_gws(), and every call to next_gw() sets the ip/port of
another destination as ruri, until no more destinations are available.
You can find an example here:
http://linguin.org/ser/lcr_cap/lcr_config_example.txt
It's for a lcr-version which I have extended a little to be able to
group destinations according to their capabilities
(http://linguin.org/ser.php#lcr-cap), but you should at least get the
idea on how to do it with the vanilla lcr module (just leave out the
argument in load_gws()).
Andy
Thanks Andy. I'll take a look. Considering I can't even find documentation for what a route() block is, I'm in for a lot of reading. *sigh* Docs.... docs.... docs.... (or lack thereof)
-----Original Message-----
From: Andreas Granig [mailto:andreas.granig@inode.info]
Sent: Thu 11/24/2005 5:24 PM
To: Douglas Garstang
Cc: users(a)openser.org
Subject: Re: [Users] Dispatcher module - Does it actually work?
Douglas Garstang wrote:
> Andy, no. No one has suggested using the lcr module, and I wasn't even aware of it until you mentioned it just now. I took a look at the module docs, they're way beyond my current understanding. it. I'll have to do some reading. Does it allow you to try another route when one is not responding?
Yes. You have to define a set of destinations which you can load in the
script using load_gws(), and every call to next_gw() sets the ip/port of
another destination as ruri, until no more destinations are available.
You can find an example here:
http://linguin.org/ser/lcr_cap/lcr_config_example.txt
It's for a lcr-version which I have extended a little to be able to
group destinations according to their capabilities
(http://linguin.org/ser.php#lcr-cap), but you should at least get the
idea on how to do it with the vanilla lcr module (just leave out the
argument in load_gws()).
Andy
I'm running SER. It allow caller make call PSTN.
========= ======= ==========
| | make call | | | |
| Caller | =========> | SER | =======> | Gateway | ====> PSTN
| | | | | |
========= ======= ==========
I want auto terminate this call after 30' ==> How to config SER ??
Plz help me solve this problem. Thanks
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.
Andy, no. No one has suggested using the lcr module, and I wasn't even aware of it until you mentioned it just now. I took a look at the module docs, they're way beyond my current understanding. it. I'll have to do some reading. Does it allow you to try another route when one is not responding?
Doug.
-----Original Message-----
From: Andreas Granig [mailto:andreas.granig@inode.info]
Sent: Thu 11/24/2005 2:25 PM
To: Douglas Garstang
Cc: users(a)openser.org
Subject: Re: [Users] Dispatcher module - Does it actually work?
Douglas Garstang wrote:
> Hashing over call-id may work to some degree, and I'll investigate it more, but hashing over the From: means that the same caller will always get the same Asterisk box, and your redundancy goes down the toilet.
>
> Actually I guess it's down the toilet anyway. The bottom line seems to be that it doesn't matter whether you use the dispatcher or SRV records to distribute load, OpenSER will never try to connect to anything else on failure and at least for us, that makes it use in a production system, not an option.
I didn't follow the whole thread, so maybe this has been suggested
before, but have you ever thought about using the lcr module for load
balancing? In combination with failure routes for failover this works
very well for me.
Andy
Hello,
here is an other diagram for people who don't yet
understand what i expect to do.
Look at sip_call_flow.png file i wish to substitute
ondo sip server with ser and ondo pbx with asterisk .
ondo sip server is able to do far-end near-end nat I
guess ser too.
I do hope i will find some people who help me to
configure that .
Regards
Harry
Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)
Hello,
here is an other diagram for people who don't yet
understand what i expect to do.
Look at sip_call_flow.png file i wish to substitute
ondo sip server with ser and ondo pbx with asterisk .
ondo sip server is able to do far-end near-end nat I
guess ser too.
I do hope i will find some people who help me to
configure that .
Regards
Harry
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
Hello,
here is an other diagram for people who don't yet
understand what i expect to do.
Look at sip_call_flow.png file i wish to substitute
ondo sip server with ser and ondo pbx with asterisk .
ondo sip server is able to do far-end near-end nat I
guess ser too.
I do hope i will find some people who help me to
configure that .
Regards
Harry
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
