Bogdan-Andrei Iancu writes:
> it was a bug in the fixup function - this was recently inserted with the
> latest changes for script variables. It should be fixed on CVS.
yes, now t_relay("0x01") does not anymore send '100 Trying';
-- juha
___
Devel
Daniel-Constantin Mierla writes:
> - added user escape/unescape trasnformation (credits to Juha
> - Heinanen); closes 1652269
thanks for the escape/unescape transformations. there is a small
performance issue related to them when applied to, for example, request
uri user.
in order to find
Hi,
I got this bizarre 500 error (openser 1.2.0-pre4-tls (arm/linux)).
192.168.2.102 - CISCO IP PHONE
192.168.2.22 - openser
192.168.2.20 - asterisk
Cisco --> openser --> asterisk
Here's the the log:
ERROR:tm:t_forward_nonack: no branch for forwarding
ERROR:tm:w_t_relay: t_forward_nonack fai
Bugs item #1653550, was opened at 2007-02-06 14:38
Message generated for change (Comment added) made by jmagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1653550&group_id=139143
Please note that this message will contain a full copy of the comment t
yup ,,, you are right ... dunno how I came up with $pi.
Thx,
-ovi
On 2/12/07, Daniel-Constantin Mierla <[EMAIL PROTECTED]> wrote:
Hello,
$pi is invalid, if you look for source port it is $sp.
I introduced a check to through error if a non-existent pseudo-variable
is used in the script.
Chee
Hello,
$pi is invalid, if you look for source port it is $sp.
I introduced a check to through error if a non-existent pseudo-variable
is used in the script.
Cheers,
Daniel
On 02/12/07 21:25, Ovidiu Sas wrote:
Hmm ... in openser 1.2.0-pre4-tls I'm no longer able to use $pi:
xl_fill_extra_s
Hmm ... in openser 1.2.0-pre4-tls I'm no longer able to use $pi:
xl_fill_extra_spec: extra item [pi] not found
xl_lookup_spec_name: not found PV [pi]
ERROR:xl_parse_spec: error searching pvar "pi"
On 2/12/07, Ovidiu Sas <[EMAIL PROTECTED]> wrote:
Hi,
While printing the source port ($pi) for a
Bugs item #1658305, was opened at 2007-02-12 19:07
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=1658305&group_id=139143
Please note that this message will contain a full copy
Hi Bogdan,
The fix works ok =) Thx.
The fix for bug 1653550 will come soon.
I will keep you updated.
Regards,
Ovidiu Sas
On 2/12/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote:
Hi Ovidiu,
the suggested fix is on the cvs - please test and let me know if there
are any other issues.
Could yo
Hi Ovidiu,
the suggested fix is on the cvs - please test and let me know if there
are any other issues.
Could you also please take a look on the 1653550 ?
regards,
bogdan
Ovidiu Sas wrote:
Hi Bogdan,
I think this is a viable solution.
And thank you for you time. I know that this is not a b
Bugs item #1653539, was opened at 2007-02-06 21:18
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1653539&group_id=139143
Please note that this message will contain a full copy of the comm
User: bogdan_iancu
Date: 2007/02/12 10:17:06 PST
OpenSER CVS - Commit Details
Modified files:
.Makefile Makefile.defs
modules/cpl-cMakefile
modules/dialog dlg_handlers.c
modules/mi_xmlrpcMakefile
modules/mysqlMakefile db_mo
Bugs item #1637284, was opened at 2007-01-17 01:13
Message generated for change (Comment added) made by amr42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1637284&group_id=139143
Please note that this message will contain a full copy of the comment thr
Patches item #1652269, was opened at 2007-02-05 12:11
Message generated for change (Comment added) made by miconda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1652269&group_id=139143
Please note that this message will contain a full copy of the commen
User: miconda
Date: 2007/02/12 10:12:47 PST
OpenSER CVS - Commit Details
Modified files:
.Makefile.defs items.c items_extra.c
sr_module.c strcommon.c strcommon.h
transformations.c transformations.h ut.h
Commit Log
Patches item #1658264, was opened at 2007-02-12 20:05
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1658264&group_id=139143
Please note that this message will contain a full copy of the c
Patches item #1658264, was opened at 2007-02-12 18:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1658264&group_id=139143
Please note that this message will contain a full co
User: bogdan_iancu
Date: 2007/02/12 09:32:45 PST
OpenSER CVS - Commit Details
Modified files:
.blacklists.c
Commit Log:
- usleep() replaced with the portable sleep_us (internally defined)
Revision ChangesPath
1.2 +9 -9 sip-server/blacklists.
User: bastian
Date: 2007/02/12 08:24:59 PST
OpenSER CVS - Commit Details
Modified files:
db db.c
Commit Log:
Fixing minor typo ("quries" -> "queries") during an error logging
Revision ChangesPath
1.7 +2 -2 sip-server/db/db.c
[
http://open
Brilliant!
Thanx for getting this in.
I'm assuming that y'all managed to work around the synchronization issues.
again - brilliant!
cheers
- Original Message -
From: Bogdan-Andrei Iancu <[EMAIL PROTECTED]>
To: users openser.org , devel
Sent: Friday, February 9, 2007 10:27:29 AM GMT-060
Hi,
While printing the source port ($pi) for a received message from port
5060, I got the following log (debug=3):
xl_get_spec_value: error - null sp->itf
This log is missleading and it should be removed (the default port
5060 should be filled in).
Regards,
Ovidiu Sas
___
User: miconda
Date: 2007/02/12 06:26:12 PST
OpenSER CVS - Commit Details
Modified files:
modules/usrloc urecord.c usrloc.c
Commit Log:
- initialize returned contact to NULL in get_ucontact. In case of not found
the function return 1 and the other functions do not check it (cr
Hi Bogdan,
Yes, uac_replace_from will do the trick, but it will complicate the script.
Can we, by default, blank the display name while in "auto" mode?
Or add a new mode/param that will control this?
Regards,
Ovidiu Sas
On 2/12/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote:
Hi Ovidiu,
n
Hello,
indeed, a consistent format should be chosen. While the seond format
might be more appropriate for the moment, since the name of the
parameter clearly states is avp, the first gives more flexibility in
long term (e.g., could be used with transformations or maybe script
variables would
Patches item #1658042, was opened at 2007-02-12 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1658042&group_id=139143
Please note that this message will contain a full co
Hi,
this is the result of a race between the outgoing reply (confirming the
dialog) and an incoming sequential request.
The TM callback for outgoing replies is called after the send itself is
done and it is possible that in the mean while another process to
already process a sequential reque
Bugs item #1657899, was opened at 2007-02-12 12:38
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=1657899&group_id=139143
Please note that this message will contain a full copy
Hi Klaus,
this issue is documented in the TM readme - see the link to the TM
parameter.
regards,
bogdan
Klaus Darilion wrote:
Great! Are there performance issues due to the locking in the reply
route?
regards
klaus
Bogdan-Andrei Iancu wrote:
Hi everybody,
The ability of accessing/proces
Hi Ovidiu,
no, the display name is not restorable because: 1) is it not transaction
critical element, 2) usually is it used only in original request and 3)
more info in RR would be required for restoring it also.
you can use uac_replace_from :
# remove display and do not touch uri
uac_re
Hi Juha,
it was a bug in the fixup function - this was recently inserted with the
latest changes for script variables. It should be fixed on CVS.
Thanks for report,
Bogdan
Juha Heinanen wrote:
i tested the new t_relay 100 trying flag as:
if (!t_relay("0x01")) {
but it still generat
User: bogdan_iancu
Date: 2007/02/12 02:51:42 PST
OpenSER CVS - Commit Details
Modified files:
modules/tm tm.c
Commit Log:
- fixed the movment of paarmeter from pos 1 to pos 2 in fixup function. The
original approach got broken during the latest changes related to script
Great! Are there performance issues due to the locking in the reply route?
regards
klaus
Bogdan-Andrei Iancu wrote:
Hi everybody,
The ability of accessing/processing AVPs in reply route was a long
debated and wanted functionality. Finally, OpenSER 1.2.x fixes this.
The new code allows two t
32 matches
Mail list logo