Fredrik,
                 I thank you again for your quick and helpful response ! It
was stupid of me to not check that first before invoking incoming proxy.

I am able to start incoming proxy now ! I am currently listening on port
5060 (UDP and TCP)

I have the following details on incomingproxy.config

[{incomingproxy, [{sipauth_realm, "a.b.com"},
                  {sipauth_password, "secret"},
                  {logger_logbasename, "/var/log/yxa/incomingproxy"},
                  {userdb_modules, [sipuserdb_file]},
                  {databaseservers, ['/var/yxa/db/incomingproxy']},
                  {myhostnames, ["a.b.com"]},
                  {homedomain, ["a.b.com"]}
                ]}].

the usersdb file (at /var/yxa/usersdb) is found below

[
 {user, [
         {name, "100"},
         {password, "100"},
         {classes, [internal]}
        ]},
 {user, [
         {name, "101"},
         {password, "101"},
         {classes, [internal]}
        ]},

 {address, [
            {user, "100"},
            {address, "sip:[EMAIL PROTECTED]"}
           ]},
 {address, [
            {user, "101"},
            {address, "sip:[EMAIL PROTECTED]"}
           ]}
].

So now, I start XLITE (a free SIP client) and I try to register user 101 to
a.b.com with realm as a.b.com.

I am uploading the incomingproxy.debug file to
http://download.yousendit.com/E40CA0F520676DCC (again valid for 7 days) but
I shall list the gist of the problem below.

1. X-Lite sends REGISTER to proxy.
2. Proxy sends 401 Authentication required (correct, it also mentions the
realm correctly)
3. X-Lite sends the challenge response
4. Proxy returns 500 Server error

In the .debug file, I find the following

2007-08-31 11:12:54.625 error<0.216.0>:=ERROR REPORT==== from SIP message
handler (in sipserver:process()) :
{noproc,{gen_server,call,[sipuserdb_file_backend,{fetch_users}]}}
2007-08-31 11:12:54.626 debug<0.216.0>:Transaction layer: Located server
transaction handler <0.217.0>
2007-08-31 11:12:54.626 error<0.216.0>:=ERROR REPORT==== from
sipserver:process :
{noproc,{gen_server,call,[sipuserdb_file_backend,{fetch_users}]}}
2007-08-31 11:12:54.626 debug<0.217.0>:UAS decision: Requested to send
2/3/4/5/6xx response 500 to REGISTER when in state 'trying' - doing so
(unreliably) and entering state 'completed'

>From the above fragment, I think it fails at
sipuserdb_file_backend,{fetch_users} meaning that it is not able to find the
users file (which is at /var/yxa/userdb) . Should I include the location of
the file so that incomingproxy knows where to look for it ?

I had requested for a step by step configuration eaerlier without being
aware of the instructions in the README (lazy me !) I apologize for that :)

I thank you all in advance.
Warm regards,
Knight

On 8/30/07, Fredrik Thulin <[EMAIL PROTECTED]> wrote:
>
> Knight Tiger wrote:
> > Fredrik,
> >             I thank you for your quick response. I am attaching the log
> file
> > to this email as an attachment (which is why I am sending this one to
> you as
> > well as the mailing list) because the log file is terribly long and I
> dont
> > want to clog all your inbox with it. So I am uploading it to this site,
> > where everyone can access the file for 7 days. (
> > http://download.yousendit.com/A5EAAD662DD27E2F)
>
> Ok, the relevant part of the error log seems to be (near the top) :
>
> 2007-08-29 11:41:08.888 error<0.169.0>:TCP listener: Could not open
> socket - module gen_tcp, proto tcp, port 5060 : eaddrinuse (address alre
> ady in use)
>
> What it says is that TCP port 5060 could not be made listening by the
> YXA server, because something else is already listening there. Are you
> running a soft phone on the same computer perhaps? Or another SIP server?
>
> > Since the functions are invoked recursively, I see the same function
> > repeating over and over in the logs.
>
> It isn't invoked recursively, but repetedly. There is a supervisor
> process that detects that the TCP listener died, and tries restarting
> it. I would agree that there is room for improvements here - when it is
> the initial setup that fails there isn't much point in immediately
> trying again until we decide it is time to bail out after 20 (or some
> other value, don't remember) attempts.
>
> > It is quite possible that I am not
> > doing this right. A step by step configuration example on the website
> would
> > be very helpful.
>
> Perhaps you did not find
>
>    http://www.stacken.kth.se/project/yxa/2phones.html and
>    http://www.stacken.kth.se/project/yxa/simple-site.html
>
> or whas it some other kind of document you had in mind? Both these are
> linked from the documentation tab of the YXA web site.
>
> > I do hope that this log does provide enough detail (I dont know how to
> tweak
> > the log levels yet). I request you all to kindly guide me here.
>
> Of course we will be kind! We were all new to Erlang once, and - well -
> it's error messages aren't exactly the things we have in mind when we
> tell someone what a beautiful programming language Erlang is ;)
>
> /Fredrik
>
_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel

Reply via email to