Hey guys, I’m getting this error message when I try to
compile the PA module:
make[1]: Entering directory `/root/sip-server/modules/pa'
Compiling xpidf.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align
-Wall -minline-all-stringops -malign-double -falign-loops
-mtune=athlon -W
Bogdan-Andrei Iancu writes:
> at the moment I see two options (both involves fixing parse_methods()
> not to return error if string is empty):
> 1) revert to the original approach (allocate extra int)
i don't see allocating a four byte word as a major performance issue and
it provides cle
Bogdan-Andrei Iancu writes:
> if you consider a more appropriate name, please feel free to change
> it...I have no issue with this...it was my first shoot.
ALL_METHODS is fine with me.
-- juha
___
Devel mailing list
Devel@openser.org
http://openser
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
> - defined ALL_METHODS as (0x)
i start to get lost here. in my implementation, all ones value was the
default in case there was not allow header or contact methods, that is,
when supported methods are not known. it is not the same a
at the moment I see two options (both involves fixing parse_methods()
not to return error if string is empty):
1) revert to the original approach (allocate extra int)
2) to avoid 0 value after parsing, use a marking bit (1<<31); so far
only first 15 bits are used to map methods.
regards,
Bogdan-Andrei Iancu writes:
> - defined ALL_METHODS as (0x)
i start to get lost here. in my implementation, all ones value was the
default in case there was not allow header or contact methods, that is,
when supported methods are not known. it is not the same as "all
methods".
-- ju
Bogdan-Andrei Iancu writes:
> 20.5 Allow
>
>The Allow header field lists the set of methods supported by the UA
>generating the message.
if the list is empty, the UA does not support any methods.
> have you found some thing else? ...even so, IMHO the purpose of a
> contact which
User: bogdan_iancu
Date: 2005/12/07 12:00:48 PST
OpenSER CVS - Commit Details
Modified files:
parser parse_methods.h
modules/registrarsave.c
modules/usrloc udomain.c
Commit Log:
- defined ALL_METHODS as (0x)
- optimization: in REGISTER, the
User: bogdan_iancu
Date: 2005/12/07 11:41:05 PST
OpenSER CVS - Commit Details
Modified files:
parser parse_allow.c
Commit Log:
-the missing of Allow hdr must not be logged as error - it's optional
Revision ChangesPath
1.5 +2 -4 sip-server/parser/p
right, the grammar looks to accept an empty body Allow hdrbut I
haven't found any mentions about the meaning of an empty body...just:
20.5 Allow
The Allow header field lists the set of methods supported by the UA
generating the message.
All methods, including ACK and CANCEL, under
Bogdan-Andrei Iancu writes:
> on double thinking, the only confusion may appear between (1) not parsed
> yet and (2) parsed but no method found - header with no
> payload... right?
no. an empty allow header
Allow:
is perfectly legal meaning that the UA doesn't accept any methods.
Allow =
on double thinking, the only confusion may appear between (1) not parsed
yet and (2) parsed but no method found - header with no payload... right?
but case (2) is reported as error by parse_methods()...so isn't not a
real case ;)
I would say there is no problem after all. If the body is succes
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
> speedup and enhancement in parse_allow():
> - the parsed methods (bitmap on unsigned int) in mapped directly
> over "parsed"
how can you then tell difference between unparsed and empty methods?
seams I was to fast in judgement :D...yo
Bogdan-Andrei Iancu writes:
> have updated also the ut.h file? - there is the place where the
> "str_init" macro was added.
i did run cvs update, but perhaps you updated ut.h later than ul_mod.c
and str_init was not yet available in anon cvs ut.h.
-- juha
Bogdan-Andrei Iancu writes:
> speedup and enhancement in parse_allow():
> - the parsed methods (bitmap on unsigned int) in mapped directly
> over "parsed"
how can you then tell difference between unparsed and empty methods?
-- juha
___
Devel
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
> I just finished merging your patch with the latest usrloc/registrar
> changes.
thanks. looks like some include is missing from ul_mod.c:
make[1]: Entering directory `/usr/src/sip-server.head/modules/usrloc'
Compiling ul_mod.c
ul_mod.c:81:
User: bogdan_iancu
Date: 2005/12/07 09:34:14 PST
OpenSER CVS - Commit Details
Modified files:
parser hf.c msg_parser.c parse_allow.c
parse_allow.h
Commit Log:
speedup and enhancement in parse_allow():
- the parsed methods (bitmap on unsigned
Bogdan-Andrei Iancu writes:
> I just finished merging your patch with the latest usrloc/registrar
> changes.
thanks. looks like some include is missing from ul_mod.c:
make[1]: Entering directory `/usr/src/sip-server.head/modules/usrloc'
Compiling ul_mod.c
ul_mod.c:81: warning: implicit decla
User: bogdan_iancu
Date: 2005/12/07 09:12:47 PST
OpenSER CVS - Commit Details
Modified files:
modules/registrarsave.c sip_msg.c sip_msg.h
Commit Log:
- more cleanup and optimization
- proper error messages reported for all error cases
- if max_contacts is exceeded, an INFO is
Bogdan-Andrei Iancu wrote:
Hi Federico,
I'm afraid you have a script error - you called twice some functions
which create transactions...The error is generate most probably by
t_relay() which found the transaction already created in the script
(maybe via t_newtran).
Yes, I know it.
It is th
Federico Giannici wrote:
Bogdan-Andrei Iancu wrote:
Hi Federico,
I'm afraid you have a script error - you called twice some functions
which create transactions...The error is generate most probably by
t_relay() which found the transaction already created in the script
(maybe via t_newtran)
Bugs item #1375370, was opened at 2005-12-07 16:34
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1375370&group_id=139143
Please note that this message will contain a full copy of the c
User: bogdan_iancu
Date: 2005/12/07 07:04:47 PST
OpenSER CVS - Commit Details
Modified files:
modules/unixodbc Makefile list.c
Commit Log:
-missing return added (compiling warning)
-include path added - thanks to Norman Brandinger (closes 1375370)
Revision ChangesPath
Hi Federico,
I'm afraid you have a script error - you called twice some functions
which create transactions...The error is generate most probably by
t_relay() which found the transaction already created in the script
(maybe via t_newtran).
To be able to help, please send the script (privatel
Bugs item #1375370, was opened at 2005-12-07 14:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1375370&group_id=139143
Please note that this message will contain a full copy
User: bogdan_iancu
Date: 2005/12/07 05:54:11 PST
OpenSER CVS - Commit Details
Modified files:
modules/usrloc dlist.c dlist.h ucontact.c ucontact.h
udomain.c urecord.c urecord.h
Commit Log:
DB operations optimized - domain name is kept null terminated -
ok - in this case, the solution will be to keep the patches on the
tracker until all pieces are in place.
regards,
bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
> My question is if we should commit the partial patches or to keep them
> pending until the whole solution is availabl
User: chgen
Date: 2005/12/07 05:16:41 PST
OpenSER CVS - Commit Details
Modified files:
modules/unixodbc list.c
Commit Log:
Return value of insert
Revision ChangesPath
1.3 +6 -5 sip-server/modules/unixodbc/list.c
[
http://cvs.sourceforge.net/viewcvs.p
User: bogdan_iancu
Date: 2005/12/07 05:24:12 PST
OpenSER CVS - Commit Details
Modified files:
.cfg_local.pm
Commit Log:
Marco Lorrai's email address added
Revision ChangesPath
1.11 +2 -1 CVSROOT/cfg_local.pm
[
http://cvs.sourceforge.net/v
Bogdan-Andrei Iancu writes:
> My question is if we should commit the partial patches or to keep them
> pending until the whole solution is available.
partial patch doesn't really help here. i may have time later this week
to rewrite reload_gws to reload_gws_and_routes so that it would remain
I would say this enhancement is welcome.
My question is if we should commit the partial patches or to keep them
pending until the whole solution is available.
regards,
bogdan
Ovidiu Sas wrote:
Hi all,
As Juha mentioned it into the lcr doc (see TODO), the second query
should be rewritten i
Hi Juha,
I just finished merging your patch with the latest usrloc/registrar
changes.
one of the biggest changes was an optimization in case of a register
with multiple contacts - common info (callid, cseq, received, socket,
etc) are calculate only once.
Also I switched TABLE_VERSION to U
User: bogdan_iancu
Date: 2005/12/07 04:43:39 PST
OpenSER CVS - Commit Details
Modified files:
.ut.h
modules/usrloc README dlist.c ucontact.c ucontact.h
udomain.c udomain.h ul_fifo.c ul_mod.c
ul_mod.h ul_uni
enclosed find a patch to openser HEAD rr module that adds optional
parameter to record_route function and allows record_route
function to be called also from branch route block. if parameter is
given, it is added as parameter to RR header field.
-- juha
rr.patch
Description: patch
User: bogdan_iancu
Date: 2005/12/07 03:44:43 PST
OpenSER CVS - Commit Details
Modified files:
.Makefile
Commit Log:
mysql module not to be compiled by default (propably removed by mistake)
Revision ChangesPath
1.12 +2 -2 sip-server/Makefile
Hi Lenir,
the warning is fixed on cvs - please update and retry.
thanks for report,
bogdan
Lenir wrote:
Guys,
I downloaded the most recent version of CVS, I get the following
compilation error, when compiling unixodbc module:
make[1]: Entering directory `/usr/src/sip-server/modules/uni
User: bogdan_iancu
Date: 2005/12/07 03:32:43 PST
OpenSER CVS - Commit Details
Modified files:
modules/unixodbc list.c
Commit Log:
compiling warning fixed - reported by Lenir <[EMAIL PROTECTED]>
Revision ChangesPath
1.2 +4 -4 sip-server/modules/unixodbc/list
37 matches
Mail list logo
