Re: [OpenSIPS-Devel] opensips error
Hi, Guan! Unless you have configured an explicit logging facility, you should look in /var/log/messages or /var/log/syslog. Also, you have to increase OpenSIPS debug level (set the debug level to 6 in config file) in order to see if OpenSIPS tries to process any message. Regards, -- Răzvan Crainea OpenSIPS Developer http://www.opensips-solutions.com On 04/19/2012 06:49 PM, Guan Xsun wrote: Hi,Crainea. I find my opensips cant receive sip message from socket. How can I debug it. where can I check its log?? Best Regards 在 2012年4月19日 下午11:07，Guan Xsun guanxian...@gmail.com mailto:guanxian...@gmail.com写 道： HI，Crainea, Where can I look the log of opensips. I want to look its footprint. Best Regards 在 2012年4月19日 下午4:23，Razvan Crainea raz...@opensips.org mailto:raz...@opensips.org写 道： Hi, Guan! You won't find any sip messages in /var/log/messages, only OpenSIPS logs. You should watch the traces you captured in order to find the registration problem. Regards, -- Răzvan Crainea OpenSIPS Developer http://www.opensips-solutions.com On 04/19/2012 04:50 AM, Guan Xsun wrote: HI, Thank you very much ! I have solved that problem , but I find a new problem again. I use MySql as Database. And I have add a new number into database . but it cant registered when I use softphone to register. Can you tell me where can I whatch the log, I think it have received sip messsage for I have looked it from captured packets. But I find no sip messages from /var/log/message. Hope you can give me more informations. Thanks 在 2012年4月18日 下午11:27，Vlad Paiu vladp...@opensips.org mailto:vladp...@opensips.org写 道： Hi, What OS is this on ? It seems to be something related to OS permissions, and not OpenSIPS on it's own, judging by the error message. Do you happen to have SELINUX enabled ? If yes, try to disable it and try again. Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 04/18/2012 06:22 PM, Guan Xsun wrote: HI,all, I enter an error when use opensips. The message log is listed: Apr 18 08:17:36 localhost opensips: ERROR:core:sr_load_module: 1 could not open module /usr/local/lib/opensips/modules/db_mysql.so: /usr/local/mysql/lib/libmysqlclient.so.15: cannot restore segment prot after reloc: Permission denied Apr 18 08:17:36 localhost opensips: CRITICAL:core:yyerror: 2parse error in config file, line 71, column 13-14: failed to load module Apr 18 08:17:36 localhost opensips: CRITICAL:core:yyerror: 2parse error in config file, line 192, column 1-6: syntax error Apr 18 08:17:36 localhost opensips: CRITICAL:core:yyerror: 2parse error in config file, line 192, column 1-6: Invalid arguments Apr 18 08:17:36 localhost opensips: ERROR:core:main: bad config file (3 errors) And the opesips.cfg is attached. ___ Devel mailing list Devel@lists.opensips.org mailto:Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org mailto:Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org mailto:Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org mailto:Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] gts2010`s question
Hi, Li Peng! You are running the script with the $si as first parameter, therefore you should access it in your Python script using sys.argv[1]. For example, if your script is: #!/usr/bin/python import sys print sys.argv[1] Then after executing the following commands in script, you should see the source IP of the message printed: exec_avp(/usr/local/sbin/my_script.py $si, $avp(should_route)); xlog(Script printed $avp(should_route)\n); Regards, -- Ra(zvan Crainea OpenSIPS Developer http://www.opensips-solutions.com On 04/20/2012 10:35 AM, GTS2010 wrote: Hi Paiu: As your words, exec_avp(/usr/local/sbin/my_script.py $si, $avp(should_route)); In my_script.py I can print a str such as the script is running! , but I can not print the $si , I what to know how could I get the $si in my_script.py . I tried the sys.argv[1] , but I failed . And even the sys.argv[0] was can not be print . If I only run the my_script.py , I can get the sys.argv[0] and the sys.argv[1] be printed . Hoping for your help! Thanks Regards! Li Peng beijing China 2012-04-20 GTS2010 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8947] trunk/modules/b2b_logic/logic.c
Revision: 8947 http://opensips.svn.sourceforge.net/opensips/?rev=8947view=rev Author: bogdan_iancu Date: 2012-04-20 09:24:06 + (Fri, 20 Apr 2012) Log Message: --- - fixed handling of Replace header in REFER methods - if the dialog to be replaced by REFER is not found in b2b, simply do not change it. Modified Paths: -- trunk/modules/b2b_logic/logic.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8948] branches/1.8/modules/b2b_logic/logic.c
Revision: 8948 http://opensips.svn.sourceforge.net/opensips/?rev=8948view=rev Author: bogdan_iancu Date: 2012-04-20 09:25:41 + (Fri, 20 Apr 2012) Log Message: --- backport from trunk (rev #8947) - fixed handling of Replace header in REFER methods - if the dialog to be replaced by REFER is not found in b2b, simply do not change it. Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=8947view=rev Modified Paths: -- branches/1.8/modules/b2b_logic/logic.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3519778 ] B2B_LOGIC: completely lumps support
Patches item #3519778, was opened at 2012-04-20 03:03 Message generated for change (Tracker Item Submitted) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3519778group_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: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: B2B_LOGIC: completely lumps support Initial Comment: Now you can change all parts of message before b2b_init_request call and in b2b_request/b2b_reply routes. It useful for add additional headers before b2b_init_request to pass through b2b (don't forget custom_headers param) and also for NAT processing in b2b_request/b2b_reply routes. Instead of patch #3515749. Please, ignore/remove old patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3519778group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3519665 ] drouting: improper handling for address in dr_gateways
Bugs item #3519665, was opened at 2012-04-19 15:35
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3519665group_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.8.x
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting: improper handling for address in dr_gateways
Initial Comment:
The documentation specify that the address field in dr_gateways table is a SIP
URI.
When a SIP URI is populated into the table, drouting fails to load.
The first thing that needs to be fixed is creating the URI that needs to be
parsed in routing.c:add_dst():
@@ -491,8 +491,9 @@
pgw-type = type;
/* add address in the list */
- if(pgw-ip_str.len5 || (strncasecmp(sip:, ip, 4)
-strncasecmp(sips:, ip, 5)))
+ if(pgw-ip_str.len5 ||
+ (strncasecmp(sip:,ip,4) != 0
+ strncasecmp(sips:,ip,5) != 0))
{
if(pgw-ip_str.len+4=GWABUF_MAX_SIZE) {
LM_ERR(GW address (%d) longer
But after that, the code still expects an IP:port in pgw-ip_str (but we have a
SIP URI).
When the new destination URI is created, the resulting SIP URI is bogus because
the host part of the new URI is startin with sip:
drouting:push_gw_for_usage: adding gw [blah] as sip:username@sip:host in
order 0
Regards,
Ovidiu Sas
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-04-20 03:55
Message:
Hi Ovidiu,
Actually the docs should be updated - the GWs are to be defined only as
IP:port format, to be consistent in the entire code.
Regards,
Bogdan
--
Comment By: Ovidiu Sas (osas)
Date: 2012-04-19 15:47
Message:
The URI parsing part is fine (the patch is a noop).
The only issue is storing the full SIP URI as a host:port in the structure
pointed by pgw .
Regards,
Ovidiu Sas
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3519665group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3518386 ] osipsconfig - wrong path
Bugs item #3518386, was opened at 2012-04-16 02:50
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3518386group_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: 1.8.x
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: osipsconfig - wrong path
Initial Comment:
Configuration files in /etc, but wrong path used when osipsconfig tries to
generate config:
Config generated :
/usr/etc/opensips/opensips_residential_2012-4-16_13:24:43.cfg = FAILED. Press
any key to continue
--
Comment By: Nick Altmann (nikbyte)
Date: 2012-04-16 19:54
Message:
There are:
LOCALBASE=/usr CFLAGS=%{optflags} %{__make} all %{?_smp_mflags} TLS=1 \
exclude_modules=%EXCLUDE_MODULES \
cfg-target=%{_sysconfdir}/opensips/ \
modules-prefix=%{buildroot}/%{_prefix} \
modules-dir=%{_lib}/%{name}/modules
opensips compiles with /etc/opensips for configs, but osipsconfig tries to
write files to /usr/etc/opensips ...
--
Comment By: Nick Altmann (nikbyte)
Date: 2012-04-16 19:50
Message:
I build my own rpm.
--
Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-04-16 12:22
Message:
Hi Nick,
How are you running osipsconfig ? From debs, or sources make install ?
Regards,
Vlad
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3518386group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3516053 ] DROUTING - core
Bugs item #3516053, was opened at 2012-04-09 04:42 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3516053group_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.7.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: DROUTING - core Initial Comment: Production server sometimes falls down with core dump. opensips-1.7.2 svn 8787 info stack #0 0x7f2fcde6c8f1 in internal_check_rt (ptree=0x7f2fa8875988, prefix=value optimized out, rgid=1) at prefix_tree.c:88 #1 get_prefix (ptree=0x7f2fa8875988, prefix=value optimized out, rgid=1) at prefix_tree.c:165 #2 0x7f2fcde69985 in do_routing (msg=0x85fac0, drg=value optimized out, sort_order=1) at drouting.c:963 #3 0x00412b30 in do_action (a=0x7b28a0, msg=0x85fac0) at action.c:1280 #4 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #5 0x00457af4 in eval_elem (e=0x7b2978, msg=0x85fac0, val=0x0) at route.c:1398 #6 0x00459335 in eval_expr (e=0x7b2978, msg=0x85fac0, val=0x0) at route.c:1743 #7 0x004592f9 in eval_expr (e=0x7b29c8, msg=0x85fac0, val=0x0) at route.c:1764 #8 0x00412f2e in do_action (a=0x7b3bf8, msg=0x85fac0) at action.c:830 #9 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #10 0x00414755 in run_actions (a=0x7aaed0, msg=0x85fac0) at action.c:121 #11 do_action (a=0x7aaed0, msg=0x85fac0) at action.c:504 #12 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #13 0x00414b33 in do_action (a=0x7ab0a0, msg=0x85fac0) at action.c:847 #14 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #15 0x00415589 in do_action (a=0x7ab250, msg=0x85fac0) at action.c:853 #16 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #17 0x00414755 in run_actions (a=0x7a5a00, msg=0x85fac0) at action.c:121 #18 do_action (a=0x7a5a00, msg=0x85fac0) at action.c:504 #19 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #20 0x00414755 in run_actions (a=0x79a2b8, msg=0x85fac0) at action.c:121 #21 do_action (a=0x79a2b8, msg=0x85fac0) at action.c:504 #22 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #23 0x00414b33 in do_action (a=0x79a390, msg=0x85fac0) at action.c:847 #24 0x00411453 in run_action_list (a=value optimized out, msg=0x85fac0) at action.c:141 #25 0x00416038 in run_actions (a=0x78e168, msg=0x85fac0) at action.c:121 #26 run_top_route (a=0x78e168, msg=0x85fac0) at action.c:182 #27 0x0044c78f in receive_msg (buf=value optimized out, len=value optimized out, rcv_info=value optimized out) at receive.c:165 #28 0x00486ce5 in udp_rcv_loop () at udp_server.c:418 ---Type return to continue, or q return to quit--- #29 0x004288d6 in main_loop (argc=value optimized out, argv=value optimized out) at main.c:872 #30 main (argc=value optimized out, argv=value optimized out) at main.c:1490 #0 0x7f2fcde6c8f1 in internal_check_rt (ptree=0x7f2fa8875988, prefix=value optimized out, rgid=1) at prefix_tree.c:88 i = 0 rg_pos = 1969581679 rg = 0x960 rtlw = 0x0 #1 get_prefix (ptree=0x7f2fa8875988, prefix=value optimized out, rgid=1) at prefix_tree.c:165 rt = 0x0 tmp = value optimized out local = value optimized out idx = value optimized out -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-10 08:25 Message: Okay, thank you. I will try 8870 and I'll open new case if there will be problems. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-10 08:22 Message: Hi Nick, There was a similar bug already fixed in 1.7.2 - see rev 8870. Could you please update from 1.7 SVN branch and see if the crash is still happening ? Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3516053group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3517393 ] B2B and Contact hdr. Again.
Bugs item #3517393, was opened at 2012-04-12 22:04 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3517393group_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.8.x Status: Open Resolution: None Priority: 7 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: B2B and Contact hdr. Again. Initial Comment: When packet goes from internal to external interface, now b2b works well without force_send_socket - it detects send socket correctly. But without force_send_socket Contact header contains always internal ip. If I do force_send_socket(EXT_IP), Contact contains external ip. I think it should also automatically detect Contact ip without force_send_socket. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-20 04:05 Message: Actually the contact should reflect the outbound interface (send socket) all the time, with or without force_send_socket(). I will look into this. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3517393group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Migration to a new wiki system (AG Projects repos)
We have migrated several former Trac web sites to a common wiki site: http://projects.ag-projects.com/ The login accounts of all subscribers have been migrated too but some usernames were duplicated and those have not been properly imported. In case you have been registered on any of our previous wiki sites you may want to check if you can login again. Regards, Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3519665 ] drouting: improper handling for address in dr_gateways
Bugs item #3519665, was opened at 2012-04-19 15:35
Message generated for change (Comment added) made by osas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3519665group_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.8.x
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting: improper handling for address in dr_gateways
Initial Comment:
The documentation specify that the address field in dr_gateways table is a SIP
URI.
When a SIP URI is populated into the table, drouting fails to load.
The first thing that needs to be fixed is creating the URI that needs to be
parsed in routing.c:add_dst():
@@ -491,8 +491,9 @@
pgw-type = type;
/* add address in the list */
- if(pgw-ip_str.len5 || (strncasecmp(sip:, ip, 4)
-strncasecmp(sips:, ip, 5)))
+ if(pgw-ip_str.len5 ||
+ (strncasecmp(sip:,ip,4) != 0
+ strncasecmp(sips:,ip,5) != 0))
{
if(pgw-ip_str.len+4=GWABUF_MAX_SIZE) {
LM_ERR(GW address (%d) longer
But after that, the code still expects an IP:port in pgw-ip_str (but we have a
SIP URI).
When the new destination URI is created, the resulting SIP URI is bogus because
the host part of the new URI is startin with sip:
drouting:push_gw_for_usage: adding gw [blah] as sip:username@sip:host in
order 0
Regards,
Ovidiu Sas
--
Comment By: Ovidiu Sas (osas)
Date: 2012-04-20 06:16
Message:
In this case proper validation of the address field should be imposed.
Maybe socket_info.h:parse_phostport() should be broken in two by creating a
parse_hostport() to validate only host[:port] strings and integrate
parse_hostport() into parse_phostport().
Regards,
Ovidiu Sas
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-04-20 03:55
Message:
Hi Ovidiu,
Actually the docs should be updated - the GWs are to be defined only as
IP:port format, to be consistent in the entire code.
Regards,
Bogdan
--
Comment By: Ovidiu Sas (osas)
Date: 2012-04-19 15:47
Message:
The URI parsing part is fine (the patch is a noop).
The only issue is storing the full SIP URI as a host:port in the structure
pointed by pgw .
Regards,
Ovidiu Sas
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3519665group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8949] branches/1.8/modules/sipmsgops/sipmsgops.c
Revision: 8949 http://opensips.svn.sourceforge.net/opensips/?rev=8949view=rev Author: bogdan_iancu Date: 2012-04-20 15:45:00 + (Fri, 20 Apr 2012) Log Message: --- - fixed validation of SDP in sip_validate() function - try to validate SDP only if application/sdp is advertised. Modified Paths: -- branches/1.8/modules/sipmsgops/sipmsgops.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8950] trunk/modules/sipmsgops/sipmsgops.c
Revision: 8950 http://opensips.svn.sourceforge.net/opensips/?rev=8950view=rev Author: bogdan_iancu Date: 2012-04-20 15:45:51 + (Fri, 20 Apr 2012) Log Message: --- port from 1.8 (rev #8949): - fixed validation of SDP in sip_validate() function - try to validate SDP only if application/sdp is advertised. Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=8949view=rev Modified Paths: -- trunk/modules/sipmsgops/sipmsgops.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8951] trunk/modules/sipmsgops/sipmsgops.c
Revision: 8951 http://opensips.svn.sourceforge.net/opensips/?rev=8951view=rev Author: vladut-paiu Date: 2012-04-20 16:05:58 + (Fri, 20 Apr 2012) Log Message: --- additional fix related to previous commit - content type body must be parsed before using it Modified Paths: -- trunk/modules/sipmsgops/sipmsgops.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[8952] branches/1.8/modules/sipmsgops/sipmsgops.c
Revision: 8952 http://opensips.svn.sourceforge.net/opensips/?rev=8952view=rev Author: bogdan_iancu Date: 2012-04-20 16:07:49 + (Fri, 20 Apr 2012) Log Message: --- additional fix related to previous commit - content type body must be parsed before using it Modified Paths: -- branches/1.8/modules/sipmsgops/sipmsgops.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3516387 ] B2B_LOGIC - transparent authentication
Patches item #3516387, was opened at 2012-04-10 03:35 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_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: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: B2B_LOGIC - transparent authentication Initial Comment: New option: auth_mode = 0 - normal authentication auth_mode = 1 - transparent authentication Passes authentication from one to another side thorough b2b. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-20 12:13 Message: I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible. The only options I see here is either use a kind of module variable to set the flags before the init: $b2b_flags = xx ; or as Nick suggested, with a function, to do more or less the same. Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like: b2b2_init_request(my_scenario,,); - b2b2_init_request(my_scenario/flags,,); Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-15 22:41 Message: What do you think about new command, like b2b_set_flags(flags)? I think that there are more than one option (flag) will be needed in future. Something like: b2b_set_flags(T); # transparent authentication b2b_init_request(top hiding); I think it would be better than just a variable. -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 08:05 Message: I would prefer a variable to be set. Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions). -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-10 07:51 Message: What do you think about change b2b_init_request parameters? First - scenario Second - FLAGS (I think it will be useful in future) Third-Sixth - scenario params And make first flag to manage authentication mode? -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 07:28 Message: Controlling auth mode globally (via a module param) is a little bit restrictive. I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3516387 ] B2B_LOGIC - transparent authentication
Patches item #3516387, was opened at 2012-04-10 03:35 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_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: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: B2B_LOGIC - transparent authentication Initial Comment: New option: auth_mode = 0 - normal authentication auth_mode = 1 - transparent authentication Passes authentication from one to another side thorough b2b. -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-20 12:22 Message: Wow! I think flags in the first param is the best solution! -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-20 12:13 Message: I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible. The only options I see here is either use a kind of module variable to set the flags before the init: $b2b_flags = xx ; or as Nick suggested, with a function, to do more or less the same. Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like: b2b2_init_request(my_scenario,,); - b2b2_init_request(my_scenario/flags,,); Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-15 22:41 Message: What do you think about new command, like b2b_set_flags(flags)? I think that there are more than one option (flag) will be needed in future. Something like: b2b_set_flags(T); # transparent authentication b2b_init_request(top hiding); I think it would be better than just a variable. -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 08:05 Message: I would prefer a variable to be set. Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions). -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-10 07:51 Message: What do you think about change b2b_init_request parameters? First - scenario Second - FLAGS (I think it will be useful in future) Third-Sixth - scenario params And make first flag to manage authentication mode? -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 07:28 Message: Controlling auth mode globally (via a module param) is a little bit restrictive. I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3516387 ] B2B_LOGIC - transparent authentication
Patches item #3516387, was opened at 2012-04-10 03:35 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_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: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: B2B_LOGIC - transparent authentication Initial Comment: New option: auth_mode = 0 - normal authentication auth_mode = 1 - transparent authentication Passes authentication from one to another side thorough b2b. -- Comment By: Ovidiu Sas (osas) Date: 2012-04-20 17:12 Message: If we want this functionality implemented as a flag, then it shouldn't be passed as an extension to the first parameter because: - it's an awkward syntax - and it's really messy when you want to pass more flags. Best thing would be to set up the flag(s) before calling b2b_init_request and leave the syntax for b2b_init_request as is. Regards, Ovidiu Sas -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-20 12:22 Message: Wow! I think flags in the first param is the best solution! -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-20 12:13 Message: I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible. The only options I see here is either use a kind of module variable to set the flags before the init: $b2b_flags = xx ; or as Nick suggested, with a function, to do more or less the same. Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like: b2b2_init_request(my_scenario,,); - b2b2_init_request(my_scenario/flags,,); Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-15 22:41 Message: What do you think about new command, like b2b_set_flags(flags)? I think that there are more than one option (flag) will be needed in future. Something like: b2b_set_flags(T); # transparent authentication b2b_init_request(top hiding); I think it would be better than just a variable. -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 08:05 Message: I would prefer a variable to be set. Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions). -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-10 07:51 Message: What do you think about change b2b_init_request parameters? First - scenario Second - FLAGS (I think it will be useful in future) Third-Sixth - scenario params And make first flag to manage authentication mode? -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 07:28 Message: Controlling auth mode globally (via a module param) is a little bit restrictive. I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3516387 ] B2B_LOGIC - transparent authentication
Patches item #3516387, was opened at 2012-04-10 03:35 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_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: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: B2B_LOGIC - transparent authentication Initial Comment: New option: auth_mode = 0 - normal authentication auth_mode = 1 - transparent authentication Passes authentication from one to another side thorough b2b. -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-20 21:10 Message: Okay, let it be separate command and one-character flags. Like b2b_set_mode(A); A - Enable transparent authentication b2b_set_mode(AxSZ); // For example -- Comment By: Ovidiu Sas (osas) Date: 2012-04-20 17:12 Message: If we want this functionality implemented as a flag, then it shouldn't be passed as an extension to the first parameter because: - it's an awkward syntax - and it's really messy when you want to pass more flags. Best thing would be to set up the flag(s) before calling b2b_init_request and leave the syntax for b2b_init_request as is. Regards, Ovidiu Sas -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-20 12:22 Message: Wow! I think flags in the first param is the best solution! -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-04-20 12:13 Message: I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible. The only options I see here is either use a kind of module variable to set the flags before the init: $b2b_flags = xx ; or as Nick suggested, with a function, to do more or less the same. Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like: b2b2_init_request(my_scenario,,); - b2b2_init_request(my_scenario/flags,,); Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-15 22:41 Message: What do you think about new command, like b2b_set_flags(flags)? I think that there are more than one option (flag) will be needed in future. Something like: b2b_set_flags(T); # transparent authentication b2b_init_request(top hiding); I think it would be better than just a variable. -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 08:05 Message: I would prefer a variable to be set. Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions). -- Comment By: Nick Altmann (nikbyte) Date: 2012-04-10 07:51 Message: What do you think about change b2b_init_request parameters? First - scenario Second - FLAGS (I think it will be useful in future) Third-Sixth - scenario params And make first flag to manage authentication mode? -- Comment By: Ovidiu Sas (osas) Date: 2012-04-10 07:28 Message: Controlling auth mode globally (via a module param) is a little bit restrictive. I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3516387group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
