Simith, Not easy to tell what the problem can be. You haven't included your ser.cfg. If you are new to ser, I would recommend that you download the Getting Started document from http://onsip.org/ and the configuration file package with all the ser.cfg example files. Those should get you started. g-)

Simith Nambiar wrote:

Hi Greger,

Thanks for the response, I don't know you, but i have been seeing your response on the mailing list for Serusers, but my post is never landing there , which is my problem.

I subscribed yesterday, still my requests are pending "Moderator approval" , i would have been happy if someone could help me, in running SER, i have an Error coming from route.c pasted below, It is from fix_rls --> fix_action , i don't understand what they are doing there in code, as i'am new to SER.

Listening on udp: 127.0.0.1 [127.0.0.1]:5070 udp: 10.10.100.44 [10.10.100.44]:5070 tcp: 127.0.0.1 [127.0.0.1]:5070 tcp: 10.10.100.44 [10.10.100.44]:5070 Aliases: tcp: linuxdemo:5070 tcp: linuxdemo.indts.com:5070 tcp: localhost:5070 tcp: localhost.localdomain:5070 udp: linuxdemo:5070 udp: linuxdemo.indts.com:5070 udp: localhost:5070 udp: localhost.localdomain:5070

WARNING: no fork mode and more than one listen address found(will use only the the first one) stateless - initializing 0(0) Maxfwd module- initializing textops - initializing ERROR: error -478 while trying to fix configuration

Something wrong with the config file ? As my mails are not reaching the list, can you plz forward this or offer any help that might fix my problem ! Thanks for your time.

Cheers. Simith

-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Wednesday, May 18, 2005 11:42 AM To: Simith Nambiar Subject: Re: [Serusers] More on load balancing: LVS + SRVs, SER + Asterisk

I'm not sure if I know you and your problem? Posting on serusers is your best hope to get help. Be specific and write short summary at the top what the problem is, then add more info further below. Most often a post that is

not answered is because it's too much work to try to decipher what the problem can be. g-)

Simith Nambiar wrote:

...

Hi Greger, I feel you are busy , please can you give me some id, that i can write to to fix my problem, I mean the moderator or someone, i'am badly in ned of a solution, as i do not Ser very well, i'am not able to fix it on my own.

Maybe once i study the code, i can fix it myself, until then i just wanted to see it up and running and test it for some funcionality, hope u understand.

Please help !

cheers. Simith

-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Wednesday, May 18, 2005 11:12 AM To: Pietro Ravasio; serusers@lists.iptel.org Subject: Re: [Serusers] More on load balancing: LVS + SRVs, SER + Asterisk

Pietro Ravasio wrote:

...

Anyway, at the moment "mixing Asterisk with SER" is not my major concern, I'm pretty worried about trying to use a particular outbound proxy for calls to a NATed UA:

...

I think that the dispatcher module of ser can be used cheaper instead of using LVS, which will not give you call-id persistence anyway. AFAIU, your scenario is quite similar to what I described in this thread: http://lists.iptel.org/pipermail/serusers/2005-May/019118.html Just a different implementation...

Yes, I now agree with you in using this approach rather than "multiple internal domains" one. The only things I'd like to modify are: - storing location on every message, not only on REGISTER, in case a ser dies and lvs udp persistence sends the next UA message to another SER (for instance my Sipura phone sends a bunch of NOTIFY messages in order to keep NAT open, if a ser dies and if phone is already authenticated, I want to update "its SER")

I'm not sure if I like the idea of doing an sql write for every single message. That's will be a massive performance hit. But the idea is good. What about doing LVS NAT?

...

• using only one table for every SER storing in a different column

the proxy (taken from dst_ip) who has handled the message. This way I don't have to preprovision all SER instances in all ser.cfg routing logics. At this point:

But then you have to modify SER, which is back to where we started:

1. If you have to modify SER to do load balancing, what would be the

best way to do it? 2. The answer is most likely: Do it in a module like dispatcher, but add call-id persistence 3. Doing level 7 load balancing can only be effective in the kernel

So why not focus your attention on creating call-id persistence in LVS? ;-)

...

.) if I use a B2B user agent in order to handle NAT (for instance asterisk) - I'd send INVITE to my B2B UA (t_relay_to_udp("b2bua_lvs_virtual_ip")) with rewritten Contact: field with the IP number of the (outbound) SER UAB has registered/sent its latest message to (taken from DB)

..) otherwise, in a "pure SER" environment,

• I'd send INVITE directly to the SER proxy which IP:port is taken

from DB with the same logic as above

Yes, but how do you know the server just went down and you still haven't updated the IP:port of the UA? I assume you will use t_replicate and save_memory to make sure that all servers have the updated registration info

in memory? (as DB writethrough works fine, but other ser's will not load the

new location upon receiving an INVITE) You probably have to do t_replicate for EVERY message to update the IP:port of the UA and you're into massive overload of SIP messages (used by t_replicate).

...

Using only one location table could be useful in order to create a flexible routing logic: if the server taken from DB is not online anymore, send message to another one (randomly chosen), hoping that UAS is not behind nat. This logic could be inserted in B2BUA dialing plans or in ser.cfg.

I don't like the word "hoping"...

...

...

If it's work, it's a workaround. No better or worse than other workarounds... g-)

At the moment I start thinking that any technique that tries to bind an outbound SER for all calls to a set of user agents, is going to be a workaround... Am I wrong? :-/

No, I don't think so. That is trying to do something at the application level that people have long figured out is better done at lower levels... In fact, I believe the simplest solution would be to make sure that LVS can select ANY SER for load balancing and use LVS NAT (which is quite scalable and is the way Cisco does it). The simplest way to modify ser for this would be to make sure that all lookup("location") calls actually make an sql

read. If each ser instance flushes each save to db and a shared sql cluster

is used as backend, you are good to go.

The other way is to implement call-id persistence in IPVS (LVS' load balancer). I like this better, because you do it in kernel mode and don't add a whole lot of new DB reads...

g-)

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

This email has been scanned via a message filtering facility. If you have any issues with your email, please contact the IT Dept.

---

This email has been scanned via a message filtering facility. If you have any issues with your email, please contact the IT Dept.