[Serusers] Post on behalf of Simith Nambiar: error -478 while trying to fix configuration

[Greger V. Teigre]

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 at 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 at teigre.com]
>> Sent: Wednesday, May 18, 2005 11:12 AM
>> To: Pietro Ravasio; serusers at 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 at 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.