[OpenSIPS-Devel] [ opensips-Feature Requests-2820627 ] Add option to specify default DB URI
Feature Requests item #2820627, was opened at 2009-07-13 08:49 Message generated for change (Tracker Item Submitted) made by gordonross You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=2820627group_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: Gordon Ross (gordonross) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to specify default DB URI Initial Comment: Many of the modules require access to a database. In some circumstances it may be necessary or desirable to use different usernames/passwords/hosts for the different modules. However, I suspect for many uses, there is no need to do this. So why do we have to specify the URI for each module that requires DB access ? Why not have an option to specify a default DB URI (which can still be over-ridden per module if needs be) ? NOTE: This default option should have a default value of NULL -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=2820627group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2820717 ] event_parse parse first parameter only
Bugs item #2820717, was opened at 2009-07-13 14:25 Message generated for change (Tracker Item Submitted) made by tiberius_d You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2820717group_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: Tiberius DULUMAN (tiberius_d) Assigned to: Nobody/Anonymous (nobody) Summary: event_parse parse first parameter only Initial Comment: There is a bug in function int event_parser(char* _s, int _l, event_t* _e) in parse_event.c. The call end= skip_token(params_str.s, tmp.len- _e-text.len- 1); is wrong. This makes the function to parse first parameter only of the Event header. I have replaced it with: end= tmp.s + tmp.len; and it works fine now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2820717group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen= syntax to support per-interface advertised
Patches item #2706135, was opened at 2009-03-23 15:50 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=2706135group_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: Phil D'Amore (ptdamore) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Change to listen= syntax to support per-interface advertised Initial Comment: [This is the patch for an idea I posted several weeks ago to the devel list. Below is the original list posting as an explanation.] The patch extends the idea of the advertised_address and advertised_port parameters so that it is possible to bind such an address to each listen= statement. Syntax-wise, it works like this: listen=[proto:]host[:port][ AS host[:port]] This new AS host[:port] syntax binds the advertised address specifically to the corresponding socket_info structure. If such an address is specified, it will be used before the address specified as advertised_address, or set in the set_advertised_address function for packets being sent on that particular socket. If it is not specified, then the old methods work as before. The core has been modified so that address tuples using the advertised address work interchangeably with the real address where you'd expect them to. grep_sock_info and find_si have been updated to allow this. Therefore, it is not necessary to explicitly name your advertised address on an alias= line. The following are now equivalent: force_send_socket(udp:adv_address:adv_port); force_send_socket(udp:real_address:real_port); Note we don't specify protocol on the advertised address. The way I see things, it makes no sense to advertise a different protocol, so it inherits the protocol of the socket. Via construction is affected in the same way that the old global advertised_address does, except the Via is written specifically for the socket used to send the message. Lump substitution is also affected. The following lump substitutions are aware of this new facility: SUBST_RCV_IP SUBST_RCV_PORT SUBST_RCV_ALL SUBST_SND_IP SUBST_SND_PORT SUBST_SND_ALL As a result of this, I was able to stop using record_route_preset in my own config, and just use standard record_route. This winds up working much better, because double-rr works properly, and add_rr_param now works as expected for me, where it was a problem using record_route_preset. Additionally, registrar and usrloc had to be modified: registrar - update the add_sock_hdr function to put the advertised address in the message instead of the real address. This allows registration information to be replicated between multi-homed proxies, and the correct interface on the peer can be used. usrloc - update db_insert_ucontact to store the advertised address in the database instead of the real address. Same reasoning as the mods to registrar. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2009-07-13 14:36 Message: Hi Phil, Is the listen_alias_port_fixed.patch the final version with all the bugs fixed ? If so, I will review the code and upload it on SVN. Thanks and regards, Bogdan -- Comment By: Phil D'Amore (ptdamore) Date: 2009-07-10 21:05 Message: Hi Bogdan: Any word if this will be included in the next release now that the bug is fixed? Thanks, Phil -- Comment By: Nergal (nergalex) Date: 2009-06-03 13:07 Message: Hello Phil, That's great, the bug is fixed! Results of no regression tests is OK too. Thank you for your help. Alexis -- Comment By: Phil D'Amore (ptdamore) Date: 2009-05-26 20:03 Message: Alexis: Thanks for the extra information. I think I found the cause of the issue, and I've uploaded a new version of the patch. Please try the listen_alias_port_fixed.patch. I have not had time to test the issue in my environment since I use port 5060 everywhere. Since I don't know if I'll be able to do it today I'm uploading the modified patch so you can test if you'd like. The issue was in the changes to msg_translator.c. I was incorrectly using the length of the original port to calculate an offset. It was not properly re-written with the rest of the code to use the alias port when it's available. Thanks, Phil -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2009-05-26 19:52 Message: Hi Guys, Is the bug fixed in the patch ? I just want to know to start evaluating the patch for upload.
[OpenSIPS-Devel] [ opensips-Bugs-2818650 ] signo=Could not find the frame base for sig_alarm_abort
Bugs item #2818650, was opened at 2009-07-08 20:49 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2818650group_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: Thomas V (tomvogt) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: signo=Could not find the frame base for sig_alarm_abort Initial Comment: opensips 1.4.5-notls, FreeBSD 7.0 (i386). opensips core dumps after a few hours with: #0 0x28268017 in kill () from /lib/libc.so.7 #1 0x28267f76 in raise () from /lib/libc.so.7 #2 0x28266b8a in abort () from /lib/libc.so.7 #3 0x08067ee3 in sig_alarm_abort (signo=Could not find the frame base for sig_alarm_abort. ) at main.c:423 #4 signal handler called #5 fm_status (qm=0x287fe000) at mem/f_malloc.c:512 #6 0x080679ed in cleanup (show_status=1) at main.c:356 #7 0x08068795 in handle_sigs () at main.c:524 #8 0x0806c969 in main (argc=3, argv=0xbfbfec58) at main.c:866 any idea? -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2009-07-13 15:14 Message: Hi Thomas, Somewhere in the code, a SEG FAULT happens: Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8408]: INFO:core:handle_sigs: child process 8421 exited by a signal 11 This triggers a shutdown, but this fails and a second crash happens - the new core file is overwriting the original one, hiding the real cause of the crash. To avoid this, I attached here a small patch that will skip the shutdown part, so that it will avoid the overwrite of the core. Please patch your code and post here the BT of the real core file -- Comment By: Thomas V (tomvogt) Date: 2009-07-10 16:07 Message: It crashes also with more Ram. Looks like memory is not the case. I do not have more information. With an older opensips 1.4.2-notls the system always crashed with: SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP 212.xxx.xxx.xxx;branch=z9hG4bK0622.99552112.0\r\nVia: SIP/2.0/UDP 85.xxx.xxx.xxx4:5060;received=85.xxx.xxx.xxx;rport=5060;branch=z9hG4bKc3ba5c8f50bc782082391762e9a2fa9e\r\nF..., len=503, rcv_info=0xbfbfeb14 A ngrep when 1.4.2 was running showed: U 85.xxx.xxx.xxx:5060 - 212.xxx.xxx.xxx:5060 INVITE sip:x...@212.xxx.xxx.xxx SIP/2.0. Via: SIP/2.0/UDP 85.xxx.xxx.xxx4:5060;rport;branch=z9hG4bK3759d84a0bea3edc47d08b9ec1cd2979. To: sip:...@212.xxx.xxx.xxx. From: sip:...@212.xxx.xxx.xxx;tag=AI60E7E8F4CC7D6BD2. Call-ID: ai1e214f5edc57c...@192.168.1.240. CSeq: 1 INVITE. Max-Forwards: 70. Contact: sip:...@85.xxx.xxx.xxx;line=AIDF22AB43A35036D9. Accept: application/sdp. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER. P-Preferred-Identity: sip:xx...@212.xxx.xxx.xxx5. Privacy: none. User-Agent: Aastra Intelligate. Content-Type: application/sdp. Content-Length: 248. . . . . . . . . . # I 212.xxx.xxx.xxx - 85.xxx.xxx.xxx 3:3 ...E(..k...;. Uv...e.}~ ;l # We installed Revision: 5049. After that we had the sig_alarm_abort issue. So we updated to 1.4.5-notls. Nothing changed, opensips still crashes. -- Comment By: Thomas V (tomvogt) Date: 2009-07-10 12:13 Message: Hi Bogdan I'm not sure but it looks like a memory leak. I upgraded the system to FreeBSD 7.2 and added an additional 1 GB memory (total 2gb). After 48h opensips reserved at least 1gb (1gb is for postgresql). We do not allow to use swap on the system. If the system has less than 50mb left, opensips crashes Log: Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8408]: INFO:core:handle_sigs: child process 8421 exited by a signal 11 Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8408]: INFO:core:handle_sigs: core was generated Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8408]: INFO:core:handle_sigs: terminating due to SIGCHLD Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8439]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8435]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8434]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8433]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8432]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8427]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8426]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8425]: INFO:core:sig_usr: signal 15 received Jul 10 08:58:59 sip02 /usr/local/sbin/opensips[8424]: INFO:core:sig_usr: signal 15
[OpenSIPS-Devel] dialog.info event package?
It occurs to me that when one wants to properly implement the dialog event package in an end-point it also needs: a) A way to provision policy b) A way to be notified about watchers For Event=presence we have pres-rules for a) and presence.winfo for b). Dialog-rules and dialog.winfo seem to be a mirrored way to do the similar but for dialog event. Does anyone have any better idea for how to accomplish the above? Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2819246 ] opensipsctl add broken for Postgres
Bugs item #2819246, was opened at 2009-07-09 23:59 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2819246group_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: Gordon Ross (gordonross) Assigned to: Iulia Bublea (iulia_bublea) Summary: opensipsctl add broken for Postgres Initial Comment: With the latest code from the trunk, if you try and add a user/subscriber to the DB (when using the Postgres backend) you are unable to. You get the message that the entry already exists in aliases. Yet the aliases tables are empty. Reverting back to the 1.5.1 source tarball, and things work fine. I suspect that the error is in the way the code is handling the return from the count() SQL function which is used to ascertain is the entry already exists. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2819246group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2819246 ] opensipsctl add broken for Postgres
Bugs item #2819246, was opened at 2009-07-09 23:59 Message generated for change (Comment added) made by iulia_bublea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2819246group_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: None Priority: 5 Private: No Submitted By: Gordon Ross (gordonross) Assigned to: Iulia Bublea (iulia_bublea) Summary: opensipsctl add broken for Postgres Initial Comment: With the latest code from the trunk, if you try and add a user/subscriber to the DB (when using the Postgres backend) you are unable to. You get the message that the entry already exists in aliases. Yet the aliases tables are empty. Reverting back to the 1.5.1 source tarball, and things work fine. I suspect that the error is in the way the code is handling the return from the count() SQL function which is used to ascertain is the entry already exists. -- Comment By: Iulia Bublea (iulia_bublea) Date: 2009-07-13 19:05 Message: Problem encountered due to the use of concat function, which is not Postgres compatible. Issue was fixed -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2819246group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen= syntax to support per-interface advertised
Patches item #2706135, was opened at 2009-03-23 09:50 Message generated for change (Comment added) made by ptdamore You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=2706135group_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: Phil D'Amore (ptdamore) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Change to listen= syntax to support per-interface advertised Initial Comment: [This is the patch for an idea I posted several weeks ago to the devel list. Below is the original list posting as an explanation.] The patch extends the idea of the advertised_address and advertised_port parameters so that it is possible to bind such an address to each listen= statement. Syntax-wise, it works like this: listen=[proto:]host[:port][ AS host[:port]] This new AS host[:port] syntax binds the advertised address specifically to the corresponding socket_info structure. If such an address is specified, it will be used before the address specified as advertised_address, or set in the set_advertised_address function for packets being sent on that particular socket. If it is not specified, then the old methods work as before. The core has been modified so that address tuples using the advertised address work interchangeably with the real address where you'd expect them to. grep_sock_info and find_si have been updated to allow this. Therefore, it is not necessary to explicitly name your advertised address on an alias= line. The following are now equivalent: force_send_socket(udp:adv_address:adv_port); force_send_socket(udp:real_address:real_port); Note we don't specify protocol on the advertised address. The way I see things, it makes no sense to advertise a different protocol, so it inherits the protocol of the socket. Via construction is affected in the same way that the old global advertised_address does, except the Via is written specifically for the socket used to send the message. Lump substitution is also affected. The following lump substitutions are aware of this new facility: SUBST_RCV_IP SUBST_RCV_PORT SUBST_RCV_ALL SUBST_SND_IP SUBST_SND_PORT SUBST_SND_ALL As a result of this, I was able to stop using record_route_preset in my own config, and just use standard record_route. This winds up working much better, because double-rr works properly, and add_rr_param now works as expected for me, where it was a problem using record_route_preset. Additionally, registrar and usrloc had to be modified: registrar - update the add_sock_hdr function to put the advertised address in the message instead of the real address. This allows registration information to be replicated between multi-homed proxies, and the correct interface on the peer can be used. usrloc - update db_insert_ucontact to store the advertised address in the database instead of the real address. Same reasoning as the mods to registrar. -- Comment By: Phil D'Amore (ptdamore) Date: 2009-07-13 12:47 Message: Bogdan, Yes the listen_alias_port_fixed.patch file contains a complete patch with the known issues fixed. Looking forward to your assessment. Thanks, Phil -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2009-07-13 07:36 Message: Hi Phil, Is the listen_alias_port_fixed.patch the final version with all the bugs fixed ? If so, I will review the code and upload it on SVN. Thanks and regards, Bogdan -- Comment By: Phil D'Amore (ptdamore) Date: 2009-07-10 14:05 Message: Hi Bogdan: Any word if this will be included in the next release now that the bug is fixed? Thanks, Phil -- Comment By: Nergal (nergalex) Date: 2009-06-03 06:07 Message: Hello Phil, That's great, the bug is fixed! Results of no regression tests is OK too. Thank you for your help. Alexis -- Comment By: Phil D'Amore (ptdamore) Date: 2009-05-26 13:03 Message: Alexis: Thanks for the extra information. I think I found the cause of the issue, and I've uploaded a new version of the patch. Please try the listen_alias_port_fixed.patch. I have not had time to test the issue in my environment since I use port 5060 everywhere. Since I don't know if I'll be able to do it today I'm uploading the modified patch so you can test if you'd like. The issue was in the changes to msg_translator.c. I was incorrectly using the length of the original port to calculate an offset. It was not properly re-written with the rest of the code to use the alias port
Re: [OpenSIPS-Devel] dialog.info event package?
El Lunes, 13 de Julio de 2009, Adrian Georgescu escribió: It occurs to me that when one wants to properly implement the dialog event package in an end-point it also needs: a) A way to provision policy b) A way to be notified about watchers For Event=presence we have pres-rules for a) and presence.winfo for b). Dialog-rules and dialog.winfo seem to be a mirrored way to do the similar but for dialog event. Does anyone have any better idea for how to accomplish the above? The provision policy (using XCAP?) is not defined by IETF. However, using dialog.winfo is the expected way since winfo package is defined for any kind of event type. -- Iñaki Baz Castillo i...@aliax.net ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Developer Docs?
Hello, I am new to OpenSIPS. My target is to make a SIP Application Server for presence and messaging according to GSM RCS initiative. I did some exploration of the presence and rls features from the website. I think I will have to extend these to meet OMA/RCS specs. I am quite lost when I peek into the code to understand it. As it is written in plain C, not object oriented C++. Can anyone point me to some sort of development guide or doc that shows how different modules interact with each other, how to extend a module, what basics does a module need, how can one module be used from another, what the general flow of execution is with core and modules, overview of the architecture of OpenSIPS, how to parse messages, the commonly used codes etc. I think it would have been helpful to have some document from the devel course link, but I could not find any. Thanks, Andaleeb ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Developer Docs?
The Kamailio folks have a development guide: http://www.kamailio.org/docs/openser-devel-guide/ Much of what is said there applies to OpenSIPS as well - at least, so far. A great deal of it is generally true of the OpenSER code stock. Andaleeb Roomy wrote: Hello, I am new to OpenSIPS. My target is to make a SIP Application Server for presence and messaging according to GSM RCS initiative. I did some exploration of the presence and rls features from the website. I think I will have to extend these to meet OMA/RCS specs. I am quite lost when I peek into the code to understand it. As it is written in plain C, not object oriented C++. Can anyone point me to some sort of development guide or doc that shows how different modules interact with each other, how to extend a module, what basics does a module need, how can one module be used from another, what the general flow of execution is with core and modules, overview of the architecture of OpenSIPS, how to parse messages, the commonly used codes etc. I think it would have been helpful to have some document from the devel course link, but I could not find any. Thanks, Andaleeb ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
