[OpenSIPS-Devel] [ opensips-Patches-2223501 ] maxfwd module - internal corruption
Patches item #2223501, was opened at 2008-11-05 04:57 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2223501&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: reticent (unspin) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: maxfwd module - internal corruption Initial Comment: The issue occurs when calling 'mf_process_maxfwd_header' or 'is_maxfwd_lt' script functions more than once within a single script execution The second occurrence always returns as if the max forward header value has reached zero due to an issue with the temporary value (max forwards count) stored by the module being overwritten with zero during an int to string conversion We are calling it more than once during a single execution to detect and trap possible call forwarding loops between accounts Cheers! Credits to: Peter Baer (pbaer at galaxytelecom dot net) Tavis Paquette (tavis at galaxytelecom dot net) -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-10 18:27 Message: Hi, I do not see how this patch solves something - you have the mf header body and trim it in a foo variable which is not used - it returns the value stored into "parsed" value. maybe something is missing me :).. Regards, Bogdan -- Comment By: reticent (unspin) Date: 2008-11-08 06:53 Message: Heres an additional patch for maxfwd, this fixes the segmentation fault we came across -- Comment By: reticent (unspin) Date: 2008-11-06 02:53 Message: We've found a rather serious problem (seg fault) but we havn't tracked it down completely We suspect the issue is related to maxfwd overwriting the pointer to the max-forward value in the sip-msg with an integer. Where before it was always zero, which would be treated as a null pointer (potentially causing a problem when TM interacts with that pointer), but we havn't had the chance to prove this theory yet We're right in the middle of a deployment so we can't work on this issue right away, but we'll have somthing definitive for you by next week -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-05 15:29 Message: OK - a fix (different approach on the problem) is now available in SVN trunk - please test and let me know if ok or not. If ok, I will do the backport on 1.4 Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-05 15:24 Message: Hi, yes, you are definitely right - the value should be first saved in the parsed hook and than written into message. Regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2223501&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2223501 ] maxfwd module - internal corruption
Patches item #2223501, was opened at 2008-11-05 04:57 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2223501&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: reticent (unspin) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: maxfwd module - internal corruption Initial Comment: The issue occurs when calling 'mf_process_maxfwd_header' or 'is_maxfwd_lt' script functions more than once within a single script execution The second occurrence always returns as if the max forward header value has reached zero due to an issue with the temporary value (max forwards count) stored by the module being overwritten with zero during an int to string conversion We are calling it more than once during a single execution to detect and trap possible call forwarding loops between accounts Cheers! Credits to: Peter Baer (pbaer at galaxytelecom dot net) Tavis Paquette (tavis at galaxytelecom dot net) -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-10 19:09 Message: I've spoken too soon - I see your case when 'mf_process_maxfwd_header' is called twice in the script - I uploaded the fixes (from this report) on SVN trunk and 1.4. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-10 18:27 Message: Hi, I do not see how this patch solves something - you have the mf header body and trim it in a foo variable which is not used - it returns the value stored into "parsed" value. maybe something is missing me :).. Regards, Bogdan -- Comment By: reticent (unspin) Date: 2008-11-08 06:53 Message: Heres an additional patch for maxfwd, this fixes the segmentation fault we came across -- Comment By: reticent (unspin) Date: 2008-11-06 02:53 Message: We've found a rather serious problem (seg fault) but we havn't tracked it down completely We suspect the issue is related to maxfwd overwriting the pointer to the max-forward value in the sip-msg with an integer. Where before it was always zero, which would be treated as a null pointer (potentially causing a problem when TM interacts with that pointer), but we havn't had the chance to prove this theory yet We're right in the middle of a deployment so we can't work on this issue right away, but we'll have somthing definitive for you by next week -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-05 15:29 Message: OK - a fix (different approach on the problem) is now available in SVN trunk - please test and let me know if ok or not. If ok, I will do the backport on 1.4 Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-05 15:24 Message: Hi, yes, you are definitely right - the value should be first saved in the parsed hook and than written into message. Regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2223501&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-05 22:43
Message generated for change (Comment added) made by rrevels
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
parsed_uri = {user = {s = 0x34476839 ,
len = 84434}, passwd = {s = 0x34353865 , len = 1916483894},
host = {s = 0x74726f70 , len =
909129021}, port = {s = 0x460a0d30 , len
= 980250482}, params = {
s = 0x73612220 , len =
1769104756}, headers = {s = 0x20226b73 ,
len = 1885958972}, port_no = 24890,
proto = 29811, type = 1936290405, transport = {s = 0x3736406b , len = 842346798}, ttl = {s = 0x3934322e ,
len = 1043346222}, user_param = {s = 0x6761743b , len = 896753981}, maddr = {s = 0x62323339 ,
len = 221591651}, method = {s = 0x3a6f540a , len = 1769159712}, lr = {s = 0x31323a70 ,
len = 842542646}, r2 = {s = 0x3532322e , len = 892547630}, transport_val = {s = 0x61743b3e ,
len = 808533351}, ttl_val = {s = 0x61306665 , len = 1680959076}, user_param_val = {s = 0x64633732 ,
len = 1664495718}, maddr_val = {s = 0x38656461 , len = 879112754}, method_val = {s = 0x36343939 ,
len = 942564405}, lr_val = {s = 0xd313864 , len = 1818313482}, r2_val = {s = 0x44492d6c ,
len = 1697914938}}, param_lst = 0x30396334, last_param = 0x39336434}
--
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-06 15:40
Message:
Turned debug up to 6 for a while. Here is a partial log output showing the
process id startup and first few lines from the last time opensips core
dumped.
[EMAIL PROTECTED] opensips]# grep 14: /var/log/opensips.log | grep 17235
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=usrloc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=tm
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:tm:child_init_callid: callid: '[EMAIL PROTECTED]'
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=registrar
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=xlog
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:xlog:child_init: init_child [-4] pid [17235]
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=acc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=avpops
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=permissions
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=dispatcher
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:dispatcher:child_init: #-4 / pid <17235>
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/
[OpenSIPS-Devel] [ opensips-Bugs-2262249 ] Small mistake in pua_usrloc documentation
Bugs item #2262249, was opened at 2008-11-11 07:54
Message generated for change (Comment added) made by saguti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
Assigned to: Sergio Gutierrez (saguti)
Summary: Small mistake in pua_usrloc documentation
Initial Comment:
Hi,
a small mistake in pua_usrloc documentation - bad for copy/pasters like me :-)
See http://www.opensips.org/html/docs/modules/1.4.x/pua_usrloc.html#id2525562
For both exported module parameters, the module name is not enclosed in quotes.
e.g. modparam(pua_usrloc, "default_domain", "opensips.org")
should be modparam("pua_usrloc", "default_domain", "opensips.org")
Regards
Sebastian
--
Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-11 08:40
Message:
Fixed. Thanks a lot for reporting.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2262249 ] Small mistake in pua_usrloc documentation
Bugs item #2262249, was opened at 2008-11-11 07:54
Message generated for change (Settings changed) made by saguti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
Assigned to: Sergio Gutierrez (saguti)
Summary: Small mistake in pua_usrloc documentation
Initial Comment:
Hi,
a small mistake in pua_usrloc documentation - bad for copy/pasters like me :-)
See http://www.opensips.org/html/docs/modules/1.4.x/pua_usrloc.html#id2525562
For both exported module parameters, the module name is not enclosed in quotes.
e.g. modparam(pua_usrloc, "default_domain", "opensips.org")
should be modparam("pua_usrloc", "default_domain", "opensips.org")
Regards
Sebastian
--
Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-11 08:40
Message:
Fixed. Thanks a lot for reporting.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2264067 ] Ambiguous return and possible memory leak
Patches item #2264067, was opened at 2008-11-11 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Nobody/Anonymous (nobody) Summary: Ambiguous return and possible memory leak Initial Comment: There is an ambiguity in return value within exec module, and a possible memory leak for not adequate memory free. The patch fixes both. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2262249 ] Small mistake in pua_usrloc documentation
Bugs item #2262249, was opened at 2008-11-11 13:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Small mistake in pua_usrloc documentation
Initial Comment:
Hi,
a small mistake in pua_usrloc documentation - bad for copy/pasters like me :-)
See http://www.opensips.org/html/docs/modules/1.4.x/pua_usrloc.html#id2525562
For both exported module parameters, the module name is not enclosed in quotes.
e.g. modparam(pua_usrloc, "default_domain", "opensips.org")
should be modparam("pua_usrloc", "default_domain", "opensips.org")
Regards
Sebastian
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2262249 ] Small mistake in pua_usrloc documentation
Bugs item #2262249, was opened at 2008-11-11 14:54
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
>Assigned to: Sergio Gutierrez (saguti)
Summary: Small mistake in pua_usrloc documentation
Initial Comment:
Hi,
a small mistake in pua_usrloc documentation - bad for copy/pasters like me :-)
See http://www.opensips.org/html/docs/modules/1.4.x/pua_usrloc.html#id2525562
For both exported module parameters, the module name is not enclosed in quotes.
e.g. modparam(pua_usrloc, "default_domain", "opensips.org")
should be modparam("pua_usrloc", "default_domain", "opensips.org")
Regards
Sebastian
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2105366 ] a patch that reads an environment variable to an avp
Patches item #2105366, was opened at 2008-09-11 12:56
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2105366&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Dror Wald (dror_wald)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: a patch that reads an environment variable to an avp
Initial Comment:
I've made a patch in exec module (based on exec_avp code) that enables to read
an environment variable and put its value inside an avp.
For example,
exec_getenv("HOSTNAME",$avp(s:hostname));
Gets the value of environment variable HOSTNAME and put it in $avp(s:hostname).
--
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-11 16:23
Message:
Thanks - I uploaded the patch on the SVN. Thank you.
Best regards,
Bogdan
--
Comment By: Dror Wald (dror_wald)
Date: 2008-11-06 17:17
Message:
I've reloaded the files with unified diff.
--
Comment By: Dror Wald (dror_wald)
Date: 2008-11-06 17:15
Message:
File Added: README.diff
--
Comment By: Dror Wald (dror_wald)
Date: 2008-11-06 17:14
Message:
File Added: exec_mod.c.diff
--
Comment By: Dror Wald (dror_wald)
Date: 2008-11-06 17:11
Message:
File Added: exec.c.diff
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-03 15:56
Message:
Hi there,
Thanks for the patch - the functionality looks good and I'm ready to
commit it, but you need to regenerate the patch with the following
changes:
1) make a unified diff
2) include the documentation for the new function.
(modules/exec/doc/exec_admin.xml).
--
Comment By: Dror Wald (dror_wald)
Date: 2008-09-11 12:59
Message:
File Added: exec_mod.c.diff
--
Comment By: Dror Wald (dror_wald)
Date: 2008-09-11 12:57
Message:
File Added: exec.c.diff
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2105366&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-05 22:43
Message generated for change (Comment added) made by rrevels
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
parsed_uri = {user = {s = 0x34476839 ,
len = 84434}, passwd = {s = 0x34353865 , len = 1916483894},
host = {s = 0x74726f70 , len =
909129021}, port = {s = 0x460a0d30 , len
= 980250482}, params = {
s = 0x73612220 , len =
1769104756}, headers = {s = 0x20226b73 ,
len = 1885958972}, port_no = 24890,
proto = 29811, type = 1936290405, transport = {s = 0x3736406b , len = 842346798}, ttl = {s = 0x3934322e ,
len = 1043346222}, user_param = {s = 0x6761743b , len = 896753981}, maddr = {s = 0x62323339 ,
len = 221591651}, method = {s = 0x3a6f540a , len = 1769159712}, lr = {s = 0x31323a70 ,
len = 842542646}, r2 = {s = 0x3532322e , len = 892547630}, transport_val = {s = 0x61743b3e ,
len = 808533351}, ttl_val = {s = 0x61306665 , len = 1680959076}, user_param_val = {s = 0x64633732 ,
len = 1664495718}, maddr_val = {s = 0x38656461 , len = 879112754}, method_val = {s = 0x36343939 ,
len = 942564405}, lr_val = {s = 0xd313864 , len = 1818313482}, r2_val = {s = 0x44492d6c ,
len = 1697914938}}, param_lst = 0x30396334, last_param = 0x39336434}
--
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-06 15:40
Message:
Turned debug up to 6 for a while. Here is a partial log output showing the
process id startup and first few lines from the last time opensips core
dumped.
[EMAIL PROTECTED] opensips]# grep 14: /var/log/opensips.log | grep 17235
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=usrloc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=tm
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:tm:child_init_callid: callid: '[EMAIL PROTECTED]'
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=registrar
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=xlog
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:xlog:child_init: init_child [-4] pid [17235]
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=acc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=avpops
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=permissions
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=dispatcher
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:dispatcher:child_init: #-4 / pid <17235>
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/
[OpenSIPS-Devel] [ opensips-Patches-2264067 ] Ambiguous return and possible memory leak
Patches item #2264067, was opened at 2008-11-11 21:02 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules >Group: trunk Status: Open >Resolution: Invalid Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Ambiguous return and possible memory leak Initial Comment: There is an ambiguity in return value within exec module, and a possible memory leak for not adequate memory free. The patch fixes both. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-12 19:21 Message: Hi Sergio, I do not see the leak - the original code looks safe to me - if there is a case where you spoted a possible leak, please describe the case (the flow in the function). Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2264067 ] Ambiguous return and possible memory leak
Patches item #2264067, was opened at 2008-11-11 14:02 Message generated for change (Comment added) made by saguti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Ambiguous return and possible memory leak Initial Comment: There is an ambiguity in return value within exec module, and a possible memory leak for not adequate memory free. The patch fixes both. -- Comment By: Sergio Gutierrez (saguti) Date: 2008-11-12 12:32 Message: Hi Bogdan. As I see: line 112, at exec_str: Memory is allocated. line 136, at exec_str: If pipe cannot be opened, goes to error01, memory is freed, but return is missed. line 160, at exec_str: If there is error reading uri (fgets within while), goes to error02, which only has return ret; line 165, at exec_str: If there is error appending branch, goes to error02, which only has return ret; line 172, at exec_str: If message has no from uri, goes to error02, which onlye has return ret; Block defined by error02 does not have memory freeing. Does the program continue through error01 and error00? Regards. Sergio. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-12 12:21 Message: Hi Sergio, I do not see the leak - the original code looks safe to me - if there is a case where you spoted a possible leak, please describe the case (the flow in the function). Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Bugs item #2274274, was opened at 2008-11-12 22:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brent (brent_thomson) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault in db_postgres Initial Comment: Partial output: *** glibc detected *** opensips: free(): invalid next size (fast): 0x01166c70 *** === Backtrace: = /lib64/libc.so.6[0x2b92149b8684] /lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc] /usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819] /usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df] opensips(db_do_query+0x335)[0x4b0da1] /usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1] /usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8] opensips(do_action+0x24d4)[0x410de0] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x44d7aa] opensips(eval_expr+0xc8)[0x451633] opensips(eval_expr+0x1ac)[0x451717] opensips(eval_expr+0x1e0)[0x45174b] opensips(do_action+0x1caf)[0x4105bb] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(do_action+0x103b)[0x40f947] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(run_top_route+0x61)[0x40e526] opensips(receive_msg+0x51f)[0x445da6] opensips(udp_rcv_loop+0x45c)[0x47af5b] opensips[0x4219ad] opensips(main+0x1c74)[0x423ccf] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4] opensips[0x40e119] CentOS 5.2 OpenSIPS: latest from svn (about an hour ago) PostgreSQL libs: 8.3.4 (built against the same) DB in writeback mode Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem. The core dump is too large to attach so I've posted it here: http://www.sendspace.com/file/1pv989 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2264067 ] Ambiguous return and possible memory leak
Patches item #2264067, was opened at 2008-11-11 21:02 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Ambiguous return and possible memory leak Initial Comment: There is an ambiguity in return value within exec module, and a possible memory leak for not adequate memory free. The patch fixes both. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-13 11:07 Message: Hi Sergio, > line 136, at exec_str: If pipe cannot be opened, goes to error01, memory is freed, but return is missed. There is a return there - the one from error00; the code is set (default) ret=-1 at the beginning - this is ok here. > line 160, at exec_str: If there is error reading uri (fgets within while),goes to error02, which only has return ret; Yes, and ret is preset to -1; also mem is freed in error01 > line 165, at exec_str: If there is error appending branch, goes to error02, which only has return ret; Same as above > line 172, at exec_str: If message has no from uri, goes to error02, which onlye has return ret; Same as above. Regards, Bogdan -- Comment By: Sergio Gutierrez (saguti) Date: 2008-11-12 19:32 Message: Hi Bogdan. As I see: line 112, at exec_str: Memory is allocated. line 136, at exec_str: If pipe cannot be opened, goes to error01, memory is freed, but return is missed. line 160, at exec_str: If there is error reading uri (fgets within while), goes to error02, which only has return ret; line 165, at exec_str: If there is error appending branch, goes to error02, which only has return ret; line 172, at exec_str: If message has no from uri, goes to error02, which onlye has return ret; Block defined by error02 does not have memory freeing. Does the program continue through error01 and error00? Regards. Sergio. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-12 19:21 Message: Hi Sergio, I do not see the leak - the original code looks safe to me - if there is a case where you spoted a possible leak, please describe the case (the flow in the function). Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-06 00:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
>Group: trunk
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-13 11:20
Message:
Hi Richard,
I'm investigating the initial crash you reported (on reply time). First
question - which of the following modules are you using: nat_traversal,
UAC, siptrace, acc, osp..
The crash happens on the TMCB_RESPONSE_IN callback (in TM) and only the
above modules are using this callback.
Regards,
Bogdan
--
Comment By: Richard Revels (rrevels)
Date: 2008-11-12 17:14
Message:
Initial indications are that when I compile with
#define PKG_MEM_POOL_SIZE 1024*4068
I don't get the core dumps.
When I compile with
#define PKG_MEM_POOL_SIZE 1024*9216
I get lots of them. I am running at about 1 call per second which is the
same load the system was at when it was dumping on a regular basis. The
other change is that I am running with command line option -m 256 vs -m 512
but I suspect the pkg memory change is the significant one.
-rw--- 1 root root 547639296 Nov 9 15:03 core.32127
-rw--- 1 root root 547602432 Nov 9 15:14 core.5279
-rw--- 1 root root 547745792 Nov 9 21:00 core.7677
-rw--- 1 root root 547614720 Nov 9 22:59 core.22886
-rw--- 1 root root 547745792 Nov 10 19:36 core.18281
-rw--- 1 root root 547655680 Nov 11 06:18 core.15740
-rw--- 1 root root 547749888 Nov 11 19:16 core.4572
-rw--- 1 root root 547745792 Nov 11 21:28 core.22289
-rw--- 1 root root 547614720 Nov 11 21:50 core.21091
-rw--- 1 root root 547614720 Nov 11 22:21 core.25760
-rw--- 1 root root 547614720 Nov 11 22:33 core.310
-rw--- 1 root root 547610624 Nov 11 23:07 core.3837
-rw--- 1 root root 547614720 Nov 12 01:05 core.10964
--
Comment By: Richard Revels (rrevels)
Date: 2008-11-11 14:13
Message:
This seems consistent in 50 to 60 percent of the core files. Looks like
there are two scenarios causing the crashes. One when replies arrive and
the other on initial invites. This is from a reply arriving and the
sequence of the function calls in the backtrace match the backtrace used to
open the bug report.
(gdb) print tb
$1 = (struct to_body *) 0x820a9d8
(gdb) print *tb
$2 = {error = 808333871, body = {s = 0x5044552f , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
parsed_uri = {user = {s = 0x34476839 ,
len = 84434}, passwd = {s = 0x34353865 , len = 1916483894},
host = {s = 0x74726f70 , len =
909129021}, port = {s = 0x460a0d30 , len
= 980250482}, params = {
s = 0x73612220 , len =
1769104756}, headers = {s = 0x20226b73 ,
len = 1885958972}, port_no = 24890,
proto = 29811, type = 1936290405, transport = {s = 0x3736406b , len = 842346798}, ttl = {s = 0x3934322e ,
len = 1043346222}, user_param = {s = 0x6761743b , len = 896753981}, maddr = {s = 0x62323339 ,
len = 221591651}, method = {s = 0x3a6f540a , len = 1769159712}, lr = {s = 0x31323a70 ,
len = 842542646}, r2 = {s = 0x3532322e , len = 892547630},
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-05 22:43
Message generated for change (Comment added) made by rrevels
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
parsed_uri = {user = {s = 0x34476839 ,
len = 84434}, passwd = {s = 0x34353865 , len = 1916483894},
host = {s = 0x74726f70 , len =
909129021}, port = {s = 0x460a0d30 , len
= 980250482}, params = {
s = 0x73612220 , len =
1769104756}, headers = {s = 0x20226b73 ,
len = 1885958972}, port_no = 24890,
proto = 29811, type = 1936290405, transport = {s = 0x3736406b , len = 842346798}, ttl = {s = 0x3934322e ,
len = 1043346222}, user_param = {s = 0x6761743b , len = 896753981}, maddr = {s = 0x62323339 ,
len = 221591651}, method = {s = 0x3a6f540a , len = 1769159712}, lr = {s = 0x31323a70 ,
len = 842542646}, r2 = {s = 0x3532322e , len = 892547630}, transport_val = {s = 0x61743b3e ,
len = 808533351}, ttl_val = {s = 0x61306665 , len = 1680959076}, user_param_val = {s = 0x64633732 ,
len = 1664495718}, maddr_val = {s = 0x38656461 , len = 879112754}, method_val = {s = 0x36343939 ,
len = 942564405}, lr_val = {s = 0xd313864 , len = 1818313482}, r2_val = {s = 0x44492d6c ,
len = 1697914938}}, param_lst = 0x30396334, last_param = 0x39336434}
--
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-06 15:40
Message:
Turned debug up to 6 for a while. Here is a partial log output showing the
process id startup and first few lines from the last time opensips core
dumped.
[EMAIL PROTECTED] opensips]# grep 14: /var/log/opensips.log | grep 17235
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=usrloc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=tm
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:tm:child_init_callid: callid: '[EMAIL PROTECTED]'
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=registrar
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=xlog
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:xlog:child_init: init_child [-4] pid [17235]
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=acc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=avpops
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=permissions
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=dispatcher
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:dispatcher:child_init: #-4 / pid <17235>
Nov 6 14:45:33 si
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-06 00:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-13 15:39
Message:
OK- acc module...
I guess you have some extra_accounting parameterscould you list them?
Bogdan
--
Comment By: Richard Revels (rrevels)
Date: 2008-11-13 15:33
Message:
Yeah, that whole pkg memory thing didn't stop the crashes after all.
I am using acc. I am also running with the account early media flag off
because I was crashing with it on. When I turned it off this started
popping up and I wanted to deal with one problem at a time, so left it off.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-13 11:20
Message:
Hi Richard,
I'm investigating the initial crash you reported (on reply time). First
question - which of the following modules are you using: nat_traversal,
UAC, siptrace, acc, osp..
The crash happens on the TMCB_RESPONSE_IN callback (in TM) and only the
above modules are using this callback.
Regards,
Bogdan
--
Comment By: Richard Revels (rrevels)
Date: 2008-11-12 17:14
Message:
Initial indications are that when I compile with
#define PKG_MEM_POOL_SIZE 1024*4068
I don't get the core dumps.
When I compile with
#define PKG_MEM_POOL_SIZE 1024*9216
I get lots of them. I am running at about 1 call per second which is the
same load the system was at when it was dumping on a regular basis. The
other change is that I am running with command line option -m 256 vs -m 512
but I suspect the pkg memory change is the significant one.
-rw--- 1 root root 547639296 Nov 9 15:03 core.32127
-rw--- 1 root root 547602432 Nov 9 15:14 core.5279
-rw--- 1 root root 547745792 Nov 9 21:00 core.7677
-rw--- 1 root root 547614720 Nov 9 22:59 core.22886
-rw--- 1 root root 547745792 Nov 10 19:36 core.18281
-rw--- 1 root root 547655680 Nov 11 06:18 core.15740
-rw--- 1 root root 547749888 Nov 11 19:16 core.4572
-rw--- 1 root root 547745792 Nov 11 21:28 core.22289
-rw--- 1 root root 547614720 Nov 11 21:50 core.21091
-rw--- 1 root root 547614720 Nov 11 22:21 core.25760
-rw--- 1 root root 547614720 Nov 11 22:33 core.310
-rw--- 1 root root 547610624 Nov 11 23:07 core.3837
-rw--- 1 root root 547614720 Nov 12 01:05 core.10964
--
Comment By: Richard Revels (rrevels)
Date: 2008-11-11 14:13
Message:
This seems consistent in 50 to 60 percent of the core files. Looks like
there are two scenarios causing the crashes. One when replies arrive and
the other on initial invites. This is from a reply arriving and the
sequence of the function calls in the backtrace match the backtrace used to
open the bug report.
(gdb) print tb
$1 = (struct to_body *) 0x820a9d8
(gdb) print *tb
$2 = {error = 808333871, body = {s = 0x5044552f , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
pars
[OpenSIPS-Devel] [ opensips-Bugs-2204065 ] "strncmp" should not be used to match parameters, SDP...
Bugs item #2204065, was opened at 2008-10-28 15:06
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2204065&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
>Assigned to: Sergio Gutierrez (saguti)
Summary: "strncmp" should not be used to match parameters, SDP...
Initial Comment:
The following code lines use case sensitive comparisions while most of them try
to match SIP parameters or SDP attributes, that whould be case insenstive per
SIP syntax:
modules/msilo/msilo.c: if(!ctaddr.s || ctaddr.len < 6 ||
strncmp(ctaddr.s, "sip:", 4)
modules/pua_bla/notify.c: if(strncmp(sep+1, "expires=",
8)!= 0)
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(line.s, "sendrecv",
8)==0 || strncmp(line.s, "sendonly", 8)==0 ||
modules/mediaproxy/mediaproxy.c:strncmp(line.s, "recvonly",
8)==0 || strncmp(line.s, "inactive", 8)==0) {
modules/rls/subscribe.c:if(ev_param->name.len== 2 &&
strncmp(ev_param->name.s, "id", 2)== 0)
modules/rls/subscribe.c:if(strncmp(hdr->body.s+ i,
"eventlist", 9)== 0)
modules/rls/resource_notify.c: if(strncmp(smc+1, "reason=", 7))
modules/rls/resource_notify.c: if(strncmp(smc+1, "expires=", 8))
modules/uri/checks.c: if (strncmp(ruri->s, "tel:", 4) != 0) return 1;
modules/pua/hash.h:if (strncmp(event->s, "presence", 8) == 0)
modules/pua/hash.h:if (strncmp(event->s, "xcap-diff", 9) == 0)
modules/pua/hash.h:if (strncmp(event->s, "dialog;sla", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "conference", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "presence;winfo", 14) == 0)
modules/pua/hash.h:if (strncmp(event->s, "message-summary", 15) ==
0)
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence",8 )==0))
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence.winfo",14 )==0))
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/pua_xmpp/simple2xmpp.c:
if(strncmp(hdr->body.s+11,"reason=timeout", 14)== 0)
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/uac/auth_hdr.c: if(val.len>=4 &&
!strncmp(val.s, "auth", 4))
modules/xmpp/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],""",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"'",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/presence_mwi/add_events.c:if (strncmp(body.s, "Messages-Waiting",
16) != 0) goto err;
modules/presence_mwi/add_events.c:if (strncmp(at, "yes", 3) == 0) at = at +
3;
modules/presence_mwi/add_events.c: if (strncmp(at, "no", 2) == 0) at = at
+ 2;
modules/imc/imc_cmd.c: if(cmd->param[0].len<4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/imc/imc_cmd.c: if(cmd->param[0].len<=4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/speeddial/sdlookup.c: if(user_s.len<4 || strncmp(user_s.s, "sip:", 4))
modules/jabber/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],""",6)==0) {
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],"'",6)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/nathelper/nathelper.c: if (strncmp(pnode->rn_address, "udp:",
4) == 0) {
modules/presence/subscribe.c: if(ev_param->name.len== 2 &&
[OpenSIPS-Devel] [ opensips-Feature Requests-2209720 ] Remove "reply_to_via" since it's anti RFC 3261
Feature Requests item #2209720, was opened at 2008-10-30 14:54 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2209720&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Remove "reply_to_via" since it's anti RFC 3261 Initial Comment: "reply_to_via=1" forces replies being sent to the IP in the Via sent-by field, even if the Via header contains a parameter "received". This is not RFC 3261 compliant since replies must be always sent to the "received" address when present (and to the port indicated in sent-by field if rport is not present). So this option would be useful prior to RFC 3261, but not now. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2209720&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2186836 ] PUA_BLA fails for UA's registered behind NAT
Bugs item #2186836, was opened at 2008-10-22 16:26 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2186836&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) >Assigned to: Anca Vamanu (anca_vamanu) Summary: PUA_BLA fails for UA's registered behind NAT Initial Comment: I'm trying PUA_BLA with phones behind NAT. When the REGISTER arrives I do "fix_nated_register()" so the original Contact: Contact: becomes: Contact: After that I do "bla_set_flag()" so PUA_BLA generates a SUBSCRIBE that should arrive to the UA, but PUA_BLA generates it: SUBSCRIBE sip:[EMAIL PROTECTED]:5060 So this SUBSCRIBE will never arrive to the UAC since it's a private IP. The SUBSCRIBE should be sent to the "received" parameter (added before) but I don't know how to achieve it. A dirty workaround is doing "fix_natted_contact()" before "bla_set_flag()" but this is a bad idea since it will change the stored Contact URI in "location" table (and normally UA's need to see their same private IP in the RURI of requests sent from the proxy). As a suggestion, PUA_BLA should take in account the "received" parameter added in Contact during registration to send the SUBSCRIBE. -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-10-22 16:43 Message: Thanks a lot, I'll try it ASAP and comment here the result. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-10-22 16:31 Message: Hi Inaki, I have just commited a fix for this. Please test and let me know if it works. regards, Anca Vamanu -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2186836&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-2207165 ] Dialog:dlg_end_dlg and direction for extra headers
Feature Requests item #2207165, was opened at 2008-10-29 13:41
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2207165&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Dialog:dlg_end_dlg and direction for extra headers
Initial Comment:
Hi!
It could be very nice of dlg_end_dlg will be able to send extra headers only to
the chosen direction ("downstream","upstream","both"). Currently extra headers
sent to both directions.
Best Regards,
Alex Massover
--
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-14 11:32
Message:
Hi,
yes, this will be an idea - please open a separate request for that. This
one will be closed.
Best regards,
Bogdan
--
Comment By: Alex Massover (cupotka2008)
Date: 2008-10-30 17:06
Message:
Hi!
This is good idea, thanks! I fought that local_route is only in a roadmap,
didn't notice that it's already available. I already started to use it for
accounting.
I have another idea for direction. Unfortunately is_direction() from RR
module is not available in local_route. What do you think to implement
is_direction() in dialog module (based of tags)? It can easily and more
reliably detect direction of requests and will be available for every route
type.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-30 15:46
Message:
Hi Alex,
Have you tried to set local_route and to intercept the BYEs there and to
do custom processing - like adding different headers ?
Regards,
Bogdan
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2207165&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2284108 ] PRACK(100rel) problem with parallel forks
Bugs item #2284108, was opened at 2008-11-14 14:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2284108&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Norm Brandinger (norm_brandinger) Assigned to: Nobody/Anonymous (nobody) Summary: PRACK(100rel) problem with parallel forks Initial Comment: Testing two phones both (Aastra's and Polycom's with PRACK support that cannot be disabled) behind a NAT registering to OpenSIPS with the same name. These tests were in support of PUA_BLA. When an incoming call is made by an endpoint that also supports PRACK, (while both phones ring) only one of the two phones can be answered. When an incoming call is made by an endpoint that does not support PRACK, both phones can be answered. Tested using a SPA942 as the phone calling in (which allows PRACK(100rel) to be turned off) resolved the problem. Tested with FreeSWITCH and it initially failed because (100rel was enabled by default). When I turned off 100rel the problem went away. I believe the problem is caused when the PRACK is being sent to endpoints that have been parallel forked by OpenSIPS. Also, if I only use one Aastra/Polycom (powering the other one down), the single phone is able to be answered all the time. The following thread first caused me to look into OpenSIPS and PRACK a little closer: http://lists.opensips.org/pipermail/users/2008-August/000286.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2284108&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-2297047 ] Dialog:dlg_direction()
Feature Requests item #2297047, was opened at 2008-11-16 10:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2297047&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Priority: 5 Private: No Submitted By: Alex Massover (cupotka2008) Assigned to: Nobody/Anonymous (nobody) Summary: Dialog:dlg_direction() Initial Comment: Hi! What do you think about implementing dlg_direction() function within dialog module (based on tags), an analog to the is_direction() from rr module, but this one will be available from every route type and will be more reliable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2297047&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2305451 ] active_watchers table: presentity_uri correction
Bugs item #2305451, was opened at 2008-11-17 13:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Norm Brandinger (norm_brandinger) Assigned to: Nobody/Anonymous (nobody) Summary: active_watchers table: presentity_uri correction Initial Comment: In the active_watchers table, the presentity_uri appears to have been calculated from incorrect headers. Page 16 of RFC3856 states: The address-of-record in the registration (the To header field) identifies the presentity. For example, in pua/send_subscribe.c, the presentity in the pua table (pres_uri column) appears to be built properly from the "To header" as shown below: memcpy(presentity->pres_uri->s, pto->uri.s, pto->uri.len); However, in presence/subscribe.c, the presentity in the active_watchers table (presentity_uri column) appears to be build improperly from a combination of the R-RUI and From domain as shown below: if(uandd_to_uri(uri.user, subs->from_domain, &subs->pres_uri)< 0) Attached is a patch that updates presence/subscribe.c so that the presentity is build from the To header as follows: if(uandd_to_uri(subs->to_user, subs->to_domain, &subs->pres_uri)< 0) Regards, Norm ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-2209720 ] Remove "reply_to_via" since it's anti RFC 3261
Feature Requests item #2209720, was opened at 2008-10-30 14:54 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2209720&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk >Status: Closed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Remove "reply_to_via" since it's anti RFC 3261 Initial Comment: "reply_to_via=1" forces replies being sent to the IP in the Via sent-by field, even if the Via header contains a parameter "received". This is not RFC 3261 compliant since replies must be always sent to the "received" address when present (and to the port indicated in sent-by field if rport is not present). So this option would be useful prior to RFC 3261, but not now. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-17 17:20 Message: OK - the param was removed on trunk. Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2209720&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2305451 ] active_watchers table: presentity_uri correction
Bugs item #2305451, was opened at 2008-11-17 13:26 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Norm Brandinger (norm_brandinger) Assigned to: Nobody/Anonymous (nobody) Summary: active_watchers table: presentity_uri correction Initial Comment: In the active_watchers table, the presentity_uri appears to have been calculated from incorrect headers. Page 16 of RFC3856 states: The address-of-record in the registration (the To header field) identifies the presentity. For example, in pua/send_subscribe.c, the presentity in the pua table (pres_uri column) appears to be built properly from the "To header" as shown below: memcpy(presentity->pres_uri->s, pto->uri.s, pto->uri.len); However, in presence/subscribe.c, the presentity in the active_watchers table (presentity_uri column) appears to be build improperly from a combination of the R-RUI and From domain as shown below: if(uandd_to_uri(uri.user, subs->from_domain, &subs->pres_uri)< 0) Attached is a patch that updates presence/subscribe.c so that the presentity is build from the To header as follows: if(uandd_to_uri(subs->to_user, subs->to_domain, &subs->pres_uri)< 0) Regards, Norm -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-17 15:36 Message: Without looking into the code: When sending a SUBSCRIBE, the presentity is addressed in the request URI. This is defined in RFC 3265: The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [1]. It also contains enough information to identify the resource for which event notification is desired. I think in this case the pua module tries to find out the presentity from the tm callback - which does not have an RURI anymore and thus maybe the to header is used instead - this is fine as long the pua module always puts into the to header the same URI as into the RURI. The code in presence module you refer to handles the BLA functionality. The BLA is totally crap and breaks with standard SIP methodology and requires such weird behavior. Resume: With the exception of the REGISTER request, the To: header is unimportant. klaus ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Bugs item #2274274, was opened at 2008-11-13 05:25 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brent (brent_thomson) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault in db_postgres Initial Comment: Partial output: *** glibc detected *** opensips: free(): invalid next size (fast): 0x01166c70 *** === Backtrace: = /lib64/libc.so.6[0x2b92149b8684] /lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc] /usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819] /usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df] opensips(db_do_query+0x335)[0x4b0da1] /usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1] /usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8] opensips(do_action+0x24d4)[0x410de0] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x44d7aa] opensips(eval_expr+0xc8)[0x451633] opensips(eval_expr+0x1ac)[0x451717] opensips(eval_expr+0x1e0)[0x45174b] opensips(do_action+0x1caf)[0x4105bb] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(do_action+0x103b)[0x40f947] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(run_top_route+0x61)[0x40e526] opensips(receive_msg+0x51f)[0x445da6] opensips(udp_rcv_loop+0x45c)[0x47af5b] opensips[0x4219ad] opensips(main+0x1c74)[0x423ccf] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4] opensips[0x40e119] CentOS 5.2 OpenSIPS: latest from svn (about an hour ago) PostgreSQL libs: 8.3.4 (built against the same) DB in writeback mode Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem. The core dump is too large to attach so I've posted it here: http://www.sendspace.com/file/1pv989 -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-17 23:59 Message: After fiddling with this some more, it appears that I can only reproduce this consistently if fork=yes in opensips.cfg. If I don't daemonize opensips (run it bare, rather than through the init script) and let all the output go to the console, it no longer crashes. Please let me know if there's any other useful information that I can provide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Bugs item #2274274, was opened at 2008-11-13 00:25 Message generated for change (Comment added) made by saguti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brent (brent_thomson) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault in db_postgres Initial Comment: Partial output: *** glibc detected *** opensips: free(): invalid next size (fast): 0x01166c70 *** === Backtrace: = /lib64/libc.so.6[0x2b92149b8684] /lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc] /usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819] /usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df] opensips(db_do_query+0x335)[0x4b0da1] /usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1] /usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8] opensips(do_action+0x24d4)[0x410de0] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x44d7aa] opensips(eval_expr+0xc8)[0x451633] opensips(eval_expr+0x1ac)[0x451717] opensips(eval_expr+0x1e0)[0x45174b] opensips(do_action+0x1caf)[0x4105bb] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(do_action+0x103b)[0x40f947] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(run_top_route+0x61)[0x40e526] opensips(receive_msg+0x51f)[0x445da6] opensips(udp_rcv_loop+0x45c)[0x47af5b] opensips[0x4219ad] opensips(main+0x1c74)[0x423ccf] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4] opensips[0x40e119] CentOS 5.2 OpenSIPS: latest from svn (about an hour ago) PostgreSQL libs: 8.3.4 (built against the same) DB in writeback mode Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem. The core dump is too large to attach so I've posted it here: http://www.sendspace.com/file/1pv989 -- Comment By: Sergio Gutierrez (saguti) Date: 2008-11-17 19:19 Message: Hello Brent. Is that backtrace taken with gdb? The syntax does not loke familiar. In case it does not, could you take the backtrace with gdb? Regards. Sergio. -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-17 18:59 Message: After fiddling with this some more, it appears that I can only reproduce this consistently if fork=yes in opensips.cfg. If I don't daemonize opensips (run it bare, rather than through the init script) and let all the output go to the console, it no longer crashes. Please let me know if there's any other useful information that I can provide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2204065 ] "strncmp" should not be used to match parameters, SDP...
Bugs item #2204065, was opened at 2008-10-28 15:06
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2204065&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Sergio Gutierrez (saguti)
Summary: "strncmp" should not be used to match parameters, SDP...
Initial Comment:
The following code lines use case sensitive comparisions while most of them try
to match SIP parameters or SDP attributes, that whould be case insenstive per
SIP syntax:
modules/msilo/msilo.c: if(!ctaddr.s || ctaddr.len < 6 ||
strncmp(ctaddr.s, "sip:", 4)
modules/pua_bla/notify.c: if(strncmp(sep+1, "expires=",
8)!= 0)
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(line.s, "sendrecv",
8)==0 || strncmp(line.s, "sendonly", 8)==0 ||
modules/mediaproxy/mediaproxy.c:strncmp(line.s, "recvonly",
8)==0 || strncmp(line.s, "inactive", 8)==0) {
modules/rls/subscribe.c:if(ev_param->name.len== 2 &&
strncmp(ev_param->name.s, "id", 2)== 0)
modules/rls/subscribe.c:if(strncmp(hdr->body.s+ i,
"eventlist", 9)== 0)
modules/rls/resource_notify.c: if(strncmp(smc+1, "reason=", 7))
modules/rls/resource_notify.c: if(strncmp(smc+1, "expires=", 8))
modules/uri/checks.c: if (strncmp(ruri->s, "tel:", 4) != 0) return 1;
modules/pua/hash.h:if (strncmp(event->s, "presence", 8) == 0)
modules/pua/hash.h:if (strncmp(event->s, "xcap-diff", 9) == 0)
modules/pua/hash.h:if (strncmp(event->s, "dialog;sla", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "conference", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "presence;winfo", 14) == 0)
modules/pua/hash.h:if (strncmp(event->s, "message-summary", 15) ==
0)
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence",8 )==0))
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence.winfo",14 )==0))
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/pua_xmpp/simple2xmpp.c:
if(strncmp(hdr->body.s+11,"reason=timeout", 14)== 0)
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/uac/auth_hdr.c: if(val.len>=4 &&
!strncmp(val.s, "auth", 4))
modules/xmpp/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],""",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"'",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/presence_mwi/add_events.c:if (strncmp(body.s, "Messages-Waiting",
16) != 0) goto err;
modules/presence_mwi/add_events.c:if (strncmp(at, "yes", 3) == 0) at = at +
3;
modules/presence_mwi/add_events.c: if (strncmp(at, "no", 2) == 0) at = at
+ 2;
modules/imc/imc_cmd.c: if(cmd->param[0].len<4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/imc/imc_cmd.c: if(cmd->param[0].len<=4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/speeddial/sdlookup.c: if(user_s.len<4 || strncmp(user_s.s, "sip:", 4))
modules/jabber/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],""",6)==0) {
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],"'",6)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/nathelper/nathelper.c: if (strncmp(pnode->rn_address, "udp:",
4) == 0) {
modules/presence/subscribe.c: if(ev_param->name.len== 2 &&
strncmp(ev_param->nam
[OpenSIPS-Devel] [ opensips-Bugs-2305451 ] active_watchers table: presentity_uri correction
Bugs item #2305451, was opened at 2008-11-17 15:26 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Norm Brandinger (norm_brandinger) >Assigned to: Anca Vamanu (anca_vamanu) Summary: active_watchers table: presentity_uri correction Initial Comment: In the active_watchers table, the presentity_uri appears to have been calculated from incorrect headers. Page 16 of RFC3856 states: The address-of-record in the registration (the To header field) identifies the presentity. For example, in pua/send_subscribe.c, the presentity in the pua table (pres_uri column) appears to be built properly from the "To header" as shown below: memcpy(presentity->pres_uri->s, pto->uri.s, pto->uri.len); However, in presence/subscribe.c, the presentity in the active_watchers table (presentity_uri column) appears to be build improperly from a combination of the R-RUI and From domain as shown below: if(uandd_to_uri(uri.user, subs->from_domain, &subs->pres_uri)< 0) Attached is a patch that updates presence/subscribe.c so that the presentity is build from the To header as follows: if(uandd_to_uri(subs->to_user, subs->to_domain, &subs->pres_uri)< 0) Regards, Norm -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-11-18 13:06 Message: Hi Norm, Unfortunately I can not accept your patch and I will explain why. The draft after which BLA is implemented: "http://tools.ietf.org/html/draft-anil-sipping-bla-03"; breaks all rules in presence information - message headers correlation. It does not respect RFC 3856, but gives some examples in which headers have some very strange values so that it makes very difficult extracting the presentity uri. This message is from the draft, at page 11, when a phone sends a SUBSCRIBE to the server: F9 Alice > State Agent SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A From: ;tag=925A3CAD-CEBB276E To: CSeq: 1 SUBSCRIBE Call-ID: [EMAIL PROTECTED] Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Accept: application/dialog-info+xml Max-Forwards: 70 Expires: 3700 Content-Length: 0 You can see here that you can not use the uri in the To header. The phones puts in the TO header what he has received in the Contact header of the SUBSCRIBE sent by the server. And this is in fact exactly the behaviour of the Polycom phones. You can not use the uri in From header either, because when there is a third party registration, it does not contain the uri of the list. Also from the draft, page 16: SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98 From: ;tag=410F7345-F7EBA89C To: CSeq: 1 SUBSCRIBE Call-ID: [EMAIL PROTECTED] Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Accept: application/dialog-info+xml Max-Forwards: 70 Expires: 3700 Content-Length: 0 The solution that I arrived at was to construct the presentity uri from: - username in Contact - domain in From Not as you said, R-URI username and from domain, but contact username and from domain. And I suppose this does not work with aastra. You can send me a SUBSCRIBE message sent by astra to analyse how it puts the info and see if there is a solution to satisfy aastra also. This troubles are caused by the bad draft, but since there are phones that implement it, we implemented it also and we have to stick to it. On the other hand, regarding the extract from RFC 3856 that you printed: it does not apply to this case. It is a suggestion on how to use REGISTER information to construct presence information. RFC 3856 says in fact that the presentity_uri uri should be taken from R-URI of the initial request. I will close your report as invalid. regards, Anca -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-17 17:36 Message: Without looking into the code: When sending a SUBSCRIBE, the presentity is addressed in the request URI. This is defined in RFC 3265: The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [1]. It also contains enough information to identify the resource for which event notification is desired. I think in this case the pua module tries to find out the pre
[OpenSIPS-Devel] [ opensips-Feature Requests-2163867 ] New Pseudo Variables for Current Date
Feature Requests item #2163867, was opened at 2008-10-13 15:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2163867&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: New Pseudo Variables for Current Date Initial Comment: It would be very useful for billing purposes to have a current date pseduo variable (formatted like '-mm-dd') for indexing and grouping CDRs (maybe $Df?). The current $Tf and $Ts vars are too granular for this purpose. I'm currently having to calculate this using a database call which is obviously expensive relative to pulling it from a variable. -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-18 12:11 Message: is it better to use a formatter rather than adding a single format of a date. but maybe it need more effort -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2163867&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-2308761 ] [PERL] Register a perl function as a dialog callback
Feature Requests item #2308761, was opened at 2008-11-18 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2308761&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [PERL] Register a perl function as a dialog callback Initial Comment: It can be interesting to add the possibility to use a perl function as a dialog callback. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2308761&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Bugs item #2274274, was opened at 2008-11-12 22:25 Message generated for change (Comment added) made by brent_thomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brent (brent_thomson) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault in db_postgres Initial Comment: Partial output: *** glibc detected *** opensips: free(): invalid next size (fast): 0x01166c70 *** === Backtrace: = /lib64/libc.so.6[0x2b92149b8684] /lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc] /usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819] /usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df] opensips(db_do_query+0x335)[0x4b0da1] /usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1] /usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8] opensips(do_action+0x24d4)[0x410de0] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x44d7aa] opensips(eval_expr+0xc8)[0x451633] opensips(eval_expr+0x1ac)[0x451717] opensips(eval_expr+0x1e0)[0x45174b] opensips(do_action+0x1caf)[0x4105bb] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(do_action+0x103b)[0x40f947] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(run_top_route+0x61)[0x40e526] opensips(receive_msg+0x51f)[0x445da6] opensips(udp_rcv_loop+0x45c)[0x47af5b] opensips[0x4219ad] opensips(main+0x1c74)[0x423ccf] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4] opensips[0x40e119] CentOS 5.2 OpenSIPS: latest from svn (about an hour ago) PostgreSQL libs: 8.3.4 (built against the same) DB in writeback mode Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem. The core dump is too large to attach so I've posted it here: http://www.sendspace.com/file/1pv989 -- Comment By: Brent (brent_thomson) Date: 2008-11-18 10:17 Message: That backtrace is the output from opensips itself, with debugging set to 9. I'm not a gdb jedi. Can you give me instructions or point me to what I need to do to generate what you're asking for? Is it just a matter of running the binary in the debugger and then grabbing the output when it crashes? -- Comment By: Sergio Gutierrez (saguti) Date: 2008-11-17 17:19 Message: Hello Brent. Is that backtrace taken with gdb? The syntax does not loke familiar. In case it does not, could you take the backtrace with gdb? Regards. Sergio. -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-17 16:59 Message: After fiddling with this some more, it appears that I can only reproduce this consistently if fork=yes in opensips.cfg. If I don't daemonize opensips (run it bare, rather than through the init script) and let all the output go to the console, it no longer crashes. Please let me know if there's any other useful information that I can provide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Bugs item #2274274, was opened at 2008-11-12 22:25 Message generated for change (Comment added) made by brent_thomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brent (brent_thomson) Assigned to: Nobody/Anonymous (nobody) Summary: seg fault in db_postgres Initial Comment: Partial output: *** glibc detected *** opensips: free(): invalid next size (fast): 0x01166c70 *** === Backtrace: = /lib64/libc.so.6[0x2b92149b8684] /lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc] /usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819] /usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df] opensips(db_do_query+0x335)[0x4b0da1] /usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1] /usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1] /usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8] opensips(do_action+0x24d4)[0x410de0] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x44d7aa] opensips(eval_expr+0xc8)[0x451633] opensips(eval_expr+0x1ac)[0x451717] opensips(eval_expr+0x1e0)[0x45174b] opensips(do_action+0x1caf)[0x4105bb] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(do_action+0x103b)[0x40f947] opensips(run_action_list+0x32)[0x40e1fa] opensips(do_action+0x1de0)[0x4106ec] opensips(run_action_list+0x32)[0x40e1fa] opensips[0x40e46e] opensips(run_top_route+0x61)[0x40e526] opensips(receive_msg+0x51f)[0x445da6] opensips(udp_rcv_loop+0x45c)[0x47af5b] opensips[0x4219ad] opensips(main+0x1c74)[0x423ccf] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4] opensips[0x40e119] CentOS 5.2 OpenSIPS: latest from svn (about an hour ago) PostgreSQL libs: 8.3.4 (built against the same) DB in writeback mode Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem. The core dump is too large to attach so I've posted it here: http://www.sendspace.com/file/1pv989 -- Comment By: Brent (brent_thomson) Date: 2008-11-18 11:05 Message: Is this what you need? (gdb) bt #0 0x2b9e74dc7155 in raise () from /lib64/libc.so.6 #1 0x2b9e74dc8bf0 in abort () from /lib64/libc.so.6 #2 0x2b9e74e013db in __libc_message () from /lib64/libc.so.6 #3 0x2b9e74e08684 in _int_free () from /lib64/libc.so.6 #4 0x2b9e74e0bccc in free () from /lib64/libc.so.6 #5 0x2b9e768797e9 in PQclear () from /usr/lib64/libpq.so.5 #6 0x2b9e7665fbe9 in free_query (_con=0x779fe8) at dbase.c:320 #7 0x2b9e7666037d in db_postgres_store_result (_con=0x779fe8, _r=0x7fff368d58b8) at dbase.c:475 #8 0x004b0634 in db_do_query () #9 0x2b9e7665fcc9 in db_postgres_query (_h=0x779fe8, _k=0x7fff368d5830, _op=0x0, _v=0x7fff368d57f0, _c=0x7802e0, _n=1, _nc=2, _o=0x0, _r=0x7fff368d58b8) at dbase.c:363 #10 0x2b9e785fd5b1 in get_ha1 (_username=0x780948, _domain=0x7fff368d58d0, _table=0x7fff368d58c0, _ha1=0x7fff368d58f0 "", res=0x7fff368d58b8) at authorize.c:101 #11 0x2b9e785fd0b1 in authorize (_m=0x77f328, _realm=0x779f30, _table=0x7737a8 "subscriber", _hftype=HDR_AUTHORIZATION_T) at authorize.c:244 #12 0x2b9e785fd9fd in www_authorize (_m=0x77f328, _realm=0x779f30 "\001", _table=0x7737a8 "subscriber") at authorize.c:287 #13 0x004105f0 in do_action () #14 0x0040da0a in run_action_list () #15 0x0044cfba in eval_elem () #16 0x00450e43 in eval_expr () #17 0x00450f27 in eval_expr () #18 0x00450f5b in eval_expr () #19 0x0040fdcb in do_action () #20 0x0040da0a in run_action_list () #21 0x0040dc7e in run_actions () #22 0x0040f157 in do_action () #23 0x0040da0a in run_action_list () #24 0x0044cfba in eval_elem () #25 0x00450e43 in eval_expr () #26 0x00450f5b in eval_expr () #27 0x0040fdcb in do_action () #28 0x0040da0a in run_action_list () #29 0x0040fefc in do_action () #30 0x0040da0a in run_action_list () #31 0x0040dc7e in run_actions () #32 0x0040dd36 in run_top_route () #33 0x004455b6 in receive_msg () #34 0x0047a76b in udp_rcv_loop () #35 0x00
[OpenSIPS-Devel] [ opensips-Bugs-2262249 ] Small mistake in pua_usrloc documentation
Bugs item #2262249, was opened at 2008-11-11 07:54
Message generated for change (Settings changed) made by saguti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
Assigned to: Sergio Gutierrez (saguti)
Summary: Small mistake in pua_usrloc documentation
Initial Comment:
Hi,
a small mistake in pua_usrloc documentation - bad for copy/pasters like me :-)
See http://www.opensips.org/html/docs/modules/1.4.x/pua_usrloc.html#id2525562
For both exported module parameters, the module name is not enclosed in quotes.
e.g. modparam(pua_usrloc, "default_domain", "opensips.org")
should be modparam("pua_usrloc", "default_domain", "opensips.org")
Regards
Sebastian
--
Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-11 08:40
Message:
Fixed. Thanks a lot for reporting.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2262249&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2315042 ] dialog: race between SIP event and dlg timer
Patches item #2315042, was opened at 2008-11-19 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2315042&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: dialog: race between SIP event and dlg timer Initial Comment: After a dialog is removed from the timer list, there's no protection for the list while walking out the expired dialogs. The attached patch is addressing this particular issue. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2315042&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2315042 ] dialog: race between SIP event and dlg timer
Patches item #2315042, was opened at 2008-11-19 17:20 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2315042&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules >Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: dialog: race between SIP event and dlg timer Initial Comment: After a dialog is removed from the timer list, there's no protection for the list while walking out the expired dialogs. The attached patch is addressing this particular issue. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2315042&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2320539 ] Inserting Content-Type Header Wrongly
Bugs item #2320539, was opened at 2008-11-21 12:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Inserting Content-Type Header Wrongly Initial Comment: Inserting Content-Type header wrongly as per syntax. Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 The correct way is as follows = Content-Type: multipart/related;type="application/rlmi+xml";start= "<1227263305.sip:[EMAIL PROTECTED]>";boundary=dXAwGlXKOFXQ6rSATAbvSdga code to change == /* old code: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: \"multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= <%s>;boundary=%s\r\n", start_cid, boundary_string);*/ new changes: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= \"<%s>\";boundary=%s\r\n", start_cid, boundary_string); Sample Msg: === NOTIFY sip:192.168.166.150:50604 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246:4343;branch=z9hG4bK993d.15a823c3.0 To: sip:[EMAIL PROTECTED];tag=s+1+144+5882a317 From: sip:[EMAIL PROTECTED];tag=10.21683.1227170190.0 CSeq: 1 NOTIFY Call-ID: [EMAIL PROTECTED] Content-Length: 524 User-Agent: OpenSIPS (1.4.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=360 Require: eventlist Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 --bJVARonZbIIuteNTNq6iNU46 Content-Transfer-Encoding: binary Content-ID: <1227170190.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2320504 ] Two Max-Forwards header getting added in RLS mode
Bugs item #2320504, was opened at 2008-11-21 12:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320504&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Two Max-Forwards header getting added in RLS mode Initial Comment: Two Max-Forwards header getting added in handling RLS Subscribe msg. eg: SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246:4343;branch=z9hG4bK54fd.7d92c254.0 To: sip:[EMAIL PROTECTED] From: sip:[EMAIL PROTECTED];tag=8438e15ae60d53f8aeb5d5f4de549934-8213 CSeq: 10 SUBSCRIBE Call-ID: [EMAIL PROTECTED] Content-Length: 0 User-Agent: OpenSIPS (1.4.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Expires: 370 Max-Forwards: 70 Support: eventlist Solution: In int resource_subscriptions(subs_t* subs, xmlNodePtr rl_node) function following code should remove. extra_headers.s= buf; extra_headers.len= sprintf(extra_headers.s, "Max-Forwards: 70\r\nSupport: eventlist\r\n"); s.extra_headers= &extra_headers; Please update this in future version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320504&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2320504 ] Two Max-Forwards header getting added in RLS mode
Bugs item #2320504, was opened at 2008-11-21 14:22 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320504&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Anca Vamanu (anca_vamanu) Summary: Two Max-Forwards header getting added in RLS mode Initial Comment: Two Max-Forwards header getting added in handling RLS Subscribe msg. eg: SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246:4343;branch=z9hG4bK54fd.7d92c254.0 To: sip:[EMAIL PROTECTED] From: sip:[EMAIL PROTECTED];tag=8438e15ae60d53f8aeb5d5f4de549934-8213 CSeq: 10 SUBSCRIBE Call-ID: [EMAIL PROTECTED] Content-Length: 0 User-Agent: OpenSIPS (1.4.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Expires: 370 Max-Forwards: 70 Support: eventlist Solution: In int resource_subscriptions(subs_t* subs, xmlNodePtr rl_node) function following code should remove. extra_headers.s= buf; extra_headers.len= sprintf(extra_headers.s, "Max-Forwards: 70\r\nSupport: eventlist\r\n"); s.extra_headers= &extra_headers; Please update this in future version. -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-11-21 17:11 Message: Hi, Thank you very much for the report. Indeed two Max-Forwards headers are were added. I have fixed that. As for the second header it is already removed in the svn version for trunk and 1.4.x branch. There are a lot of bugs fixed in rls in the svn branch compared to the release, so I would advise you to take this module from svn. regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320504&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2320539 ] Inserting Content-Type Header Wrongly
Bugs item #2320539, was opened at 2008-11-21 14:31 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Inserting Content-Type Header Wrongly Initial Comment: Inserting Content-Type header wrongly as per syntax. Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 The correct way is as follows = Content-Type: multipart/related;type="application/rlmi+xml";start= "<1227263305.sip:[EMAIL PROTECTED]>";boundary=dXAwGlXKOFXQ6rSATAbvSdga code to change == /* old code: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: \"multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= <%s>;boundary=%s\r\n", start_cid, boundary_string);*/ new changes: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= \"<%s>\";boundary=%s\r\n", start_cid, boundary_string); Sample Msg: === NOTIFY sip:192.168.166.150:50604 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246:4343;branch=z9hG4bK993d.15a823c3.0 To: sip:[EMAIL PROTECTED];tag=s+1+144+5882a317 From: sip:[EMAIL PROTECTED];tag=10.21683.1227170190.0 CSeq: 1 NOTIFY Call-ID: [EMAIL PROTECTED] Content-Length: 524 User-Agent: OpenSIPS (1.4.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=360 Require: eventlist Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 --bJVARonZbIIuteNTNq6iNU46 Content-Transfer-Encoding: binary Content-ID: <1227170190.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-11-21 17:14 Message: Hi, This is already fixed in svn branch 1.4.x. As I already mentioned in the other bug report, I advise you to take this module from there. Thanks and regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2320539 ] Inserting Content-Type Header Wrongly
Bugs item #2320539, was opened at 2008-11-21 14:31 Message generated for change (Settings changed) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Anca Vamanu (anca_vamanu) Summary: Inserting Content-Type Header Wrongly Initial Comment: Inserting Content-Type header wrongly as per syntax. Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 The correct way is as follows = Content-Type: multipart/related;type="application/rlmi+xml";start= "<1227263305.sip:[EMAIL PROTECTED]>";boundary=dXAwGlXKOFXQ6rSATAbvSdga code to change == /* old code: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: \"multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= <%s>;boundary=%s\r\n", start_cid, boundary_string);*/ new changes: str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, "Content-Type: multipart/related;type=\"application/rlmi+xml\""); str_hdr->len+= sprintf(str_hdr->s+str_hdr->len, ";start= \"<%s>\";boundary=%s\r\n", start_cid, boundary_string); Sample Msg: === NOTIFY sip:192.168.166.150:50604 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246:4343;branch=z9hG4bK993d.15a823c3.0 To: sip:[EMAIL PROTECTED];tag=s+1+144+5882a317 From: sip:[EMAIL PROTECTED];tag=10.21683.1227170190.0 CSeq: 1 NOTIFY Call-ID: [EMAIL PROTECTED] Content-Length: 524 User-Agent: OpenSIPS (1.4.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=360 Require: eventlist Content-Type: "multipart/related;type="application/rlmi+xml";start= <1227170190.sip:[EMAIL PROTECTED]>;boundary=bJVARonZbIIuteNTNq6iNU46 --bJVARonZbIIuteNTNq6iNU46 Content-Transfer-Encoding: binary Content-ID: <1227170190.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-11-21 17:14 Message: Hi, This is already fixed in svn branch 1.4.x. As I already mentioned in the other bug report, I advise you to take this module from there. Thanks and regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2320539&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2204065 ] "strncmp" should not be used to match parameters, SDP...
Bugs item #2204065, was opened at 2008-10-28 08:06
Message generated for change (Comment added) made by saguti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2204065&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Sergio Gutierrez (saguti)
Summary: "strncmp" should not be used to match parameters, SDP...
Initial Comment:
The following code lines use case sensitive comparisions while most of them try
to match SIP parameters or SDP attributes, that whould be case insenstive per
SIP syntax:
modules/msilo/msilo.c: if(!ctaddr.s || ctaddr.len < 6 ||
strncmp(ctaddr.s, "sip:", 4)
modules/pua_bla/notify.c: if(strncmp(sep+1, "expires=",
8)!= 0)
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(line.s, "sendrecv",
8)==0 || strncmp(line.s, "sendonly", 8)==0 ||
modules/mediaproxy/mediaproxy.c:strncmp(line.s, "recvonly",
8)==0 || strncmp(line.s, "inactive", 8)==0) {
modules/rls/subscribe.c:if(ev_param->name.len== 2 &&
strncmp(ev_param->name.s, "id", 2)== 0)
modules/rls/subscribe.c:if(strncmp(hdr->body.s+ i,
"eventlist", 9)== 0)
modules/rls/resource_notify.c: if(strncmp(smc+1, "reason=", 7))
modules/rls/resource_notify.c: if(strncmp(smc+1, "expires=", 8))
modules/uri/checks.c: if (strncmp(ruri->s, "tel:", 4) != 0) return 1;
modules/pua/hash.h:if (strncmp(event->s, "presence", 8) == 0)
modules/pua/hash.h:if (strncmp(event->s, "xcap-diff", 9) == 0)
modules/pua/hash.h:if (strncmp(event->s, "dialog;sla", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "conference", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "presence;winfo", 14) == 0)
modules/pua/hash.h:if (strncmp(event->s, "message-summary", 15) ==
0)
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence",8 )==0))
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence.winfo",14 )==0))
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/pua_xmpp/simple2xmpp.c:
if(strncmp(hdr->body.s+11,"reason=timeout", 14)== 0)
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/uac/auth_hdr.c: if(val.len>=4 &&
!strncmp(val.s, "auth", 4))
modules/xmpp/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],""",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"'",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/presence_mwi/add_events.c:if (strncmp(body.s, "Messages-Waiting",
16) != 0) goto err;
modules/presence_mwi/add_events.c:if (strncmp(at, "yes", 3) == 0) at = at +
3;
modules/presence_mwi/add_events.c: if (strncmp(at, "no", 2) == 0) at = at
+ 2;
modules/imc/imc_cmd.c: if(cmd->param[0].len<4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/imc/imc_cmd.c: if(cmd->param[0].len<=4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/speeddial/sdlookup.c: if(user_s.len<4 || strncmp(user_s.s, "sip:", 4))
modules/jabber/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],""",6)==0) {
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],"'",6)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/nathelper/nathelper.c: if (strncmp(pnode->rn_address, "udp:",
4) == 0) {
modules/presence/subscribe.c: if(ev_param->name.len== 2 &&
strncmp(ev_param->name.s,
[OpenSIPS-Devel] [ opensips-Bugs-2204065 ] "strncmp" should not be used to match parameters, SDP...
Bugs item #2204065, was opened at 2008-10-28 08:06
Message generated for change (Settings changed) made by saguti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2204065&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Sergio Gutierrez (saguti)
Summary: "strncmp" should not be used to match parameters, SDP...
Initial Comment:
The following code lines use case sensitive comparisions while most of them try
to match SIP parameters or SDP attributes, that whould be case insenstive per
SIP syntax:
modules/msilo/msilo.c: if(!ctaddr.s || ctaddr.len < 6 ||
strncmp(ctaddr.s, "sip:", 4)
modules/pua_bla/notify.c: if(strncmp(sep+1, "expires=",
8)!= 0)
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(uri.s, "sip:", 4)==0) {
modules/mediaproxy/mediaproxy.c:if (strncmp(line.s, "sendrecv",
8)==0 || strncmp(line.s, "sendonly", 8)==0 ||
modules/mediaproxy/mediaproxy.c:strncmp(line.s, "recvonly",
8)==0 || strncmp(line.s, "inactive", 8)==0) {
modules/rls/subscribe.c:if(ev_param->name.len== 2 &&
strncmp(ev_param->name.s, "id", 2)== 0)
modules/rls/subscribe.c:if(strncmp(hdr->body.s+ i,
"eventlist", 9)== 0)
modules/rls/resource_notify.c: if(strncmp(smc+1, "reason=", 7))
modules/rls/resource_notify.c: if(strncmp(smc+1, "expires=", 8))
modules/uri/checks.c: if (strncmp(ruri->s, "tel:", 4) != 0) return 1;
modules/pua/hash.h:if (strncmp(event->s, "presence", 8) == 0)
modules/pua/hash.h:if (strncmp(event->s, "xcap-diff", 9) == 0)
modules/pua/hash.h:if (strncmp(event->s, "dialog;sla", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "conference", 10) == 0)
modules/pua/hash.h:if (strncmp(event->s, "presence;winfo", 14) == 0)
modules/pua/hash.h:if (strncmp(event->s, "message-summary", 15) ==
0)
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence",8 )==0))
modules/pua_xmpp/simple2xmpp.c:
(strncmp(msg->event->body.s,"presence.winfo",14 )==0))
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/pua_xmpp/simple2xmpp.c:
if(strncmp(hdr->body.s+11,"reason=timeout", 14)== 0)
modules/pua_xmpp/simple2xmpp.c: if(hdr &&
strncmp(hdr->body.s,"terminated", 10)== 0)
modules/uac/auth_hdr.c: if(val.len>=4 &&
!strncmp(val.s, "auth", 4))
modules/xmpp/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],""",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"'",6)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/xmpp/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/presence_mwi/add_events.c:if (strncmp(body.s, "Messages-Waiting",
16) != 0) goto err;
modules/presence_mwi/add_events.c:if (strncmp(at, "yes", 3) == 0) at = at +
3;
modules/presence_mwi/add_events.c: if (strncmp(at, "no", 2) == 0) at = at
+ 2;
modules/imc/imc_cmd.c: if(cmd->param[0].len<4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/imc/imc_cmd.c: if(cmd->param[0].len<=4 || strncmp(cmd->param[0].s,
"sip:", 4)!=0)
modules/speeddial/sdlookup.c: if(user_s.len<4 || strncmp(user_s.s, "sip:", 4))
modules/jabber/xode_str.c:if (strncmp(&buf[i],"&",5)==0)
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],""",6)==0) {
modules/jabber/xode_str.c:} else if
(strncmp(&buf[i],"'",6)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],"<",4)==0) {
modules/jabber/xode_str.c:} else if (strncmp(&buf[i],">",4)==0) {
modules/nathelper/nathelper.c: if (strncmp(pnode->rn_address, "udp:",
4) == 0) {
modules/presence/subscribe.c: if(ev_param->name.len== 2 &&
strncmp(ev_param-&
[OpenSIPS-Devel] [ opensips-Bugs-2284108 ] PRACK(100rel) problem with parallel forks
Bugs item #2284108, was opened at 2008-11-14 15:06 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2284108&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Norm Brandinger (norm_brandinger) Assigned to: Nobody/Anonymous (nobody) Summary: PRACK(100rel) problem with parallel forks Initial Comment: Testing two phones both (Aastra's and Polycom's with PRACK support that cannot be disabled) behind a NAT registering to OpenSIPS with the same name. These tests were in support of PUA_BLA. When an incoming call is made by an endpoint that also supports PRACK, (while both phones ring) only one of the two phones can be answered. When an incoming call is made by an endpoint that does not support PRACK, both phones can be answered. Tested using a SPA942 as the phone calling in (which allows PRACK(100rel) to be turned off) resolved the problem. Tested with FreeSWITCH and it initially failed because (100rel was enabled by default). When I turned off 100rel the problem went away. I believe the problem is caused when the PRACK is being sent to endpoints that have been parallel forked by OpenSIPS. Also, if I only use one Aastra/Polycom (powering the other one down), the single phone is able to be answered all the time. The following thread first caused me to look into OpenSIPS and PRACK a little closer: http://lists.opensips.org/pipermail/users/2008-August/000286.html -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-23 22:50 Message: Could you provide a SIP trace of the problem you have? I don't understand it. Anyway, note that to send a PRACK you must receive first a provisional response containing a "Contact" header since PRACK is an in-dialog message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2284108&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335003 ] ERROR:db_mysql:db_mysql_submit_query
Bugs item #2335003, was opened at 2008-11-23 22:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR:db_mysql:db_mysql_submit_query Initial Comment: This error occurs to me very often (sometimes during an INVITE, during a SUBSCRIBE...). If it occurs during an INVITE, then OpenSIPS returns 500: --- Nov 23 16:42:07 [12195] ERROR:db_mysql:db_mysql_submit_query: driver error on query: Commands out of sync; you can't run this command now Nov 23 16:42:07 [12195] ERROR:core:db_do_query: error while submitting query Nov 23 16:42:07 [12195] ERROR:auth_db:get_ha1: failed to query database --- I've two users registered (alice and bob), both registered in the same Twinkle sofphone. - If alice calls (so OpenSIPS sends 407) the OpenSIPS returns 500 when alice re-sends the INVITE with credentials (auth_db issue clearly). - If bob calls (OpenSIPS sends also 407) bob re-sends the INVITE with credentials and there is no problem. After restarting OpenSIPS the issue dissapears (temporaly). I've found similar problems, specially this thread: http://www.mail-archive.com/devel%40lists.openser.org/msg02761.html in which Bogdan finally says: - as the DB connections are TCP connections, if the connection is opened before the fork, it will inherited by all the forked child procs. This is a typical error if you mishandle a DB connection from mod_init(). - -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-23 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335003 ] ERROR:db_mysql:db_mysql_submit_query
Bugs item #2335003, was opened at 2008-11-23 22:54 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR:db_mysql:db_mysql_submit_query Initial Comment: This error occurs to me very often (sometimes during an INVITE, during a SUBSCRIBE...). If it occurs during an INVITE, then OpenSIPS returns 500: --- Nov 23 16:42:07 [12195] ERROR:db_mysql:db_mysql_submit_query: driver error on query: Commands out of sync; you can't run this command now Nov 23 16:42:07 [12195] ERROR:core:db_do_query: error while submitting query Nov 23 16:42:07 [12195] ERROR:auth_db:get_ha1: failed to query database --- I've two users registered (alice and bob), both registered in the same Twinkle sofphone. - If alice calls (so OpenSIPS sends 407) the OpenSIPS returns 500 when alice re-sends the INVITE with credentials (auth_db issue clearly). - If bob calls (OpenSIPS sends also 407) bob re-sends the INVITE with credentials and there is no problem. After restarting OpenSIPS the issue dissapears (temporaly). I've found similar problems, specially this thread: http://www.mail-archive.com/devel%40lists.openser.org/msg02761.html in which Bogdan finally says: - as the DB connections are TCP connections, if the connection is opened before the fork, it will inherited by all the forked child procs. This is a typical error if you mishandle a DB connection from mod_init(). - -- >Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-24 14:23 Message: I use Debian Etch (64 bits) with OpenSIPS trunk version: ii libmysqlclient15-dev 5.0.32-7etch6 ii libmysqlclient15off 5.0.32-7etch6 ii mysql-client-5.0 5.0.32-7etch6 ii mysql-common 5.0.32-7etch6 ii mysql-server-5.0 5.0.32-7etch6 ii opensips-mysql-module 1.4.0-1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342336 ] Failed to generate 404 reply when a final 404 was sent out
Bugs item #2342336, was opened at 2008-11-25 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Failed to generate 404 reply when a final 404 was sent out Initial Comment: Version : svn version for trunk Error Message: Nov 25 03:40:08 [13536] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 03:40:08 [13536] DBG:core:parse_headers: flags= Nov 25 03:40:08 [13536] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 03:40:08 [13536] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 03:40:08 [13536] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 03:40:08 [13536] DBG:tm:put_on_wait: put on WAIT Nov 25 03:40:08 [13536] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 03:40:08 [13536] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342736 ] No rls document found in database
Bugs item #2342736, was opened at 2008-11-25 16:07 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: No rls document found in database Initial Comment: Version : svn version for trunk The same setup worked fine in 1.4.2 release build. Log Message Nov 25 04:31:08 [14773] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Nov 25 04:31:08 [14773] DBG:rls:get_resource_list: No rl document found in database Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing 2 columns Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180978 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[1] at 0x8180968 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result names at 0x8180958 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result types at 0x8180878 Nov 25 04:31:08 [14773] DBG:core:db_free_rows: freeing 0 rows Nov 25 04:31:08 [14773] DBG:core:db_free_result: freeing result set at 0x8185a80 Nov 25 04:31:08 [14773] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 04:31:08 [14773] DBG:core:parse_headers: flags= Nov 25 04:31:08 [14773] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 04:31:08 [14773] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 04:31:08 [14773] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 04:31:08 [14773] DBG:tm:put_on_wait: put on WAIT Nov 25 04:31:08 [14773] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 04:31:08 [14773] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-24 00:35 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 12:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-23 23:35 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- >Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 12:13 Message: Could you please say me which rev has the patch? I've done a svn update and got: Usocket_info.h Umodules/nat_traversal/nat_traversal.c Umodules/acc/acc.c Umodules/tm/doc/tm_admin.xml Umodules/tm/uac.c Umodules/tm/README Actualizado a la revisión 5031. (I think no one of these modules are involved in this report, are they?) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 11:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342336 ] Failed to generate 404 reply when a final 404 was sent out
Bugs item #2342336, was opened at 2008-11-25 10:52 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Nathan (rmnathan) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Failed to generate 404 reply when a final 404 was sent out Initial Comment: Version : svn version for trunk Error Message: Nov 25 03:40:08 [13536] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 03:40:08 [13536] DBG:core:parse_headers: flags= Nov 25 03:40:08 [13536] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 03:40:08 [13536] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 03:40:08 [13536] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 03:40:08 [13536] DBG:tm:put_on_wait: put on WAIT Nov 25 03:40:08 [13536] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 03:40:08 [13536] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 12:57 Message: Hi Nathan, A translation of the error is "trying to send a second 404", so could you check on the SIP level if a 404 reply was indeed sent out by opensips? Also, can you provide a full log (for the complete processing) ? - you can send it to me privately if too large. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342736 ] No rls document found in database
Bugs item #2342736, was opened at 2008-11-25 16:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: No rls document found in database Initial Comment: Version : svn version for trunk The same setup worked fine in 1.4.2 release build. Log Message Nov 25 04:31:08 [14773] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Nov 25 04:31:08 [14773] DBG:rls:get_resource_list: No rl document found in database Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing 2 columns Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180978 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[1] at 0x8180968 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result names at 0x8180958 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result types at 0x8180878 Nov 25 04:31:08 [14773] DBG:core:db_free_rows: freeing 0 rows Nov 25 04:31:08 [14773] DBG:core:db_free_result: freeing result set at 0x8185a80 Nov 25 04:31:08 [14773] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 04:31:08 [14773] DBG:core:parse_headers: flags= Nov 25 04:31:08 [14773] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 04:31:08 [14773] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 04:31:08 [14773] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 04:31:08 [14773] DBG:tm:put_on_wait: put on WAIT Nov 25 04:31:08 [14773] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 04:31:08 [14773] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342336 ] Failed to generate 404 reply when a final 404 was sent out
Bugs item #2342336, was opened at 2008-11-25 14:22 Message generated for change (Comment added) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Failed to generate 404 reply when a final 404 was sent out Initial Comment: Version : svn version for trunk Error Message: Nov 25 03:40:08 [13536] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 03:40:08 [13536] DBG:core:parse_headers: flags= Nov 25 03:40:08 [13536] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 03:40:08 [13536] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 03:40:08 [13536] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 03:40:08 [13536] DBG:tm:put_on_wait: put on WAIT Nov 25 03:40:08 [13536] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 03:40:08 [13536] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- Comment By: Nathan (rmnathan) Date: 2008-11-25 17:54 Message: Hi Bogdan, At SIP level 404 was sent out by opensips. can u explain me why am getting following error? DBG:rls:get_resource_list: No rl document found in database But i have two RLS list in database. mysql> desc xcap; +--+--+--+-+-++ | Field| Type | Null | Key | Default | Extra | +--+--+--+-+-++ | id | int(10) unsigned | NO | PRI | NULL| auto_increment | | username | varchar(64) | NO | MUL | || | domain | varchar(64) | NO | | || | doc | blob | NO | | || | doc_type | int(11) | NO | | || | etag | varchar(64) | NO | | || | source | int(11) | NO | MUL | || | doc_uri | varchar(128) | NO | | || | port | int(11) | NO | | || +--+--+--+-+-++ 9 rows in set (0.00 sec) mysql> select id, username, domain, doc_type, etag, source, doc_uri, port from xcap ; ++--+-+--+--++---+--+ | id | username | domain | doc_type | etag | source | doc_uri | port | ++--+-+--+--++---+--+ | 1 | s3-1 | 192.168.166.150 |4 | 4709f53ac7be212e34bb7652d0a0df4c | 0 | resource-list.xml |0 | | 2 | s4-1 | 192.168.166.150 |4 | 37c1be25e27970454b31d3202005db77 | 0 | resource-list.xml |0 | ++--+-+--+--++---+--+ 2 rows in set (0.00 sec) The same setup was worked fine in 1.4.2 release build. Here with full log is attached. Thanks, Nathan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 16:27 Message: Hi Nathan, A translation of the error is "trying to send a second 404", so could you check on the SIP level if a 404 reply was indeed sent out by opensips? Also, can you provide a full log (for the complete processing) ? - you can send it to me privately if too large. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342336&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-24 00:35 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 15:33 Message: check the revision 5032. It was my fault - the commit failed because I didn't updated the sources first. Try now. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 13:13 Message: Could you please say me which rev has the patch? I've done a svn update and got: Usocket_info.h Umodules/nat_traversal/nat_traversal.c Umodules/acc/acc.c Umodules/tm/doc/tm_admin.xml Umodules/tm/uac.c Umodules/tm/README Actualizado a la revisión 5031. (I think no one of these modules are involved in this report, are they?) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 12:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-23 23:35 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- >Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 15:21 Message: It seems to work properly now. Thanks. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 14:33 Message: check the revision 5032. It was my fault - the commit failed because I didn't updated the sources first. Try now. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 12:13 Message: Could you please say me which rev has the patch? I've done a svn update and got: Usocket_info.h Umodules/nat_traversal/nat_traversal.c Umodules/acc/acc.c Umodules/tm/doc/tm_admin.xml Umodules/tm/uac.c Umodules/tm/README Actualizado a la revisión 5031. (I think no one of these modules are involved in this report, are they?) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 11:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342736 ] No rls document found in database
Bugs item #2342736, was opened at 2008-11-25 16:07 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Deleted Resolution: None Priority: 8 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: No rls document found in database Initial Comment: Version : svn version for trunk The same setup worked fine in 1.4.2 release build. Log Message Nov 25 04:31:08 [14773] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Nov 25 04:31:08 [14773] DBG:rls:get_resource_list: No rl document found in database Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing 2 columns Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180978 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[1] at 0x8180968 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result names at 0x8180958 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result types at 0x8180878 Nov 25 04:31:08 [14773] DBG:core:db_free_rows: freeing 0 rows Nov 25 04:31:08 [14773] DBG:core:db_free_result: freeing result set at 0x8185a80 Nov 25 04:31:08 [14773] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 04:31:08 [14773] DBG:core:parse_headers: flags= Nov 25 04:31:08 [14773] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 04:31:08 [14773] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 04:31:08 [14773] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 04:31:08 [14773] DBG:tm:put_on_wait: put on WAIT Nov 25 04:31:08 [14773] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 04:31:08 [14773] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342736 ] No rls document found in database
Bugs item #2342736, was opened at 2008-11-25 16:07 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Deleted Resolution: None >Priority: 1 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: No rls document found in database Initial Comment: Version : svn version for trunk The same setup worked fine in 1.4.2 release build. Log Message Nov 25 04:31:08 [14773] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Nov 25 04:31:08 [14773] DBG:rls:get_resource_list: No rl document found in database Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing 2 columns Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180978 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[1] at 0x8180968 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result names at 0x8180958 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result types at 0x8180878 Nov 25 04:31:08 [14773] DBG:core:db_free_rows: freeing 0 rows Nov 25 04:31:08 [14773] DBG:core:db_free_result: freeing result set at 0x8185a80 Nov 25 04:31:08 [14773] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 04:31:08 [14773] DBG:core:parse_headers: flags= Nov 25 04:31:08 [14773] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 04:31:08 [14773] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 04:31:08 [14773] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 04:31:08 [14773] DBG:tm:put_on_wait: put on WAIT Nov 25 04:31:08 [14773] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 04:31:08 [14773] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2342736 ] No rls document found in database
Bugs item #2342736, was opened at 2008-11-25 16:07 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed Resolution: None Priority: 1 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: No rls document found in database Initial Comment: Version : svn version for trunk The same setup worked fine in 1.4.2 release build. Log Message Nov 25 04:31:08 [14773] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Nov 25 04:31:08 [14773] DBG:rls:get_resource_list: No rl document found in database Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing 2 columns Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180978 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing RES_NAMES[1] at 0x8180968 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result names at 0x8180958 Nov 25 04:31:08 [14773] DBG:core:db_free_columns: freeing result types at 0x8180878 Nov 25 04:31:08 [14773] DBG:core:db_free_rows: freeing 0 rows Nov 25 04:31:08 [14773] DBG:core:db_free_result: freeing result set at 0x8185a80 Nov 25 04:31:08 [14773] DBG:rls:rls_handle_subscribe: list not found - search for uri = sip:[EMAIL PROTECTED] Nov 25 04:31:08 [14773] DBG:core:parse_headers: flags= Nov 25 04:31:08 [14773] DBG:core:check_via_address: params 192.168.166.150, 192.168.166.150, 0 Nov 25 04:31:08 [14773] ERROR:tm:_reply_light: failed to generate 404 reply when a final 404 was sent out Nov 25 04:31:08 [14773] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Nov 25 04:31:08 [14773] DBG:tm:put_on_wait: put on WAIT Nov 25 04:31:08 [14773] ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module Nov 25 04:31:08 [14773] ERROR:rls:rls_handle_subscribe: failed to send 400 reply -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2342736&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-24 00:35 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 19:25 Message: OK - perfect - I will do the backport and also check if there are other similar cases. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 16:21 Message: It seems to work properly now. Thanks. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 15:33 Message: check the revision 5032. It was my fault - the commit failed because I didn't updated the sources first. Try now. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 13:13 Message: Could you please say me which rev has the patch? I've done a svn update and got: Usocket_info.h Umodules/nat_traversal/nat_traversal.c Umodules/acc/acc.c Umodules/tm/doc/tm_admin.xml Umodules/tm/uac.c Umodules/tm/README Actualizado a la revisión 5031. (I think no one of these modules are involved in this report, are they?) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 12:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2351116 ] Error in creating RLS service document
Bugs item #2351116, was opened at 2008-11-26 20:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tools Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in creating RLS service document Initial Comment: Hi I tried latest codes from trunk svn of opensips.I looked at the get_resource_list() in the subscribe.c has changed lot. Instead of resource-list document , rls-services document is used to get the list. I used openxcap to create resource-list document. But now when i tried to create rls-service document in openxcap am getting following error Exception rendering: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 407, in _read self._gotData(result) File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 418, in _gotData result.callback(None) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 243, in callback self._startRunCallbacks(result) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 312, in _startRunCallbacks self._runCallbacks() --- --- File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 328, in _runCallbacks self.result = callback(self.result, *args, **kw) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 178, in _finished_reading d = self.authenticate(request) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 116, in authenticate request.xcap_uri = parseNodeURI(uri, AuthenticationConfig.default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 200, in parseNodeURI return XCAPUri(xcap_root, resource_selector, default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 180, in __init__ if not self.user.domain: exceptions.AttributeError: 'NoneType' object has no attribute 'domain' While trying to store(uri = "/xcap-root/rls-services/global/index") the following rls-service document http://www.w3.org/2001/XMLSchema-instance";> http://[EMAIL PROTECTED]/resource-lists/users/sip:s3- [EMAIL PROTECTED]/resource-list.xml/~~/resource-lists/[EMAIL PROTECTED] presence presence Is there any anything(syntax) I might be missing? Thanks in advance Nathan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351140 ] [nat_traversal] Making OPTIONS/NOTIFY lighter
Patches item #2351140, was opened at 2008-11-26 16:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: [nat_traversal] Making OPTIONS/NOTIFY lighter Initial Comment: I attach a patch that makes NOTIFY/OPTIONS sent by "send_keepalive()" function lighter. Basically I use short header names and make shorter the Call-Id. The original message has ~ 252 chars. The modified message has ~ 198 chars. Not too much anyway. I wonder if the server_IP could also be replaced in From and To headers, and use "nat" as hostpart or whatever. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2351116 ] Error in creating RLS service document
Bugs item #2351116, was opened at 2008-11-26 15:00 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tools Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in creating RLS service document Initial Comment: Hi I tried latest codes from trunk svn of opensips.I looked at the get_resource_list() in the subscribe.c has changed lot. Instead of resource-list document , rls-services document is used to get the list. I used openxcap to create resource-list document. But now when i tried to create rls-service document in openxcap am getting following error Exception rendering: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 407, in _read self._gotData(result) File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 418, in _gotData result.callback(None) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 243, in callback self._startRunCallbacks(result) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 312, in _startRunCallbacks self._runCallbacks() --- --- File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 328, in _runCallbacks self.result = callback(self.result, *args, **kw) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 178, in _finished_reading d = self.authenticate(request) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 116, in authenticate request.xcap_uri = parseNodeURI(uri, AuthenticationConfig.default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 200, in parseNodeURI return XCAPUri(xcap_root, resource_selector, default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 180, in __init__ if not self.user.domain: exceptions.AttributeError: 'NoneType' object has no attribute 'domain' While trying to store(uri = "/xcap-root/rls-services/global/index") the following rls-service document http://www.w3.org/2001/XMLSchema-instance";> http://[EMAIL PROTECTED]/resource-lists/users/sip:s3- [EMAIL PROTECTED]/resource-list.xml/~~/resource-lists/[EMAIL PROTECTED] presence presence Is there any anything(syntax) I might be missing? Thanks in advance Nathan -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-26 15:09 Message: You have opened a ticket on OpenXCAP site with the same question. You are running an old server version as it was explained to you. Please upgrade your server to 1.0.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2335193 ] Presence server forces refresh SUBSCRIBE's being always UDP
Bugs item #2335193, was opened at 2008-11-24 00:35 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Presence server forces refresh SUBSCRIBE's being always UDP Initial Comment: Alice sends a SUBSCRIBE (Event: presence) to Opensips which handles the subscription by itself with the 'presence' module. This SUBSCRIBE has been sent using TCP, but the 200 OK from the presence server has a Contact with no "transport=tcp": - # alice -> OpenSIPS (with presence server) SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: Event: presence # OpenSIPS -> alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.0.129:6060;branch=z9hG4bKfglujzrw Contact: -- As you see, Contact in 200 OK doesn't have ";transport=tcp". This means that future refresh SUBSCRIBE's from alice (in-dialog request) MUST be sent using UDP instead of TCP, while the NOTIFY from OpenSIPS to alice MUST be always using TCP (since the Contact in the initial SUBSCRIBE from alice has "transport=tcp"). While this is not a bug (SIP protocol allows it and also more exotic things) I think it doesn't make sense: Imagine that alice needs to use TCP because the SUBSCRIBE is very long (for any reason) o just because there are network issues using UDP in her network (UDP fragmentation?). In this scenairo refresh subscriptions would be lost. IMHO if the initial SUBSCRIBE uses TCP, the presence server (UAS) should allow using TCP for refresh subscriptions, and for that it must add "transport=tcp" in the Contact of the first 200 OK. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 19:25 Message: OK - perfect - I will do the backport and also check if there are other similar cases. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 16:21 Message: It seems to work properly now. Thanks. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 15:33 Message: check the revision 5032. It was my fault - the commit failed because I didn't updated the sources first. Try now. Thanks and regards, Bogdan -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-25 13:13 Message: Could you please say me which rev has the patch? I've done a svn update and got: Usocket_info.h Umodules/nat_traversal/nat_traversal.c Umodules/acc/acc.c Umodules/tm/doc/tm_admin.xml Umodules/tm/uac.c Umodules/tm/README Actualizado a la revisión 5031. (I think no one of these modules are involved in this report, are they?) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-11-25 12:53 Message: Hi Iñaki, I just commited a fix on SVN trunk - could you please test it - it was a blind fix :D... Thanks and regards, Bogdan ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335193&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351158 ] Pseudovar argument for sleep function at cfgutils.
Patches item #2351158, was opened at 2008-11-26 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351158&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Nobody/Anonymous (nobody) Summary: Pseudovar argument for sleep function at cfgutils. Initial Comment: Based on a question posted by a user, this patch implements the feature of allowing sleep function at cfgutils module receives a pseudovariable argument. This patch is a very first approach, and in case of being accepted, it could be applied to usleep function too. A couple questions: 1. What should be the module's behaviour when argument as invalid value/format (Ignore/log the error, or stop execution?) 2. Should the current behaviour be kept? That is to say, still receive a string as argument, or should it be completely overrided by pseudovar usage? In case that it should be kept, is there a way to do it in the same function? As I see, a new function should be implemented, as fixup functions are different for pseudovar and string. Thanks in advance for your attention. Sergio -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351158&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351140 ] [nat_traversal] Making OPTIONS/NOTIFY lighter
Patches item #2351140, was opened at 2008-11-26 16:09 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: [nat_traversal] Making OPTIONS/NOTIFY lighter Initial Comment: I attach a patch that makes NOTIFY/OPTIONS sent by "send_keepalive()" function lighter. Basically I use short header names and make shorter the Call-Id. The original message has ~ 252 chars. The modified message has ~ 198 chars. Not too much anyway. I wonder if the server_IP could also be replaced in From and To headers, and use "nat" as hostpart or whatever. -- >Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-26 16:25 Message: Humm, I've realized that my patch causes an error: ERROR:core:forward_reply: no 2nd via found in reply I don't see that error. It occurs when OpenSIPS sends (sucesfully) the keepalive NOTIFY and the user replies: - NOTIFY sip:USER_IP:62356 SIP/2.0 v: SIP/2.0/UDP PROXY_IP:5060;branch=0 f: sip:[EMAIL PROTECTED];tag=e3e052d t: sip:USER_IP:62356 i: 28d6327a CSeq: 1 NOTIFY Event: keep-alive l: 0 SIP/2.0 400 Contact header missing Via: SIP/2.0/UDP PROXY_IP:5060;branch=0 To: ;tag=giwjk From: ;tag=e3e052d Call-ID: 28d6327a CSeq: 1 NOTIFY Server: Twinkle/1.3 Content-Length: 0 What could be the problem? does it really exist? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2352405 ] Possible fixing for bug 2225405
Patches item #2352405, was opened at 2008-11-26 16:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fixing for bug 2225405 Initial Comment: IThe attached patch contains a possible fixing for bug reported with ID 2225405 (pua_bla: bla_handle_notify return code to script) I defined for all the cases where parsing errors occured in message, and defined a return code of -1 for those cases. The patch also contains changes to implicit boolean conditions, changing them to explicit equality conditions, and initialization for str variables. Any feedbback about this fixing would be very welcomed. Best regards. Sergio -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 00:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 00:57
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
--
>Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 01:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2351116 ] Error in creating RLS service document
Bugs item #2351116, was opened at 2008-11-26 17:00 Message generated for change (Comment added) made by dan_pascu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tools Group: trunk >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nathan (rmnathan) >Assigned to: Dan (dan_pascu) Summary: Error in creating RLS service document Initial Comment: Hi I tried latest codes from trunk svn of opensips.I looked at the get_resource_list() in the subscribe.c has changed lot. Instead of resource-list document , rls-services document is used to get the list. I used openxcap to create resource-list document. But now when i tried to create rls-service document in openxcap am getting following error Exception rendering: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 407, in _read self._gotData(result) File "/usr/lib/python2.5/site-packages/twisted/web2/stream.py", line 418, in _gotData result.callback(None) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 243, in callback self._startRunCallbacks(result) File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 312, in _startRunCallbacks self._runCallbacks() --- --- File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 328, in _runCallbacks self.result = callback(self.result, *args, **kw) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 178, in _finished_reading d = self.authenticate(request) File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 116, in authenticate request.xcap_uri = parseNodeURI(uri, AuthenticationConfig.default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 200, in parseNodeURI return XCAPUri(xcap_root, resource_selector, default_realm) File "/usr/lib/python2.5/site-packages/xcap/uri.py", line 180, in __init__ if not self.user.domain: exceptions.AttributeError: 'NoneType' object has no attribute 'domain' While trying to store(uri = "/xcap-root/rls-services/global/index") the following rls-service document http://www.w3.org/2001/XMLSchema-instance";> http://[EMAIL PROTECTED]/resource-lists/users/sip:s3- [EMAIL PROTECTED]/resource-list.xml/~~/resource-lists/[EMAIL PROTECTED] presence presence Is there any anything(syntax) I might be missing? Thanks in advance Nathan -- >Comment By: Dan (dan_pascu) Date: 2008-11-27 10:41 Message: This is not the place to report openxcap issues. openxcap has it's own tracker. post there (you already did) and follow the advices you get, instead of posting the same issue to every tracker you know of on every related project. -- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-26 17:09 Message: You have opened a ticket on OpenXCAP site with the same question. You are running an old server version as it was explained to you. Please upgrade your server to 1.0.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2351116&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351140 ] [nat_traversal] Making OPTIONS/NOTIFY lighter
Patches item #2351140, was opened at 2008-11-26 17:09 Message generated for change (Comment added) made by dan_pascu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) >Assigned to: Dan (dan_pascu) Summary: [nat_traversal] Making OPTIONS/NOTIFY lighter Initial Comment: I attach a patch that makes NOTIFY/OPTIONS sent by "send_keepalive()" function lighter. Basically I use short header names and make shorter the Call-Id. The original message has ~ 252 chars. The modified message has ~ 198 chars. Not too much anyway. I wonder if the server_IP could also be replaced in From and To headers, and use "nat" as hostpart or whatever. -- >Comment By: Dan (dan_pascu) Date: 2008-11-27 10:52 Message: The gain is size is minimal and doesn't justity the loss of readability. Plus by changing the way you build the call-id you made it impossible for it to identify the replies. -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-26 17:25 Message: Humm, I've realized that my patch causes an error: ERROR:core:forward_reply: no 2nd via found in reply I don't see that error. It occurs when OpenSIPS sends (sucesfully) the keepalive NOTIFY and the user replies: - NOTIFY sip:USER_IP:62356 SIP/2.0 v: SIP/2.0/UDP PROXY_IP:5060;branch=0 f: sip:[EMAIL PROTECTED];tag=e3e052d t: sip:USER_IP:62356 i: 28d6327a CSeq: 1 NOTIFY Event: keep-alive l: 0 SIP/2.0 400 Contact header missing Via: SIP/2.0/UDP PROXY_IP:5060;branch=0 To: ;tag=giwjk From: ;tag=e3e052d Call-ID: 28d6327a CSeq: 1 NOTIFY Server: Twinkle/1.3 Content-Length: 0 What could be the problem? does it really exist? ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-26 23:57
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 11:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 00:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2354984 ] Error in adding contact header of 200ok SUBSCRIBE message
Bugs item #2354984, was opened at 2008-11-28 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in adding contact header of 200ok SUBSCRIBE message Initial Comment: Error in adding contact header of 200ok SUBSCRIBE message in handling_rls_subscribe. The contact header of 200 ok message should be ip address of opensips. But it sends whatever received from SUBSCRIBE message. Without RLS, its working fine. Subscribe Message SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 260 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 200 ok Message === SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=f1453b347f31a67638709b559e39d455-6afd Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Expires: 260 Contact: Require: eventlist Server: OpenSIPS (1.5.0dev2-notls (i386/linux)) Content-Length: 0 Regards, Nathan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 01:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
>Resolution: Accepted
>Priority: 7
Private: No
Submitted By: Iñaki Baz (ibc_sf)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 13:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 02:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2226940 ] core dump parsing messages
Bugs item #2226940, was opened at 2008-11-05 22:43
Message generated for change (Comment added) made by rrevels
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2226940&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: core dump parsing messages
Initial Comment:
opensips segfault occuring multiple times daily. Core files available on
request.
Core was generated by `/usr/local/opensips/sbin/opensips -f
/usr/local/opensips/etc/opensips/opensips.'.
Program terminated with signal 11, Segmentation fault.
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
75 foo = tp->next;
(gdb) bt
#0 free_to (tb=0x820a9d8) at parser/parse_to.c:75
#1 0x080de8e0 in clean_hdr_field (hf=0x9864de0c) at parser/hf.c:186
#2 0x002e91b7 in run_trans_callbacks (type=2, trans=0x986bd438,
req=0x9864d3d0, rpl=0x820b6f0, code=300) at sip_msg.h:49
#3 0x002f353c in t_reply_matching (p_msg=0x820b6f0, p_branch=0xbfd11764) at
t_lookup.c:840
#4 0x002f39dc in t_check (p_msg=0x820b6f0, param_branch=0xbfd11764) at
t_lookup.c:911
#5 0x00304136 in reply_received (p_msg=0x820b6f0) at t_reply.c:1288
#6 0x08064e4a in forward_reply (msg=0x820b6f0) at forward.c:507
#7 0x080951b6 in receive_msg (
buf=0x817a120 "SIP/2.0 300 Multiple choices\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.XXX;branch=z9hG4bKe2a7.40d37b23.0,SIP/2.0/UDP
XX.XXX.XX.XX:5060;received=XX.XXX.XX.XX;branch=z9hG4bK4abb0821;rport=5060\r\nFrom:
\"FOO\" , len = 775370272}, uri = {s = 0x2e323531 , len = 775500850},
display = {s = 0x353a3033 , len =
993015344}, tag_value = {s = 0x6e617262 ,
len = 2050844771},
parsed_uri = {user = {s = 0x34476839 ,
len = 84434}, passwd = {s = 0x34353865 , len = 1916483894},
host = {s = 0x74726f70 , len =
909129021}, port = {s = 0x460a0d30 , len
= 980250482}, params = {
s = 0x73612220 , len =
1769104756}, headers = {s = 0x20226b73 ,
len = 1885958972}, port_no = 24890,
proto = 29811, type = 1936290405, transport = {s = 0x3736406b , len = 842346798}, ttl = {s = 0x3934322e ,
len = 1043346222}, user_param = {s = 0x6761743b , len = 896753981}, maddr = {s = 0x62323339 ,
len = 221591651}, method = {s = 0x3a6f540a , len = 1769159712}, lr = {s = 0x31323a70 ,
len = 842542646}, r2 = {s = 0x3532322e , len = 892547630}, transport_val = {s = 0x61743b3e ,
len = 808533351}, ttl_val = {s = 0x61306665 , len = 1680959076}, user_param_val = {s = 0x64633732 ,
len = 1664495718}, maddr_val = {s = 0x38656461 , len = 879112754}, method_val = {s = 0x36343939 ,
len = 942564405}, lr_val = {s = 0xd313864 , len = 1818313482}, r2_val = {s = 0x44492d6c ,
len = 1697914938}}, param_lst = 0x30396334, last_param = 0x39336434}
--
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-06 15:40
Message:
Turned debug up to 6 for a while. Here is a partial log output showing the
process id startup and first few lines from the last time opensips core
dumped.
[EMAIL PROTECTED] opensips]# grep 14: /var/log/opensips.log | grep 17235
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=usrloc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=tm
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:tm:child_init_callid: callid: '[EMAIL PROTECTED]'
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=registrar
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=xlog
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:xlog:child_init: init_child [-4] pid [17235]
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=acc
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=avpops
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=permissions
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:core:init_mod_child: type=PROC_TCP_MAIN, rank=-4, module=dispatcher
Nov 6 14:45:33 sips-proxy-01 /usr/local/opensips/sbin/opensips[17235]:
DBG:dispatcher:child_init: #-4 / pid <17235>
Nov 6 14:45:33 si
[OpenSIPS-Devel] [ opensips-Bugs-2354984 ] Error in adding contact header of 200ok SUBSCRIBE message
Bugs item #2354984, was opened at 2008-11-28 13:13 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None >Priority: 9 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in adding contact header of 200ok SUBSCRIBE message Initial Comment: Error in adding contact header of 200ok SUBSCRIBE message in handling_rls_subscribe. The contact header of 200 ok message should be ip address of opensips. But it sends whatever received from SUBSCRIBE message. Without RLS, its working fine. Subscribe Message SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 260 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 200 ok Message === SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=f1453b347f31a67638709b559e39d455-6afd Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Expires: 260 Contact: Require: eventlist Server: OpenSIPS (1.5.0dev2-notls (i386/linux)) Content-Length: 0 Regards, Nathan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2354984 ] Error in adding contact header of 200ok SUBSCRIBE message
Bugs item #2354984, was opened at 2008-11-28 09:43 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Nathan (rmnathan) >Assigned to: Anca Vamanu (anca_vamanu) Summary: Error in adding contact header of 200ok SUBSCRIBE message Initial Comment: Error in adding contact header of 200ok SUBSCRIBE message in handling_rls_subscribe. The contact header of 200 ok message should be ip address of opensips. But it sends whatever received from SUBSCRIBE message. Without RLS, its working fine. Subscribe Message SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 260 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 200 ok Message === SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=f1453b347f31a67638709b559e39d455-6afd Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Expires: 260 Contact: Require: eventlist Server: OpenSIPS (1.5.0dev2-notls (i386/linux)) Content-Length: 0 Regards, Nathan -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-03 17:28 Message: Hi Nathan, Thank you for the report. I have fixed this in trunk and I will also do a backport in stable version. regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2354984 ] Error in adding contact header of 200ok SUBSCRIBE message
Bugs item #2354984, was opened at 2008-11-28 09:43 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Closed Resolution: Fixed Priority: 9 Private: No Submitted By: Nathan (rmnathan) Assigned to: Anca Vamanu (anca_vamanu) Summary: Error in adding contact header of 200ok SUBSCRIBE message Initial Comment: Error in adding contact header of 200ok SUBSCRIBE message in handling_rls_subscribe. The contact header of 200 ok message should be ip address of opensips. But it sends whatever received from SUBSCRIBE message. Without RLS, its working fine. Subscribe Message SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 260 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 200 ok Message === SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;X-ST-CID=20003 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-12901940060 From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=f1453b347f31a67638709b559e39d455-6afd Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20003 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=536870911 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Expires: 260 Contact: Require: eventlist Server: OpenSIPS (1.5.0dev2-notls (i386/linux)) Content-Length: 0 Regards, Nathan -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-03 17:29 Message: Hi Nathan, Thank you for your report. I fixed it in trunk and I will also do a backport in 1.4.X branch. regards, Anca -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-03 17:28 Message: Hi Nathan, Thank you for the report. I have fixed this in trunk and I will also do a backport in stable version. regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2385561 ] Hang due to "no more nonces can be generated"
Bugs item #2385561, was opened at 2008-12-04 00:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Hang due to "no more nonces can be generated" Initial Comment: We've just had OpenSIPS 1.4.2 stop processing SIP packets and effectively hang. During this time, it logged the following many times to /var/log/daemon.log: ERROR:auth:build_auth_hf: no more nonces can be generated ERROR:auth:challenge: failed to generate nonce Restarting OpenSIPS has temporarily cured it, but I expect the problem will come back. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2385561 ] Hang due to "no more nonces can be generated"
Bugs item #2385561, was opened at 2008-12-04 02:33 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: modules >Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Hang due to "no more nonces can be generated" Initial Comment: We've just had OpenSIPS 1.4.2 stop processing SIP packets and effectively hang. During this time, it logged the following many times to /var/log/daemon.log: ERROR:auth:build_auth_hf: no more nonces can be generated ERROR:auth:challenge: failed to generate nonce Restarting OpenSIPS has temporarily cured it, but I expect the problem will come back. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:18 Message: What is the number of authentication requests you expect to have per minute/second ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2385561 ] Hang due to "no more nonces can be generated"
Bugs item #2385561, was opened at 2008-12-04 00:33 Message generated for change (Comment added) made by acunningham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Hang due to "no more nonces can be generated" Initial Comment: We've just had OpenSIPS 1.4.2 stop processing SIP packets and effectively hang. During this time, it logged the following many times to /var/log/daemon.log: ERROR:auth:build_auth_hf: no more nonces can be generated ERROR:auth:challenge: failed to generate nonce Restarting OpenSIPS has temporarily cured it, but I expect the problem will come back. -- Comment By: Alistair Cunningham (acunningham) Date: 2008-12-04 12:26 Message: (I am the original reporter, and have now made an account) This system has around 1800 phones registering to it. Most will have a registration interval of 1 minute or 5 minutes for NAT purposes, as the system was recently upgraded from SER 0.9.6 which didn't handle NAT keep-alives very well and so necessitated a short registration time on the client side. Few (if any) users will have changed to longer intervals. I would budget on 1000 registrations per minute (this figure may be on the high side). If we can overcome this problem, we'd plan to move some very much larger systems (several hundred thousand users) over to OpenSIPS at some point in the medium future. If we do then fo course the registration rate will be much higher. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 12:18 Message: What is the number of authentication requests you expect to have per minute/second ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351158 ] Pseudovar argument for sleep function at cfgutils.
Patches item #2351158, was opened at 2008-11-26 17:16 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351158&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Pseudovar argument for sleep function at cfgutils. Initial Comment: Based on a question posted by a user, this patch implements the feature of allowing sleep function at cfgutils module receives a pseudovariable argument. This patch is a very first approach, and in case of being accepted, it could be applied to usleep function too. A couple questions: 1. What should be the module's behaviour when argument as invalid value/format (Ignore/log the error, or stop execution?) 2. Should the current behaviour be kept? That is to say, still receive a string as argument, or should it be completely overrided by pseudovar usage? In case that it should be kept, is there a way to do it in the same function? As I see, a new function should be implemented, as fixup functions are different for pseudovar and string. Thanks in advance for your attention. Sergio -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:32 Message: Hi Sergio, some remarks: 1) your patch defines a new function m_sleep2(), but I do no see it triggered from the module export structure (you changed only the fixup function) ...also, what about the old m_sleep() function ? 2) please update the docs also (about what params the function accepts) 3) please use consistent code indentation (use only tabs for this, without spaces) Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351158&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351140 ] [nat_traversal] Making OPTIONS/NOTIFY lighter
Patches item #2351140, was opened at 2008-11-26 17:09 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Dan (dan_pascu) Summary: [nat_traversal] Making OPTIONS/NOTIFY lighter Initial Comment: I attach a patch that makes NOTIFY/OPTIONS sent by "send_keepalive()" function lighter. Basically I use short header names and make shorter the Call-Id. The original message has ~ 252 chars. The modified message has ~ 198 chars. Not too much anyway. I wonder if the server_IP could also be replaced in From and To headers, and use "nat" as hostpart or whatever. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:39 Message: Dan, maybe re-using the short naming of the headers (without changing the callid) will spare some bandwidth - if you consider the amount of pings and how often you do it. Regards, Bogdan -- Comment By: Dan (dan_pascu) Date: 2008-11-27 10:52 Message: The gain is size is minimal and doesn't justity the loss of readability. Plus by changing the way you build the call-id you made it impossible for it to identify the replies. -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-26 17:25 Message: Humm, I've realized that my patch causes an error: ERROR:core:forward_reply: no 2nd via found in reply I don't see that error. It occurs when OpenSIPS sends (sucesfully) the keepalive NOTIFY and the user replies: - NOTIFY sip:USER_IP:62356 SIP/2.0 v: SIP/2.0/UDP PROXY_IP:5060;branch=0 f: sip:[EMAIL PROTECTED];tag=e3e052d t: sip:USER_IP:62356 i: 28d6327a CSeq: 1 NOTIFY Event: keep-alive l: 0 SIP/2.0 400 Contact header missing Via: SIP/2.0/UDP PROXY_IP:5060;branch=0 To: ;tag=giwjk From: ;tag=e3e052d Call-ID: 28d6327a CSeq: 1 NOTIFY Server: Twinkle/1.3 Content-Length: 0 What could be the problem? does it really exist? ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2385561 ] Hang due to "no more nonces can be generated"
Bugs item #2385561, was opened at 2008-12-04 02:33 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open >Resolution: Accepted >Priority: 9 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Anca Vamanu (anca_vamanu) Summary: Hang due to "no more nonces can be generated" Initial Comment: We've just had OpenSIPS 1.4.2 stop processing SIP packets and effectively hang. During this time, it logged the following many times to /var/log/daemon.log: ERROR:auth:build_auth_hf: no more nonces can be generated ERROR:auth:challenge: failed to generate nonce Restarting OpenSIPS has temporarily cured it, but I expect the problem will come back. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 15:25 Message: Passed it to Anca. -- Comment By: Alistair Cunningham (acunningham) Date: 2008-12-04 14:26 Message: (I am the original reporter, and have now made an account) This system has around 1800 phones registering to it. Most will have a registration interval of 1 minute or 5 minutes for NAT purposes, as the system was recently upgraded from SER 0.9.6 which didn't handle NAT keep-alives very well and so necessitated a short registration time on the client side. Few (if any) users will have changed to longer intervals. I would budget on 1000 registrations per minute (this figure may be on the high side). If we can overcome this problem, we'd plan to move some very much larger systems (several hundred thousand users) over to OpenSIPS at some point in the medium future. If we do then fo course the registration rate will be much higher. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:18 Message: What is the number of authentication requests you expect to have per minute/second ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2385561 ] Hang due to "no more nonces can be generated"
Bugs item #2385561, was opened at 2008-12-04 02:33 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.4.x Status: Open >Resolution: Fixed Priority: 9 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Anca Vamanu (anca_vamanu) Summary: Hang due to "no more nonces can be generated" Initial Comment: We've just had OpenSIPS 1.4.2 stop processing SIP packets and effectively hang. During this time, it logged the following many times to /var/log/daemon.log: ERROR:auth:build_auth_hf: no more nonces can be generated ERROR:auth:challenge: failed to generate nonce Restarting OpenSIPS has temporarily cured it, but I expect the problem will come back. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 17:59 Message: Hi Alistair, Anca did a fix - indeed it was a bug that was introducing some limitation. Please upload and be as wild as you want with the load - the error should not occur. I will wait for your confirmation in order to close this bug. Regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 15:25 Message: Passed it to Anca. -- Comment By: Alistair Cunningham (acunningham) Date: 2008-12-04 14:26 Message: (I am the original reporter, and have now made an account) This system has around 1800 phones registering to it. Most will have a registration interval of 1 minute or 5 minutes for NAT purposes, as the system was recently upgraded from SER 0.9.6 which didn't handle NAT keep-alives very well and so necessitated a short registration time on the client side. Few (if any) users will have changed to longer intervals. I would budget on 1000 registrations per minute (this figure may be on the high side). If we can overcome this problem, we'd plan to move some very much larger systems (several hundred thousand users) over to OpenSIPS at some point in the medium future. If we do then fo course the registration rate will be much higher. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:18 Message: What is the number of authentication requests you expect to have per minute/second ? ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2385561&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2391787 ] Error in sending NOTIFY for refresh SUBSCRIBE in RLS module
Bugs item #2391787, was opened at 2008-12-05 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2391787&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in sending NOTIFY for refresh SUBSCRIBE in RLS module Initial Comment: Version = trunk build Module = RLS The NOTIFY msg for refresh subscribe is sending directly to UE instead of sending to proxy in RLS mode. In that Route header is missing. Initial subscribe == 1. Proxy to opensips SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bf0d90f7f3edfa41d338960687825df3+s+1;X-ST-CID=21011 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114461640680 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=21011 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for initial subscribe (opensips to proxy) NOTIFY sip:[EMAIL PROTECTED]:6 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246;branch=z9hG4bKaa48.106098f2.0 To: sip:[EMAIL PROTECTED];tag=59572288 From: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 CSeq: 1 NOTIFY Call-ID: s3-1-80 Route: ;X-DC-TM-IDX=1;X-ST-CID=21011, ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Content-Length: 375 User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start= "<1228453070.sip:[EMAIL PROTECTED]>";boundary="Fk3QCGTvdTGnGmVrrm5wBXef" --Fk3QCGTvdTGnGmVrrm5wBXef Content-Transfer-Encoding: binary Content-ID: <1228453070.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" --Fk3QCGTvdTGnGmVrrm5wBXef-- Refresh Subscribe === 1. Proxy to opensips SUBSCRIBE sip:10.6.2.246:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bd987cb1d4b434a184c0ad66fe527ebc+s+1;X-ST-CID=21013 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114224888240 P-Charging-Vector: icid-value=starent.coms3-1-80 Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 P-Asserted-Identity: Call-ID: s3-1-80 CSeq: 2 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for Refresh subscribe (opensips to proxy) Issue: = Here Notification is sending directly to UE. No route header has added. Opensips should send to proxy. Finally lot of re transmission happened for NOTIFY (for not getting 200 ok ) Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5b012fc next=0xb5afbefc, timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:11 [26262] DBG:tm:set_timer: relative timeout is 100 Dec 4 23:58:11 [26262] DBG:tm:insert_timer_unsafe: [5]: 0xb5b012fc (4750) Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afbefc next=(nil), timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afe5ec next=(nil), timeout=4660 Dec 4 23:58:12 [26262] DBG:tm:utimer_routine: timer routine:5,tl=0xb5b012fc next=(nil), timeout=4750 Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:12 [26262] DBG:tm:set_timer: relative timeout is 200 Dec 4 23:58:12 [26262] DBG:tm:insert_timer_unsafe: [6]: 0xb5b012fc (4950) Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:14 [26262] DBG:tm:utimer_routine: timer routine:6,tl=0xb5b012fc next=(nil), timeout=4950 Dec 4 23:58:14 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:14 [26262] DBG:tm:set_timer: relative timeout is 400 Dec 4 23:58:14 [26262] DBG:tm:insert
[OpenSIPS-Devel] [ opensips-Bugs-2391787 ] Error in sending NOTIFY for refresh SUBSCRIBE in RLS module
Bugs item #2391787, was opened at 2008-12-05 11:33 Message generated for change (Settings changed) made by rmnathan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2391787&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None >Priority: 9 Private: No Submitted By: Nathan (rmnathan) Assigned to: Nobody/Anonymous (nobody) Summary: Error in sending NOTIFY for refresh SUBSCRIBE in RLS module Initial Comment: Version = trunk build Module = RLS The NOTIFY msg for refresh subscribe is sending directly to UE instead of sending to proxy in RLS mode. In that Route header is missing. Initial subscribe == 1. Proxy to opensips SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bf0d90f7f3edfa41d338960687825df3+s+1;X-ST-CID=21011 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114461640680 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=21011 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for initial subscribe (opensips to proxy) NOTIFY sip:[EMAIL PROTECTED]:6 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246;branch=z9hG4bKaa48.106098f2.0 To: sip:[EMAIL PROTECTED];tag=59572288 From: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 CSeq: 1 NOTIFY Call-ID: s3-1-80 Route: ;X-DC-TM-IDX=1;X-ST-CID=21011, ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Content-Length: 375 User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start= "<1228453070.sip:[EMAIL PROTECTED]>";boundary="Fk3QCGTvdTGnGmVrrm5wBXef" --Fk3QCGTvdTGnGmVrrm5wBXef Content-Transfer-Encoding: binary Content-ID: <1228453070.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" --Fk3QCGTvdTGnGmVrrm5wBXef-- Refresh Subscribe === 1. Proxy to opensips SUBSCRIBE sip:10.6.2.246:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bd987cb1d4b434a184c0ad66fe527ebc+s+1;X-ST-CID=21013 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114224888240 P-Charging-Vector: icid-value=starent.coms3-1-80 Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 P-Asserted-Identity: Call-ID: s3-1-80 CSeq: 2 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for Refresh subscribe (opensips to proxy) Issue: = Here Notification is sending directly to UE. No route header has added. Opensips should send to proxy. Finally lot of re transmission happened for NOTIFY (for not getting 200 ok ) Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5b012fc next=0xb5afbefc, timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:11 [26262] DBG:tm:set_timer: relative timeout is 100 Dec 4 23:58:11 [26262] DBG:tm:insert_timer_unsafe: [5]: 0xb5b012fc (4750) Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afbefc next=(nil), timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afe5ec next=(nil), timeout=4660 Dec 4 23:58:12 [26262] DBG:tm:utimer_routine: timer routine:5,tl=0xb5b012fc next=(nil), timeout=4750 Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:12 [26262] DBG:tm:set_timer: relative timeout is 200 Dec 4 23:58:12 [26262] DBG:tm:insert_timer_unsafe: [6]: 0xb5b012fc (4950) Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:14 [26262] DBG:tm:utimer_routine: timer routine:6,tl=0xb5b012fc next=(nil), timeout=4950 Dec 4 23:58:14 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:14 [26262] DBG:tm:set_timer: relative timeout is 400 Dec 4 23:58:14 [26262] DBG:tm:insert_timer_unsafe: [7]: 0xb5b012
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 01:57
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
--
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-12-05 10:45
Message:
Hi Inaki,
The timeout update (at sequential request) is done only if the dialog is
in CONFIRMED state (2xx and ACK was received) - note that with a missing
ACK the timeout update will not work.
Try running in full debug mode (=6) and at re-INVITE time look for the
following debug message:
"sequential request successfully processed"
Do you get this?
Regards,
Bogdan
------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 13:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 02:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2187147 ] Core memory allocation failure.
Bugs item #2187147, was opened at 2008-10-22 19:20 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2187147&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandre Ferreira (areisferreira) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Core memory allocation failure. Initial Comment: After some time operating the server Opensips stop the relay of messages and log the following errors: Oct 16 17:02:52 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure Oct 16 17:02:52 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure Oct 16 17:02:56 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_res: out of pkg mem Oct 16 17:02:56 opensips-1.4.2[22197]: ERROR:tm:relay_reply: no mem for outbound reply buffer Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory ; needs 296 Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:sl:sl_send_reply_helper: response building failed Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory ; needs 361 Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:sl:sl_send_reply_helper: response building failed Oct 22 09:04:20 opensips-1.4.2[22203]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory ; needs 296 Oct 22 09:04:20 opensips-1.4.2[22203]: ERROR:sl:sl_send_reply_helper: response building failed Regards, Alexandre Ferreira. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-05 11:59 Message: Hi Alexandre, any news on this? Regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-10-23 10:39 Message: Hi, Have you tried the following : http://www.opensips.org/index.php?n=Resources.DocsTsMem Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2187147&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 00:57
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
--
>Comment By: Iñaki Baz (ibc_sf)
Date: 2008-12-05 12:41
Message:
Bogdan, I do my tests in confirmed dialog (no problem with the ACK of
course).
Also, there is other bug related in which I did a small change in the code
and now the timout is updated:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-12-05 09:45
Message:
Hi Inaki,
The timeout update (at sequential request) is done only if the dialog is
in CONFIRMED state (2xx and ACK was received) - note that with a missing
ACK the timeout update will not work.
Try running in full debug mode (=6) and at re-INVITE time look for the
following debug message:
"sequential request successfully processed"
Do you get this?
Regards,
Bogdan
------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 12:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 01:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on a sequential request
Bugs item #2352599, was opened at 2008-11-27 01:57
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each time a
sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10 seconds I
do re-INVITE's all the time, but when call duraton becomes 10 seconds OpenSIPS
sends a BYE to both sides.
--
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-12-05 15:33
Message:
OK - removing that test will break the timeout setting - it will allow the
default timeout to overwrite the user timeout.
have you set the default_timeout ? if yes, what value?
in script, what value are you pushing in the timeout avp ?
Bogdan
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-12-05 13:41
Message:
Bogdan, I do my tests in confirmed dialog (no problem with the ACK of
course).
Also, there is other bug related in which I did a small change in the code
and now the timout is updated:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-12-05 10:45
Message:
Hi Inaki,
The timeout update (at sequential request) is done only if the dialog is
in CONFIRMED state (2xx and ACK was received) - note that with a missing
ACK the timeout update will not work.
Try running in full debug mode (=6) and at re-INVITE time look for the
following debug message:
"sequential request successfully processed"
Do you get this?
Regards,
Bogdan
------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 13:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_id=139143&atid=743020
--
Comment By: Iñaki Baz (ibc_sf)
Date: 2008-11-27 02:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2351140 ] [nat_traversal] Making OPTIONS/NOTIFY lighter
Patches item #2351140, was opened at 2008-11-26 17:09 Message generated for change (Comment added) made by dan_pascu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Dan (dan_pascu) Summary: [nat_traversal] Making OPTIONS/NOTIFY lighter Initial Comment: I attach a patch that makes NOTIFY/OPTIONS sent by "send_keepalive()" function lighter. Basically I use short header names and make shorter the Call-Id. The original message has ~ 252 chars. The modified message has ~ 198 chars. Not too much anyway. I wonder if the server_IP could also be replaced in From and To headers, and use "nat" as hostpart or whatever. -- >Comment By: Dan (dan_pascu) Date: 2008-12-05 18:53 Message: The gain doesn't justify the loss of readability. You only gain about 20 bytes from the short header names which is less than 10%. For 2 endpoints to keepalive and a ping interval of 90 seconds you will get 400kbps instead of 434kbps. That difference doesn't justify the loss of readability IMO. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-12-04 14:39 Message: Dan, maybe re-using the short naming of the headers (without changing the callid) will spare some bandwidth - if you consider the amount of pings and how often you do it. Regards, Bogdan -- Comment By: Dan (dan_pascu) Date: 2008-11-27 10:52 Message: The gain is size is minimal and doesn't justity the loss of readability. Plus by changing the way you build the call-id you made it impossible for it to identify the replies. -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-11-26 17:25 Message: Humm, I've realized that my patch causes an error: ERROR:core:forward_reply: no 2nd via found in reply I don't see that error. It occurs when OpenSIPS sends (sucesfully) the keepalive NOTIFY and the user replies: - NOTIFY sip:USER_IP:62356 SIP/2.0 v: SIP/2.0/UDP PROXY_IP:5060;branch=0 f: sip:[EMAIL PROTECTED];tag=e3e052d t: sip:USER_IP:62356 i: 28d6327a CSeq: 1 NOTIFY Event: keep-alive l: 0 SIP/2.0 400 Contact header missing Via: SIP/2.0/UDP PROXY_IP:5060;branch=0 To: ;tag=giwjk From: ;tag=e3e052d Call-ID: 28d6327a CSeq: 1 NOTIFY Server: Twinkle/1.3 Content-Length: 0 What could be the problem? does it really exist? ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2351140&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2391787 ] Error in sending NOTIFY for refresh SUBSCRIBE in RLS module
Bugs item #2391787, was opened at 2008-12-05 08:03 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2391787&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Nathan (rmnathan) >Assigned to: Anca Vamanu (anca_vamanu) Summary: Error in sending NOTIFY for refresh SUBSCRIBE in RLS module Initial Comment: Version = trunk build Module = RLS The NOTIFY msg for refresh subscribe is sending directly to UE instead of sending to proxy in RLS mode. In that Route header is missing. Initial subscribe == 1. Proxy to opensips SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bf0d90f7f3edfa41d338960687825df3+s+1;X-ST-CID=21011 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114461640680 P-Charging-Vector: icid-value=starent.coms3-1-80 Route: Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED] P-Asserted-Identity: Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=21011 Record-Route: ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Call-ID: s3-1-80 CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for initial subscribe (opensips to proxy) NOTIFY sip:[EMAIL PROTECTED]:6 SIP/2.0 Via: SIP/2.0/UDP 10.6.2.246;branch=z9hG4bKaa48.106098f2.0 To: sip:[EMAIL PROTECTED];tag=59572288 From: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 CSeq: 1 NOTIFY Call-ID: s3-1-80 Route: ;X-DC-TM-IDX=1;X-ST-CID=21011, ;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913 Content-Length: 375 User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: Subscription-State: active;expires=200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start= "<1228453070.sip:[EMAIL PROTECTED]>";boundary="Fk3QCGTvdTGnGmVrrm5wBXef" --Fk3QCGTvdTGnGmVrrm5wBXef Content-Transfer-Encoding: binary Content-ID: <1228453070.sip:[EMAIL PROTECTED]> Content-Type: application/rlmi+xml;charset="UTF-8r" --Fk3QCGTvdTGnGmVrrm5wBXef-- Refresh Subscribe === 1. Proxy to opensips SUBSCRIBE sip:10.6.2.246:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bd987cb1d4b434a184c0ad66fe527ebc+s+1;X-ST-CID=21013 Via: SIP/2.0/UDP 192.168.126.151:6;branch=z9hG4bK-s3-114224888240 P-Charging-Vector: icid-value=starent.coms3-1-80 Expires: 200 Event: presence Accept: application/rlmi+xml Accept: multipart/related Accept: application/pidf+xml Supported: eventlist From: sip:[EMAIL PROTECTED];tag=59572288 To: sip:[EMAIL PROTECTED];tag=97b57f2144c425bc44f2e7a21eb22549-b818 P-Asserted-Identity: Call-ID: s3-1-80 CSeq: 2 SUBSCRIBE Contact: Content-Length: 0 Max-Forwards: 69 2. Notify for Refresh subscribe (opensips to proxy) Issue: = Here Notification is sending directly to UE. No route header has added. Opensips should send to proxy. Finally lot of re transmission happened for NOTIFY (for not getting 200 ok ) Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5b012fc next=0xb5afbefc, timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:11 [26262] DBG:tm:set_timer: relative timeout is 100 Dec 4 23:58:11 [26262] DBG:tm:insert_timer_unsafe: [5]: 0xb5b012fc (4750) Dec 4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afbefc next=(nil), timeout=4650 Dec 4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afe5ec next=(nil), timeout=4660 Dec 4 23:58:12 [26262] DBG:tm:utimer_routine: timer routine:5,tl=0xb5b012fc next=(nil), timeout=4750 Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:12 [26262] DBG:tm:set_timer: relative timeout is 200 Dec 4 23:58:12 [26262] DBG:tm:insert_timer_unsafe: [6]: 0xb5b012fc (4950) Dec 4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : done Dec 4 23:58:14 [26262] DBG:tm:utimer_routine: timer routine:6,tl=0xb5b012fc next=(nil), timeout=4950 Dec 4 23:58:14 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... ) Dec 4 23:58:14 [26262] DBG:tm:set_timer: relative timeout is 400 Dec 4 23:58:14 [26262] DBG:tm:insert_timer_unsafe: [7]: 0x
[OpenSIPS-Devel] [ opensips-Bugs-2186836 ] PUA_BLA fails for UA's registered behind NAT
Bugs item #2186836, was opened at 2008-10-22 16:26 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2186836&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Anca Vamanu (anca_vamanu) Summary: PUA_BLA fails for UA's registered behind NAT Initial Comment: I'm trying PUA_BLA with phones behind NAT. When the REGISTER arrives I do "fix_nated_register()" so the original Contact: Contact: becomes: Contact: After that I do "bla_set_flag()" so PUA_BLA generates a SUBSCRIBE that should arrive to the UA, but PUA_BLA generates it: SUBSCRIBE sip:[EMAIL PROTECTED]:5060 So this SUBSCRIBE will never arrive to the UAC since it's a private IP. The SUBSCRIBE should be sent to the "received" parameter (added before) but I don't know how to achieve it. A dirty workaround is doing "fix_natted_contact()" before "bla_set_flag()" but this is a bad idea since it will change the stored Contact URI in "location" table (and normally UA's need to see their same private IP in the RURI of requests sent from the proxy). As a suggestion, PUA_BLA should take in account the "received" parameter added in Contact during registration to send the SUBSCRIBE. -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-08 14:40 Message: Hi Inaki, Can you please provide a feedback to this as I would like to close this bug report. regards, Anca -- Comment By: Iñaki Baz (ibc_sf) Date: 2008-10-22 16:43 Message: Thanks a lot, I'll try it ASAP and comment here the result. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-10-22 16:31 Message: Hi Inaki, I have just commited a fix for this. Please test and let me know if it works. regards, Anca Vamanu ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2186836&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2225405 ] pua_bla: bla_handle_notify return code to script
Bugs item #2225405, was opened at 2008-11-05 15:53
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2225405&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: pua_bla: bla_handle_notify return code to script
Initial Comment:
It appears that bla_handle_notify does not return to the script when an error
is detected.
Below are the LOG messages:
ERROR:pua_bla:bla_handle_notify: Notify in a non existing dialog
WARNING:tm:t_unref: script writer didn't release transaction
This is the code around the bla_handle_notify() call:
if (is_method("NOTIFY")) {
if (bla_handle_notify()) {
t_reply("200", "OK");
} else {
xlog("L_INFO", "bla_handle_notify() failed\n");
}
t_release();
}
--
>Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-08 14:04
Message:
Hi Norm,
Thank you for the report. It is fixed now.
regards,
Anca
--
Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-08 13:57
Message:
Hi Norm,
Thank you for the report. It is fixed now.
regards,
Anca
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2225405&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2352405 ] Possible fixing for bug 2225405
Patches item #2352405, was opened at 2008-11-26 23:59 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fixing for bug 2225405 Initial Comment: IThe attached patch contains a possible fixing for bug reported with ID 2225405 (pua_bla: bla_handle_notify return code to script) I defined for all the cases where parsing errors occured in message, and defined a return code of -1 for those cases. The patch also contains changes to implicit boolean conditions, changing them to explicit equality conditions, and initialization for str variables. Any feedbback about this fixing would be very welcomed. Best regards. Sergio -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-08 14:39 Message: Hi Sergio, Thank you for the patch. I have followed the suggestions in it with some modifications. regards, Anca -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-08 13:56 Message: Hi Sergio, Thank you for the patch. I have followed the suggestions in it with some modifications. regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2225405 ] pua_bla: bla_handle_notify return code to script
Bugs item #2225405, was opened at 2008-11-05 15:53
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2225405&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: pua_bla: bla_handle_notify return code to script
Initial Comment:
It appears that bla_handle_notify does not return to the script when an error
is detected.
Below are the LOG messages:
ERROR:pua_bla:bla_handle_notify: Notify in a non existing dialog
WARNING:tm:t_unref: script writer didn't release transaction
This is the code around the bla_handle_notify() call:
if (is_method("NOTIFY")) {
if (bla_handle_notify()) {
t_reply("200", "OK");
} else {
xlog("L_INFO", "bla_handle_notify() failed\n");
}
t_release();
}
--
>Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-08 13:57
Message:
Hi Norm,
Thank you for the report. It is fixed now.
regards,
Anca
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2225405&group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2352405 ] Possible fixing for bug 2225405
Patches item #2352405, was opened at 2008-11-26 23:59 Message generated for change (Settings changed) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Sergio Gutierrez (saguti) Assigned to: Nobody/Anonymous (nobody) Summary: Possible fixing for bug 2225405 Initial Comment: IThe attached patch contains a possible fixing for bug reported with ID 2225405 (pua_bla: bla_handle_notify return code to script) I defined for all the cases where parsing errors occured in message, and defined a return code of -1 for those cases. The patch also contains changes to implicit boolean conditions, changing them to explicit equality conditions, and initialization for str variables. Any feedbback about this fixing would be very welcomed. Best regards. Sergio -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-08 13:56 Message: Hi Sergio, Thank you for the patch. I have followed the suggestions in it with some modifications. regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2352405&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2049389 ] pua_mi crash in mi_publ_rpl_cback
Bugs item #2049389, was opened at 2008-08-13 13:34 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2049389&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Denis Bilenko (denik) Assigned to: Anca Vamanu (anca_vamanu) Summary: pua_mi crash in mi_publ_rpl_cback Initial Comment: I'm using pua_mi module to publish xcap-diff events from openxcap. It crashes when there're many requests and fork=yes (with fork=no I get timeout errors instead). OpenSIPS used: trunk/rev4612, with this patch applied https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2048012&group_id=232389 It also uses presence_xcapdiff module that does nothing else but adds event 'xcap-diff' to presence and to pua. config/logs/core dump are attached Core was generated by `./opensips -f etc/openxcap.cfg -w .'. Program terminated with signal 11, Segmentation fault. [New process 16600] #0 0x7faa606d24b0 in ?? () (gdb) bt #0 0x7faa606d24b0 in ?? () #1 0x7faa62dec956 in mi_publ_rpl_cback (hentity=, reply=0x776d08) at mi_func.c:327 #2 0x7faa63004314 in publ_cback_func (t=, type=, ps=0x7faa661b2340) at pua_callback.h:72 #3 0x7faa65f8481e in run_trans_callbacks (type=256, trans=0x7faa606e0268, req=0x0, rpl=0x765540, code=16600) at t_hooks.c:205 #4 0x7faa65fa0324 in local_reply (t=0x7faa606e0268, p_msg=0x776d08, branch=1859448616, msg_status=, cancel_bitmap=0x7fff6ed4ef28) at t_reply.c:1248 #5 0x7faa65fa1adb in reply_received (p_msg=0x776d08) at t_reply.c:1389 #6 0x00421a6c in forward_reply (msg=0x776d08) at forward.c:507 #7 0x0045d0c5 in receive_msg (buf=0x40d8 , len=1859448784, rcv_info=0x7fff6ed4f020) at receive.c:203 #8 0x0049c456 in udp_rcv_loop () at udp_server.c:449 #9 0x004289de in main (argc=, argv=0x7fff6ed4f1f8) at main.c:780 -- >Comment By: Anca Vamanu (anca_vamanu) Date: 2008-12-08 14:46 Message: Hi Denis, I have fixed this in revision 5015 for 1.4.x branch and revision 5014 for trunk. Thanks and regards, Anca -- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-22 16:49 Message: Logged In: NO Thanks, Anca. I'm using mi_datagram. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2008-08-22 16:39 Message: Logged In: YES user_id=1614776 Originator: NO Hi Denis, I will investigate this. First, please tell me what MI transport are you using? Is it xmlrpc? It seems that there might be some problems in there. Anyhow, I will test it myself with fifo to check if the problem is in pua modules. regards, Anca Vamanu -- Comment By: Denis Bilenko (denik) Date: 2008-08-15 12:20 Message: Logged In: YES user_id=2068628 Originator: YES core: http://devel.ag-projects.com/~denis/opensips_core_dump_pua_mi.bz2 -- Comment By: Denis Bilenko (denik) Date: 2008-08-13 13:56 Message: Logged In: YES user_id=2068628 Originator: YES File Added: crash_log.bz2 ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2049389&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
