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
On 11/24/05 19:50, Douglas Garstang wrote:
> I am doing record routing as far as I know. I've pretty much still got a default openser.cfg, with a few modifications. The record route statement is still in there towards the top. And besides, it's OpenSER that's adding itself to the record-route header, so the route is always going to be the same anyway. I don't follow how that helps.
>
The Record-Route ensures that all messages within same dialog will
follow same path. So the BYE will go same way (or opposite if callee
sends it) as the first INVITE.
>
> I'm still new at this.... at ideas how I'd tell if it was the first invite? Check Cseq?
>
The first invite of a dialog has no To-tag. There is a function in uri
module to check that.
Cheers,
Daniel
>
> Thanks.
>
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
> Sent: Thu 11/24/2005 10:32 AM
> To: Douglas Garstang
> Cc: users(a)openser.org
> Subject: Re: [Users] Dispatcher module - Does it actually work?
>
>
>
>
> On 11/24/05 02:16, Douglas Garstang wrote:
> > Actually, you know, now that I think about it, what I think should happen is that OpenSER should _never_ switch to another proxy when the Dialog/Callid is the same. This just confuses everyone.
> >
> Actually you should use the dispatcher only for the first INVITE and
> CANCEL. To ensure that all the other requests within the dialog follow
> same path, use record-routing.
>
> Cheers,
> Daniel
>
> >
> > It doesn't matter if you use the dispatcher module or DNS SRV. Either one when configured for round robin has the potential to send a second INVITE with requested auth credentials (with the same call-id) to another proxy server. This is bad. This was happening with DNS SRV and it's why I started looking at the dispatcher module instead.
> >
> > There has to be a way to do this....
> >
> > Doug
> >
> > -----Original Message-----
> > From: Douglas Garstang
> > Sent: Wed 11/23/2005 4:37 PM
> > To: users(a)openser.org
> > Cc:
> > Subject: [Users] Dispatcher module - Does it actually work?
> >
> >
> >
> > 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 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
> >
>
>
>
I'm trying to understand a little better the docs for the algorithms in the dispatcher module.
What exactly does 'hash over call-id', or 'hash over from uri' mean? The emphasis here is on the use of the word 'hash'. For a given call-id or a given from uri, I think I understand that the selected proxy will always be the same. However, is there any way to determine how this will distribute call volume between proxies? Is there some magic formula that is used (ie the hash) to select the proxy? I'd like to know what it is so I could run some numbers through it and try and understand how it would break up call placement to proxies for certain input values.
Doug.
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? I'm trying to round-robin as evenly (as possible) and distribute call load amonst multiple Asterisk systems.
-----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
>
Friends,
We are testing our SER set up using SIPSAK.
Are there any limitations in terms of the number of registered
subscribers that
can be kept by SER in memory or in database?
We tried with both db_mod 0 or 1. After some 40,000 registrations, SER
starts
Giving "No memory left" messages and sometimes terminates as well. And
with
db_mode=1, SER can not startup again, giving
We checked the machine and out of 2GBytes of memory only about 10Mbytes
Were used up.
Any ideas?
ramin
------------------------------------------------------------------------
----------------
SER crash errors with db_mode= 0 or 1
------------------------------------------------------------------------
----------------
modparam("usrloc", "db_mode", 0)
OR modparam("usrloc", "db_mode", 1)
12(24376) new_ucontact(): No memory left
12(24376) mem_insert_ucontact(): Can't create new contact
12(24376) insert_ucontact(): Error while inserting contact
12(24376) insert(): Error while inserting contact
12(24376) contacts(): Error while inserting record
12(24376) new_ucontact(): No memory left
12(24376) mem_insert_ucontact(): Can't create new contact
12(24376) insert_ucontact(): Error while inserting contact
12(24376) insert(): Error while inserting contact
12(24376) contacts(): Error while inserting record
19(24383) ERROR: tcpconn_new: mem. allocation failure
19(24383) ERROR: tcp_main_loop: tcpconn_new failed, closing socket
14(24378) Binding
'2224449999335607','sip:2224449999335607@172.16.15.201:3006' has expired
14(24378) Binding
'2224449999335608','sip:2224449999335608@172.16.15.201:3006' has expired
14(24378) Binding
'2224449999335609','sip:2224449999335609@172.16.15.201:3006' has expired
14(24378) Binding
'2224449999335610','sip:2224449999335610@172.16.15.201:3006' has expired
14(24378) Binding
'2224449999127988','sip:2224449999127988@172.16.15.203:1815' has expired
12(24376) new_ucontact(): No memory left
12(24376) mem_insert_ucontact(): Can't create new contact
12(24376) insert_ucontact(): Error while inserting contact
12(24376) insert(): Error while inserting contact
12(24376) contacts(): Error while inserting record
19(24383) ERROR: tcpconn_new: mem. allocation failure
19(24383) ERROR: tcp_main_loop: tcpconn_new failed, closing socket
1(24365) 10(24374) INFO: signal 15 received
13(24377) INFO: signal 15 received
18(24382) 3(24367) INFO: signal 15 received
INFO: signal 15 received
4(24368) 19(24383) INFO: signal 15 received
6(24370) INFO: signal 15 received
------------------------------------------------------------------------
----------------
SER Startup error with db_mode=1
------------------------------------------------------------------------
----------------
And when I try with
modparam("usrloc", "db_mode", 1)
SER exits and to restart it, it gives me the following error and can't
start:
.
[root@ser]/usr/local/ser/etc/ser/logs> 0(0) Maxfwd module- initializing
textops - initializing
callidselect - initializing
callidselect: module initialized successfully!
exec - initializing
0(0) AVPops - initializing
0(0) permissions - initializing
0(0) Default allow file (/usr/local/ser/etc/ser/permissions.allow)
parsed
0(0) Default deny file (/usr/local/ser/etc/ser/permissions.deny) not
found => empty rule set
acc - initializing
0(0) info: mediaproxy: loaded SIP asymmetric clients file containing 2
entries.
0(0) info: mediaproxy: loaded RTP asymmetric clients file containing 2
entries.
0(0) convert_row(): No memory left
0(0) convert_rows(): Error while converting row #2549
0(0) convert_result(): Error while converting rows
0(0) store_result(): Error while converting result
0(0) preload_udomain(): Error while doing db_query
0(0) register_udomain(): Error while preloading domain 'location'
0(0) domain_fixup(): Error while registering domain
0(0) ERROR: fix_expr : fix_actions error
ERROR: error -1 while trying to fix configuration
[root@ser]/usr/local/ser/etc/ser/logs>service ser start
Starting Sip Express Router (SER) server: serListening on
udp: 127.0.0.1 [127.0.0.1]:5
Hello,
In fact I wish ser act like siproxd SER listen ppp0
and eth0
requests are sent to eth0 with private addresses so
SER have to fix contact with ppp0 address .
Regards
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)
Actually, you know, now that I think about it, what I think should happen is that OpenSER should _never_ switch to another proxy when the Dialog/Callid is the same. This just confuses everyone.
It doesn't matter if you use the dispatcher module or DNS SRV. Either one when configured for round robin has the potential to send a second INVITE with requested auth credentials (with the same call-id) to another proxy server. This is bad. This was happening with DNS SRV and it's why I started looking at the dispatcher module instead.
There has to be a way to do this....
Doug
-----Original Message-----
From: Douglas Garstang
Sent: Wed 11/23/2005 4:37 PM
To: users(a)openser.org
Cc:
Subject: [Users] Dispatcher module - Does it actually work?
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 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.
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 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.
I need to add some functions in my ser.cfg for nat
support.
I use my open(ser) as outbound proxy with two
interfaces ppp0 and eth0.
sip agents send requests to eth0.
I want my packets passing through the register and
invite blocks by fixing contact with a public ip.
All packets from private network must be sent to eth0.
Any suggestions
Harry
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
