Re: [SR-Users] generating cdrs
Hey, Am 23.04.2012 um 22:57 schrieb Pirjo Ahvenainen: No prob, and thanks for your comments, I'm suspecting I had installed a devel version on the system I was testing before installing 3.2.3 and had used its db creation scripts. So what I will need to do is go back to testing the right version! ;) I installed a clean box with 3.2.3, no cdrs table vs. the one I had, I'll use that for devel version testing. Next job, I'll try it out with the devel version. So the cdr to db is on its way, the 3.2 documentation means saving only to syslog. Originally I associated this to the cdrs table I was staring at. I think I can call this myth busted! Admittedly, the docs could be a bit more clear on the fact that CDR generation doesn't involve database storage (yet). Being the original author, I'm the one to blame. :) I'll try to increase documentation accuracy of the acc module as soon as I can get to it. Thanks and cheers, --Timo 23. huhtikuuta 2012 18.15 Timo Reimann s...@foo-lounge.de kirjoitti: Hey Pirjo, sorry for the delay! Am 20.04.2012 um 20:05 schrieb Pirjo Ahvenainen: That would sort of make sense... Although, 'kamdbctl create' generates cdrs table along with all others, why have a table (+ 3.2 documentation), with nothing to populate that table in code? I cannot find any instances of the word cdr in any file of the util/kamctl and lib/ directories. Are you sure that there are CDR-related tables being created with that script? With regards to the acc documentation, there's no mentioning of any database storage as far as I can tell. I wrote the original piece of documentation, so unless someone has extended the code base and updated the docs there shouldn't be any reference (yet) to the feature you desire. What the original CDR-generating implementation allowed you to do was to create a syslog-based stream of CDRs similar to how transaction logging works in the acc module. Pumping that CDR stream into a database had to be done via an external process, however. Cheers, --Timo 20. huhtikuuta 2012 20.48 Timo Reimann s...@foo-lounge.de kirjoitti: Hey Pirjo, Am 20.04.2012 um 15:21 schrieb Pirjo Ahvenainen: Hi Karsten, Thanks for the tip, I do have that defined but no cdrs. cheers, Pirjo I haven't looked at the acc module in quite a while but to my knowledge, direct-to-DB storage of CDRs is still in the making. The second to last commit messages by Sven Knoblich (7b4567) mentions that the patch is necessary for the upcoming db-storage of cdr's. HTH, --Timo 20. huhtikuuta 2012 16.15 Karsten Horsmann khorsm...@gmail.com kirjoitti: Hi Pirijo, try #!define WITH_ACCDB in your kamailio.cfg -- Mit freundlichen Grüßen *Karsten Horsmann* ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] generating cdrs
Am 25.04.2012 um 21:00 schrieb Timo Reimann: Am 23.04.2012 um 22:57 schrieb Pirjo Ahvenainen: No prob, and thanks for your comments, I'm suspecting I had installed a devel version on the system I was testing before installing 3.2.3 and had used its db creation scripts. So what I will need to do is go back to testing the right version! ;) I installed a clean box with 3.2.3, no cdrs table vs. the one I had, I'll use that for devel version testing. Next job, I'll try it out with the devel version. So the cdr to db is on its way, the 3.2 documentation means saving only to syslog. Originally I associated this to the cdrs table I was staring at. I think I can call this myth busted! Admittedly, the docs could be a bit more clear on the fact that CDR generation doesn't involve database storage (yet). Being the original author, I'm the one to blame. :) I'll try to increase documentation accuracy of the acc module as soon as I can get to it. Done! (See commit caee2de.) HTH, --Timo 23. huhtikuuta 2012 18.15 Timo Reimann s...@foo-lounge.de kirjoitti: Hey Pirjo, sorry for the delay! Am 20.04.2012 um 20:05 schrieb Pirjo Ahvenainen: That would sort of make sense... Although, 'kamdbctl create' generates cdrs table along with all others, why have a table (+ 3.2 documentation), with nothing to populate that table in code? I cannot find any instances of the word cdr in any file of the util/kamctl and lib/ directories. Are you sure that there are CDR-related tables being created with that script? With regards to the acc documentation, there's no mentioning of any database storage as far as I can tell. I wrote the original piece of documentation, so unless someone has extended the code base and updated the docs there shouldn't be any reference (yet) to the feature you desire. What the original CDR-generating implementation allowed you to do was to create a syslog-based stream of CDRs similar to how transaction logging works in the acc module. Pumping that CDR stream into a database had to be done via an external process, however. Cheers, --Timo 20. huhtikuuta 2012 20.48 Timo Reimann s...@foo-lounge.de kirjoitti: Hey Pirjo, Am 20.04.2012 um 15:21 schrieb Pirjo Ahvenainen: Hi Karsten, Thanks for the tip, I do have that defined but no cdrs. cheers, Pirjo I haven't looked at the acc module in quite a while but to my knowledge, direct-to-DB storage of CDRs is still in the making. The second to last commit messages by Sven Knoblich (7b4567) mentions that the patch is necessary for the upcoming db-storage of cdr's. HTH, --Timo 20. huhtikuuta 2012 16.15 Karsten Horsmann khorsm...@gmail.com kirjoitti: Hi Pirijo, try #!define WITH_ACCDB in your kamailio.cfg -- Mit freundlichen Grüßen *Karsten Horsmann* ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] generating cdrs
Hey Pirjo, sorry for the delay! Am 20.04.2012 um 20:05 schrieb Pirjo Ahvenainen: That would sort of make sense... Although, 'kamdbctl create' generates cdrs table along with all others, why have a table (+ 3.2 documentation), with nothing to populate that table in code? I cannot find any instances of the word cdr in any file of the util/kamctl and lib/ directories. Are you sure that there are CDR-related tables being created with that script? With regards to the acc documentation, there's no mentioning of any database storage as far as I can tell. I wrote the original piece of documentation, so unless someone has extended the code base and updated the docs there shouldn't be any reference (yet) to the feature you desire. What the original CDR-generating implementation allowed you to do was to create a syslog-based stream of CDRs similar to how transaction logging works in the acc module. Pumping that CDR stream into a database had to be done via an external process, however. Cheers, --Timo 20. huhtikuuta 2012 20.48 Timo Reimann s...@foo-lounge.de kirjoitti: Hey Pirjo, Am 20.04.2012 um 15:21 schrieb Pirjo Ahvenainen: Hi Karsten, Thanks for the tip, I do have that defined but no cdrs. cheers, Pirjo I haven't looked at the acc module in quite a while but to my knowledge, direct-to-DB storage of CDRs is still in the making. The second to last commit messages by Sven Knoblich (7b4567) mentions that the patch is necessary for the upcoming db-storage of cdr's. HTH, --Timo 20. huhtikuuta 2012 16.15 Karsten Horsmann khorsm...@gmail.com kirjoitti: Hi Pirijo, try #!define WITH_ACCDB in your kamailio.cfg -- Mit freundlichen Grüßen *Karsten Horsmann* ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] generating cdrs
Hey Pirjo, Am 20.04.2012 um 15:21 schrieb Pirjo Ahvenainen: Hi Karsten, Thanks for the tip, I do have that defined but no cdrs. cheers, Pirjo I haven't looked at the acc module in quite a while but to my knowledge, direct-to-DB storage of CDRs is still in the making. The second to last commit messages by Sven Knoblich (7b4567) mentions that the patch is necessary for the upcoming db-storage of cdr's. HTH, --Timo 20. huhtikuuta 2012 16.15 Karsten Horsmann khorsm...@gmail.com kirjoitti: Hi Pirijo, try #!define WITH_ACCDB in your kamailio.cfg -- Mit freundlichen Grüßen *Karsten Horsmann* ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- -- Pirjo Ahvenainen +35844 559 7729 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio v3.2 problem with dialog module.
Hey Phillip,
Am 21.02.2012 um 07:50 schrieb Phillman25 Kyriacou:
Thanks for your prompt response.
I realized what i did wrong now, i had followed the guide you specified below
but i believe i may have entered the following command more than once:
INSERT INTO version (table_name, table_version) VALUES ('dialog_vars','1');
I found 4 entries in the mysql version table for dialog_vars. I then
removed the 3 entries and left only one and this worked. Now everything is ok.
Glad you figured out what the problem was!
Sorry to have troubled you and thank you for your support.
No worries -- by posting both the question and the answer you've done a great
service to upcoming generations. ;)
Cheers,
--Timo
On Mon, Feb 20, 2012 at 11:50 PM, Timo Reimann s...@foo-lounge.de wrote:
Hey,
Am 20.02.2012 um 15:10 schrieb Phillman25 Kyriacou:
After upgrading from V3.1.5 to V3.2. Kamailio crashes with the below error
messages:
Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core
[db.c:392]: invalid number of rows received: 4, dialog_vars
This one describes the actual error: invalid number of rows received.
Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core
[db.c:419]: querying version for table dialog_vars
Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: dialog
[dlg_db_handler.c:153]: error during dialog-vars version check.
Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: dialog
[dialog.c:646]: failed to initialize the DB support
Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core
[sr_module.c:932]: init_mod(): Error while initializing module dialog
(/usr/local/lib/kamailio/modules_k/dialog.so)
[snip!]
i realised that when i set the
modparam(dialog, db_mode, 0) kamailio starts fine, seems to be a
problem connecting to the database.
Does anyone know what is wrong?
Did you possibly miss to follow the upgrade guide
http://sip-router.org/wiki/install/3.1.x-to-3.2.x
particularly the part describing the changes required to the MySQL database
(given that you use MySQL)
http://sip-router.org/wiki/install/3.1.x-to-3.2.x#sql_commands
?
Dialog variables were introduced in 3.2. As they are used by default once you
enable db_mode, SIP-Router barks at you if missed generating the according
tables. Catch up on this and you should be fine.
HTH,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio v3.2 problem with dialog module.
Hey, Am 20.02.2012 um 15:10 schrieb Phillman25 Kyriacou: After upgrading from V3.1.5 to V3.2. Kamailio crashes with the below error messages: Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core [db.c:392]: invalid number of rows received: 4, dialog_vars This one describes the actual error: invalid number of rows received. Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core [db.c:419]: querying version for table dialog_vars Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: dialog [dlg_db_handler.c:153]: error during dialog-vars version check. Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: dialog [dialog.c:646]: failed to initialize the DB support Feb 20 16:43:59 sipproxy /usr/local/sbin/kamailio[11705]: ERROR: core [sr_module.c:932]: init_mod(): Error while initializing module dialog (/usr/local/lib/kamailio/modules_k/dialog.so) [snip!] i realised that when i set the modparam(dialog, db_mode, 0) kamailio starts fine, seems to be a problem connecting to the database. Does anyone know what is wrong? Did you possibly miss to follow the upgrade guide http://sip-router.org/wiki/install/3.1.x-to-3.2.x particularly the part describing the changes required to the MySQL database (given that you use MySQL) http://sip-router.org/wiki/install/3.1.x-to-3.2.x#sql_commands ? Dialog variables were introduced in 3.2. As they are used by default once you enable db_mode, SIP-Router barks at you if missed generating the according tables. Catch up on this and you should be fine. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well
Hey all, Am 31.01.2012 um 14:06 schrieb Timo Reimann: Am 31.01.2012 um 11:32 schrieb Marius Pedersen: On 01/31/2012 09:11 AM, Øyvind Kolbu wrote: On 2012-01-20 at 23:32, Timo Reimann wrote: Hi and sorry for the late response! Another possible root cause: After calling dlg_manage() on an INVITE, you do not forward the request (e.g., by calling exit() instead). Could that be the case? If so, the solution would be (again) to defer dialog tracking unless you're sure the INVITE will be routed. Thanks, this was indeed at least the main problem! We have no replaced a lot of sl_send_reply(123, message) with t_newtran() + t_reply(123,message) before exit(), and that solved most of the hanging dialogs. These were by the way hanging in state 1. If not, the last thing I can think of to try is to do some tracing (using ngrep or tcpdump, for example) and attempt to catch a dialog that dangles. If you succeed at that, analyzing the trace will probably help in determining the issue. We still have a few calls, probably one to two a day, which get stuck in state 4. They have proper INVITE, 200 OK and later BYE. We have tracked the problem down to that once in a while Asterisk, our bridge to PSTN, issues double INVITEs at the extact same time for the same call and in this case there seem to be a race within Kamailio. The call is properly setup and termitated, but the entry is still in the dialog table. Any ideas how to cope with the double INVITEs? We do btw use dlg_match_mode = 1, as we used that in Kamailio 1.5 and that worked like a charm. Have not tested altering it to either 0 or 2. Some extra information: We also still get some dialogs stuck in state 1 when we see these double invites (but the call is not set up due to busy, hang-up etc). For these events we also (always?) see one or more of these messages in the logs: CRITICAL: dialog [dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' CRITICAL: dialog [dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' Also sometimes event 8. This happens to a very small minority of calls (1% I'd guess). I'm currently in the process of investigating a dialog-related issue together with Uri (see CC). It may be related to your problem, so let's see if I can find something out that helps you as well. If not, I/we should take a dedicated look at your case. Unfortunately, I'm currently short on time so I cannot give any guarantees as to when I'll find the time to get to these dialog-related things. I promise to get back to you folks ASAP though, so please hang on. Uri's issue was fixed in the master branch. I don't think it has anything to do with your case, however. Before getting back to you in detail: Is the problem still persisting? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well
Sorry I missed to see that this thread was already in full action and Daniel got catched on... Cheers, --Timo Am 20.02.2012 um 22:55 schrieb Timo Reimann: Hey all, Am 31.01.2012 um 14:06 schrieb Timo Reimann: Am 31.01.2012 um 11:32 schrieb Marius Pedersen: On 01/31/2012 09:11 AM, Øyvind Kolbu wrote: On 2012-01-20 at 23:32, Timo Reimann wrote: Hi and sorry for the late response! Another possible root cause: After calling dlg_manage() on an INVITE, you do not forward the request (e.g., by calling exit() instead). Could that be the case? If so, the solution would be (again) to defer dialog tracking unless you're sure the INVITE will be routed. Thanks, this was indeed at least the main problem! We have no replaced a lot of sl_send_reply(123, message) with t_newtran() + t_reply(123,message) before exit(), and that solved most of the hanging dialogs. These were by the way hanging in state 1. If not, the last thing I can think of to try is to do some tracing (using ngrep or tcpdump, for example) and attempt to catch a dialog that dangles. If you succeed at that, analyzing the trace will probably help in determining the issue. We still have a few calls, probably one to two a day, which get stuck in state 4. They have proper INVITE, 200 OK and later BYE. We have tracked the problem down to that once in a while Asterisk, our bridge to PSTN, issues double INVITEs at the extact same time for the same call and in this case there seem to be a race within Kamailio. The call is properly setup and termitated, but the entry is still in the dialog table. Any ideas how to cope with the double INVITEs? We do btw use dlg_match_mode = 1, as we used that in Kamailio 1.5 and that worked like a charm. Have not tested altering it to either 0 or 2. Some extra information: We also still get some dialogs stuck in state 1 when we see these double invites (but the call is not set up due to busy, hang-up etc). For these events we also (always?) see one or more of these messages in the logs: CRITICAL: dialog [dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' CRITICAL: dialog [dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' Also sometimes event 8. This happens to a very small minority of calls (1% I'd guess). I'm currently in the process of investigating a dialog-related issue together with Uri (see CC). It may be related to your problem, so let's see if I can find something out that helps you as well. If not, I/we should take a dedicated look at your case. Unfortunately, I'm currently short on time so I cannot give any guarantees as to when I'll find the time to get to these dialog-related things. I promise to get back to you folks ASAP though, so please hang on. Uri's issue was fixed in the master branch. I don't think it has anything to do with your case, however. Before getting back to you in detail: Is the problem still persisting? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sipp issues with dialog module
Am 07.02.2012 um 17:13 schrieb Uri Shacked: anyone knows why the dialog module leaves active dialogs even after a bye was recieved when using sipp? once i had issues with the record route and i forced sipp to deal with that, is there something to set on the bye sent by sipp? From my experience, it's quite tricky to please the dialog module using sipp. Not because of the dialog module but because of sipp which needs some fine-tuning from a dialog perspective. My BYE message emitted from sipp looks something like this: send ![CDATA[ BYE [next_url] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] [routes] From: sip:[service]@[local_ip];tag=[call_number] To: sip:[field0]@[remote_ip][peer_tag_param] Call-ID: [call_id] CSeq: [cseq] BYE Contact: sip:[service]@127.0.0.1:[local_port] Max-Forwards: 70 Subject: Conversation over Content-Length: 0 ]] /send If that's not helpful enough, my suggestion is to take a working (i.e., dialog-conforming) real-world call and try to match your sipp scenario gradually. That is, you should verify for each message in the sipp call flow whether it produces the very same dialog state generated by the mirroring real-world call flow. If it fails to do so with some message, compare the sipp/real message line by line and try to match further. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well
Hi, Am 31.01.2012 um 11:32 schrieb Marius Pedersen: On 01/31/2012 09:11 AM, Øyvind Kolbu wrote: On 2012-01-20 at 23:32, Timo Reimann wrote: Hi and sorry for the late response! Another possible root cause: After calling dlg_manage() on an INVITE, you do not forward the request (e.g., by calling exit() instead). Could that be the case? If so, the solution would be (again) to defer dialog tracking unless you're sure the INVITE will be routed. Thanks, this was indeed at least the main problem! We have no replaced a lot of sl_send_reply(123, message) with t_newtran() + t_reply(123,message) before exit(), and that solved most of the hanging dialogs. These were by the way hanging in state 1. If not, the last thing I can think of to try is to do some tracing (using ngrep or tcpdump, for example) and attempt to catch a dialog that dangles. If you succeed at that, analyzing the trace will probably help in determining the issue. We still have a few calls, probably one to two a day, which get stuck in state 4. They have proper INVITE, 200 OK and later BYE. We have tracked the problem down to that once in a while Asterisk, our bridge to PSTN, issues double INVITEs at the extact same time for the same call and in this case there seem to be a race within Kamailio. The call is properly setup and termitated, but the entry is still in the dialog table. Any ideas how to cope with the double INVITEs? We do btw use dlg_match_mode = 1, as we used that in Kamailio 1.5 and that worked like a charm. Have not tested altering it to either 0 or 2. Some extra information: We also still get some dialogs stuck in state 1 when we see these double invites (but the call is not set up due to busy, hang-up etc). For these events we also (always?) see one or more of these messages in the logs: CRITICAL: dialog [dlg_hash.c:650]: bogus event 6 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' CRITICAL: dialog [dlg_hash.c:650]: bogus event 7 in state 1 for dlg 0xb5e88dc4 [2445:97666510] with clid '2adcd4b23355a3aa3a4ae5a73fe72631@pstn-gateway-ip' and tags 'as485e20a7' '' Also sometimes event 8. This happens to a very small minority of calls (1% I'd guess). I'm currently in the process of investigating a dialog-related issue together with Uri (see CC). It may be related to your problem, so let's see if I can find something out that helps you as well. If not, I/we should take a dedicated look at your case. Unfortunately, I'm currently short on time so I cannot give any guarantees as to when I'll find the time to get to these dialog-related things. I promise to get back to you folks ASAP though, so please hang on. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] unable to find dialog for ACK with route param
Hey, Am 23.01.2012 um 11:13 schrieb Uri Shacked: i use the dialog module. i create the dialog using dlg_manage() right after the invite is recieved. in a case where the final destination rejects the call (486 busy), i get the following error: WARNING: dialog [dlg_handlers.c:1054]: unable to find dialog for ACK with route param. i guess the dialog module deletes the dialog on the 486 reply and gives me this erro when an ACK for the 486 is recieved from the caller... No, the module shouldn't behave like that. IIRC, a terminating dialog is tied to its underlying transaction and should stay alive until the transaction times out. Does each ACK message include a proper dialog ID (i.e., To-tag, From-tag, and Call-ID corresponding to the 486 message)? Is the ACK routed statefully at all? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Who can tell me how to get the dialog-based CDRs ?
Hey,
Am 21.12.2011 um 07:03 schrieb sunny_day:
My object:get the dialog-based CDRs
SIP proxy: kamailio-3.2.0
My script:
loadmodule dialog.so
..
modparam(dialog,dlg_flag,4)#Must be set to create the dialog associated
to an initial request.
modparam(dialog,db_url,mysql://xxx:xxx@localhost/albert)
modparam(dialog,table_name,dialog)
...
request_route{
if( is_method(INVITE) !has_totag())
{
dlg_setflag(4);
dlg_var(start_time)=$TS;
dlg_var(caller)=$fU;
dlg_var(caller)=$tU;
}
dlg_manage();
..
# dispatch destinations to PSTN
route(PSTN);
# user location service
route(LOCATION);
route(RELAY);
}
.
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method(BYE)) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
sql_query(cd, insert into
cdr(caller,callee,start_time,duration)
values($dlg_var(caller),$dlg_var(callee),$dlg_var(start_time),$DLG_lifetime),
rd);
sql_result_free(rd);
}
if (is_method(ACK)) {
route(NATMANAGE); # ACK is forwarded statelessy
}
route(RELAY);
}
My issue is :
The dialog records can be wrritten into the dialog table. But , the
sql_query can not executed. So the cdr table will not get the CDRs. I don't
know why. Who can help me ?
This is a simple script for testing.
Any suggestion will be appreciated.
Thank you in advance.
It's very hard to help with any Kamailio error unless you provide the actual
error message. Whatever the issue is with the sqlops module, Kamailio will tell
you, so please tell us.
Until then, I can only speculate what's gone wrong: Did you possibly forget to
specify the sqlcon module parameter? You need to setup the MySQL connection
parameters in there. See
http://sip-router.org/docbook/sip-router/branch/master/modules_k/sqlops/sqlops.html#id2793249
for sqlcon's documentation and
http://sip-router.org/docbook/sip-router/branch/master/modules_k/sqlops/sqlops.html#id2794430
for the reference regarding sql_query(). Please note how that part states that
the result parameter should normally only be omitted when no result is
expected (INSERT, UPDATE, DELETE) (which is the case in your test script). In
consequence, you won't need to free the result set which could be another
source of error.
Finally, please note that the dialog module itself is capable of producing CDRs
directly from the dialog machinery. It's yet lacking support for direct output
to a database (AFAIK), however, so you'd have to post-process the CDR results
(which are being written to file as of now) in order to get them persisted into
a database.
For some reason, the CDR documentation I wrote seems to have disappeared from
the git repository. I'll investigate that further and provide you with a link
to the dialog-way-of-creating-CDRs when available (and desired from your side).
HTH,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Who can tell me how to get the dialog-based CDRs ?
Hey there,
I added the list to CC as others may be interested in your findings as well.
sunny_day 416415...@qq.com schrieb:
Thank you very much for your detailed analysis !
According to your analysis I have been getting more understand the
kamailio. :-)
After submitting the issue, I have done many experiments. And now, I
may find the reason about my script.
1. somebody seems like having said dialog is tracing and dealed with
after loose_route()--(May be I didn't understand it correctly. And now
I am also not sure the relationship between dialog and loose_route() ).
And the dialog will be destroyed after receiving the BYE message.
So, I place the insert after loose_route() and is_method(BYE) .
--it may have problem.
Calling loose_route() makes sure that for a given sequential request (which
includes BYE messages) it is properly linked to its dialog. This is carried out
by either adding cookies to Route headers or trying to match the
dialog-identifying SIP headers (From-Tag, To-Tag, and Call-ID).
This so-called matching mode is set to DID only which corresponds to using
cookies in Route headers. For this to work, you must ensure that calls are
being enriched with Record-Route headers. So one possible reason why things
didn't work for you is that you used DID only matching mode (which you
apparently did as you configuration didn't deviate from the default) but forgot
to add Record-Route headers. Alternatively, you could set matching mode to 2
(SIP header-based matching only) or 1 (cookie-based but fallback to
header-based) to get things going dialog-wise.
See the dlg_match_mode modparam documentation here:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dialog.html#id2580386
.
The main reason insert can not insert the data into cdr table is
loose_route() returns 0, which has no Route: header , and the
insert will never be executed.
Which may be the case because you did not instruct Kamailio to add Record-Route
headers along the signaling way.
2. At last, I place the insert in the route(RELAY);. And data can
be inserted into the cdr table again. Originally, I was considering the
dialog will be destroyed immediately when then BYE message received.
The results of my experiments prove that it isn't. But I am not sure
whether my conclusion is right.
In the old days, dialogs would indeed be destroyed as soon as the transaction
correlating to the first BYE request was deleted. This was changed a while in
ago in order to be able to handle responses to such BYE requests too. So these
days, dialogs do not get destroyed until a BYE-completing response is seen.
(More specifically, until the transaction related to a BYE-completing response
is terminated. Or, if that BYE request never sees a response and its
transaction times out, whichever comes first. But that's just details.)
You probably shouldn't be satisfied with updating database entries during
route[RELAY] (at least not only). If it's not working on processing of a final
BYE request, this indicates that dialog tracking isn't properly working for you
(see my explanation above as to why). Whatever you store in dialog variables
during an INVITE may not be valid by the time you persist to database.
And regarding CDR generation using Kamailio's built-in mechanism: It's part of
the acc (accounting) module (not dialog as I initially claimed). You may want
to look at the documentation to see if it's a fit for you:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/acc/acc.html#id3041546
HTH,
--Timo
-- Original --
From: Timo Reimanns...@foo-lounge.de;
Date: Wed, Dec 21, 2011 06:51 PM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing Listsr-users@lists.sip-router.org;
Cc: sunny_day416415...@qq.com;
Subject: Re: [SR-Users] Who can tell me how to get the dialog-based
CDRs ?
Hey,
Am 21.12.2011 um 07:03 schrieb sunny_day:
My object:get the dialog-based CDRs
SIP proxy: kamailio-3.2.0
My script:
loadmodule dialog.so
..
modparam(dialog,dlg_flag,4)#Must be set to create the dialog
associated to an initial request.
modparam(dialog,db_url,mysql://xxx:xxx@localhost/albert)
modparam(dialog,table_name,dialog)
...
request_route{
if( is_method(INVITE) !has_totag())
{
dlg_setflag(4);
dlg_var(start_time)=$TS;
dlg_var(caller)=$fU;
dlg_var(caller)=$tU;
}
dlg_manage();
..
# dispatch destinations to PSTN
route(PSTN);
# user location service
route(LOCATION);
route(RELAY);
}
.
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method(BYE)) {
setflag(FLT_ACC); # do accounting ...
Re: [SR-Users] Bug: Dialog State=*Teminated* even when the call is active
Hey, Am 15.12.2011 um 23:29 schrieb Gnaneshwar Gatla: Please find the attached patch. This patch was already submitted to Kamailio 3.1.5 by Timo Reimann. The patch was designed that if “override_lifetime” is not used, the value of the expires is taken from dialog module. FS#159 - Default expires value in dialog-info. As mentioned by myself in the Flyspray issue, the patch is already part of 3.1, 3.2, and master branch. So there's no need to re-apply the patch. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] tracking ACC for a 486
Hey Sven, Am 10.11.2011 um 11:48 schrieb Sven Knoblich: Hi, I have a short question regarding a tm callback. I want to track a local generated ACK during a cfa. scenario: A calls B with a cfa to C B response with a 486 Busy this will be confirmed with an ACK. I saw, that TMCB_ACK_NEG_IN will only be called when a new transaction is created (t_lookup.c:t_newtran). Unfortunately in this case an ACK will be send directly when a reply will be received (t_reply.c:reply_received). Any ideas? Lass mich raten -- TKÜV? Das war noch einer der Punkte, den ich vor meinem Austritt fertig kriegen wollte -- hat leider aus Zeitgründen nicht geklappt. Meine, ich hätte damals Marius eine Mail mit ein paar (wenigen) Infos zukommen lassen. Wenn ich nicht völlig irre, liegt im ui-kamailio-Repository bereits ein Patch, der genau die gewünschte Funktion für 1.5 umsetzt. Es verbleibt damit also, den Patch irgendwie nach SIP-Router zu forward-porten. Wenn du mir den 1.5er Patch zukommen lässt, kann ich auch gerne mal einen Blick drauf werfen. Außerdem liegt im upstream-git-Repository ein Branch von mir, der bereits einige fehlende Callbacks für 3.x enthält (darüber hatte Marius definitiv eine E-Mail von mir erhalten). Es wäre sehr sinnig, diesen Branch um die fehlende TMCB_ACK_NEG_IN-Sache zu ergänzen, damit wir das Ganze danach in den master-Branch committen können. In jedem Fall viel Erfolg und viele Grüße, --Timo PS: Grüße an alle. Hoffe, es läuft rund bei euch. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] tracking ACC for a 486
Sorry everybody, this was supposed to be directed at Sven only! (Hit reply accidentally :( ) --Timo Am 11.11.2011 um 00:54 schrieb Timo Reimann: Hey Sven, Am 10.11.2011 um 11:48 schrieb Sven Knoblich: Hi, I have a short question regarding a tm callback. I want to track a local generated ACK during a cfa. scenario: A calls B with a cfa to C B response with a 486 Busy this will be confirmed with an ACK. I saw, that TMCB_ACK_NEG_IN will only be called when a new transaction is created (t_lookup.c:t_newtran). Unfortunately in this case an ACK will be send directly when a reply will be received (t_reply.c:reply_received). Any ideas? Lass mich raten -- TKÜV? Das war noch einer der Punkte, den ich vor meinem Austritt fertig kriegen wollte -- hat leider aus Zeitgründen nicht geklappt. Meine, ich hätte damals Marius eine Mail mit ein paar (wenigen) Infos zukommen lassen. Wenn ich nicht völlig irre, liegt im ui-kamailio-Repository bereits ein Patch, der genau die gewünschte Funktion für 1.5 umsetzt. Es verbleibt damit also, den Patch irgendwie nach SIP-Router zu forward-porten. Wenn du mir den 1.5er Patch zukommen lässt, kann ich auch gerne mal einen Blick drauf werfen. Außerdem liegt im upstream-git-Repository ein Branch von mir, der bereits einige fehlende Callbacks für 3.x enthält (darüber hatte Marius definitiv eine E-Mail von mir erhalten). Es wäre sehr sinnig, diesen Branch um die fehlende TMCB_ACK_NEG_IN-Sache zu ergänzen, damit wir das Ganze danach in den master-Branch committen können. In jedem Fall viel Erfolg und viele Grüße, --Timo PS: Grüße an alle. Hoffe, es läuft rund bei euch. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] segmentation fault in init_mod_child function
Hey Bruno, Am 09.11.2011 um 20:31 schrieb Bruno Bresciani: Kamailio 3.1.2 terminated with signal 11, segmentation fault, in the init_mod_child function at sr_module.c file. This problem occurs only when I try loading the loadbalance.so module, it was written by me. Someone Can help me to understand why this segmentation fault was generated? There are two other module written by me and this problem doesn't happen. Kamailio's trace: 9(27616) DEBUG: db_postgres [km_pg_con.c:80]: PQsetdbLogin(0x8db2878) 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): sl 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): auth_db 9(27616) DEBUG: core [db.c:294]: connection 0x82f4108 found in pool 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): usrloc 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): mi_fifo 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): registrar 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): nathelper 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): permissions 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): loadbalance 9(27616) DEBUG: loadbalance [loadbalance_mod.c:271]: loadbalance: child started! (5) 9(27616) DEBUG: core [sr_module.c:828]: DEBUG: init_mod_child (5): route 0(27582) ALERT: core [main.c:741]: child process 27585 exited by a signal 11 0(27582) ALERT: core [main.c:744]: core was generated 0(27582) INFO: core [main.c:756]: INFO: terminating due to SIGCHLD 8(27615) INFO: core [main.c:807]: INFO: signal 15 received 8(27615) DEBUG: core [main.c:818]: Memory status (pkg): 8(27615) DEBUG: fm_status: fm_status (0x82aefc0): 8(27615) DEBUG: fm_status: heap size= 4194304 8(27615) DEBUG: fm_status: used= 236720, used+overhead=264064, free=3930240 8(27615) DEBUG: fm_status: max used (+overhead)= 299824 8(27615) DEBUG: fm_status: dumping free list: 8(27615) DEBUG: fm_status: hash = 1 fragments no.:27, unused: 0 bucket size: 8 - 8 (first 8) 8(27615) DEBUG: fm_status: hash = 44 fragments no.: 1, unused: 0 bucket size: 352 - 352 (first 352) 8(27615) DEBUG: fm_status: hash = 74 fragments no.: 1, unused: 0 bucket size: 592 - 592 (first 592) 8(27615) DEBUG: fm_status: hash = 77 fragments no.: 1, unused: 0 bucket size: 616 - 616 (first 616) 8(27615) DEBUG: fm_status: hash = 81 fragments no.: 1, unused: 0 bucket size: 648 - 648 (first 648) 8(27615) DEBUG: fm_status: hash = 84 fragments no.: 1, unused: 0 bucket size: 672 - 672 (first 672) 8(27615) DEBUG: fm_status: hash = 113 fragments no.:51, unused: 0 bucket size: 904 - 904 (first 904) 8(27615) DEBUG: fm_status: hash = 2056 fragments no.: 1, unused: 0 gdb bt full trace: Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/route.so...done. Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/route.so Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/rtpproxy.so...done. Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/rtpproxy.so Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/tls.so...done. Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/tls.so Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/perms_db.so...done. Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/perms_db.so Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Core was generated by `/home2/local/kamailio/sbin/kamailio -P /var/run/kamailio.pid'. Program terminated with signal 11, Segmentation fault. #0 init_mod_child (m=0xa238, rank=2) at sr_module.c:827 827 sr_module.c: Arquivo ou diretório não encontrado. in sr_module.c (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) bt full #0 init_mod_child (m=0xa238, rank=2) at sr_module.c:827 No locals. #1 0x in ?? () No symbol table info available. (gdb) The address of the m struct in init_mod_child looks awkward. Although it's non-null, it's probably not within the validity range of the process's address space, thereby causing a segfault. You can verify this by investigating the coredump in gdb and printing m's content with print m. If my assumption holds, try figuring out why m became messy in the first place. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org
Re: [SR-Users] Kamailio 3.2 Acc Runtime error
Hey Nathaniel, Am 05.11.2011 um 02:11 schrieb Nathaniel L Keeling: I am getting this error when I start kamailio 3.2 on Solaris 10. Any direction on solving this would be greatly appreciated. ERROR: load_module: could not open module /opt/kamailio-3.2/lib64/kamailio/modules_k/acc.so: ld.so.1: kamailio: fatal: relocation error: file /opt/kamailio-3.2/lib64/kamailio/modules_k/acc.so: symbol timersub: referenced symbol not found Should work now in latest 3.2 and master. If not, I'll get back to this tomorrow. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog / BYE
Hey Brandon, Am 02.11.2011 um 22:13 schrieb Brandon Armstead: It is not equivalent. Essentially what I see happening is the BYE packet just comes in - however Kamailio does nothing with it. It is not relayed - simply nothing at all happens, on a network level I just see the BYE coming into the Kamailio proxy and zero response or reaction from Kamailio. So for some reason Kamailio decides that it will not forward the package, possibly because it cannot determine the next hop. Can you increase debug verbosity on the dropping Kamailio and see what it has to say with respect to the scenario in question? By the way, may I assume that you are sending BYE requests on an established call, i.e., one where the SIP handshake (INVITE/200/ACK) has already concluded successfully? Cheers, --Timo On Wed, Nov 2, 2011 at 2:04 PM, Timo Reimann s...@foo-lounge.de wrote: Hey, Am 02.11.2011 um 08:24 schrieb Brandon Armstead: Some interesting results indeed. If I place the same block of code with or without dlg_get first then dlg_bye AFTER loose_route -- kamailio ignores the packet. If I place it before loose_route WITH dlg_get FIRST - it works as expected. What do you mean by kamailio ignores the packet? Is this equivalent to what you described initially regarding dialogs that were terminated single-sided only? Cheers, --Timo On Tue, Nov 1, 2011 at 4:42 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 02.11.2011 um 00:32 schrieb Brandon Armstead: Thats correct - however I am calling this before loose_route, perhaps that is my problem and need for calling dlg_get? Let me give this a go - and I will respond back with my findings, thanks! Yeah, that should be it -- linking to the currently active dialog is being implemented as a callback to record-routed messages which takes place after a call to loose_route(). Looking forward to hearing your findings. :) Cheers, --Timo On Tue, Nov 1, 2011 at 4:21 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 01.11.2011 um 23:44 schrieb Brandon Armstead: Thank you for the input - I actually just figured out a resolution. Apparently dlg_bye(all) must be called after dlg_get - so what I'm doing now is simply checking for request with a special request uri with the callid / from tag / to tag in the request that correlates to the call I desire to terminate. I am then feeding $ci, $tt, and $ft into dlg_get and then calling dlg_bye(all) - in which Kamailio then proceeds to send BYE out to both legs of the call. I think we can mark this as resolved :). OK, very good. :) Let me make sure that this isn't a dialog module bug: You are now calling dlg_get() followed by dlg_bye() with proper parameters from within the Kamailio configuration script? if so, you shouldn't need to call dlg_get() in the first place, at least not if you place dlg_bye() after the call to loose_route(). Contrary, using certain dialog features (including dlg_bye()) from reply routes isn't completely possible yet which could explain your findings. Cheers, --Timo On Tue, Nov 1, 2011 at 3:21 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 01.11.2011 um 22:48 schrieb Brandon Armstead: I am attempting to tear down a call with a BYE packet generated externally (kind of similar to Kamailio fifo dlg_end_dlg). Let me describe what I am trying to do in more depth and then I will continue to tell you the problem I think I am experiencing. [PSTN SIP Proxy] - [CORE SIP Proxy] - [REGISTRAR] - [UAC] So the above layout is the normal call flow / structure of calls (incoming when originating from pstn) (outgoing when originating from uac). I then have an external host - I am attempting to generate a BYE to [CORE SIP Proxy] and have it go both directions [PSTN] + [UAC]. So far I am able to get the call to tear down in only a single direction (only kill call with PSTN) or (only kill call with UAC). I have not been able to kill both legs of the call. [snip] My Question - what am I doing wrong - or what is the best method to tackle this task? If I get you right you are trying to emulate Kamailio's dlg_end_dlg functionality without involving Kamailio at all (except for passing forward the BYE requests). This makes your question sort of off-topic as processing BYE requests is a matter of RFC 3261 alone. Apart from that, what you could do is take a look at the dialog module code and check how it implements dlg_end_dlg. An idea I have what you could possibly be doing wrong is not using the CSeq numbers that each party expects. I don't have the details at hand but if either CSeq
Re: [SR-Users] Dialog / BYE
Hey Brandon, Am 01.11.2011 um 22:48 schrieb Brandon Armstead: I am attempting to tear down a call with a BYE packet generated externally (kind of similar to Kamailio fifo dlg_end_dlg). Let me describe what I am trying to do in more depth and then I will continue to tell you the problem I think I am experiencing. [PSTN SIP Proxy] - [CORE SIP Proxy] - [REGISTRAR] - [UAC] So the above layout is the normal call flow / structure of calls (incoming when originating from pstn) (outgoing when originating from uac). I then have an external host - I am attempting to generate a BYE to [CORE SIP Proxy] and have it go both directions [PSTN] + [UAC]. So far I am able to get the call to tear down in only a single direction (only kill call with PSTN) or (only kill call with UAC). I have not been able to kill both legs of the call. [snip] My Question - what am I doing wrong - or what is the best method to tackle this task? If I get you right you are trying to emulate Kamailio's dlg_end_dlg functionality without involving Kamailio at all (except for passing forward the BYE requests). This makes your question sort of off-topic as processing BYE requests is a matter of RFC 3261 alone. Apart from that, what you could do is take a look at the dialog module code and check how it implements dlg_end_dlg. An idea I have what you could possibly be doing wrong is not using the CSeq numbers that each party expects. I don't have the details at hand but if either CSeq number is off your UAs won't accept the BYE request. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog / BYE
Hey Brandon, Am 01.11.2011 um 23:44 schrieb Brandon Armstead: Thank you for the input - I actually just figured out a resolution. Apparently dlg_bye(all) must be called after dlg_get - so what I'm doing now is simply checking for request with a special request uri with the callid / from tag / to tag in the request that correlates to the call I desire to terminate. I am then feeding $ci, $tt, and $ft into dlg_get and then calling dlg_bye(all) - in which Kamailio then proceeds to send BYE out to both legs of the call. I think we can mark this as resolved :). OK, very good. :) Let me make sure that this isn't a dialog module bug: You are now calling dlg_get() followed by dlg_bye() with proper parameters from within the Kamailio configuration script? if so, you shouldn't need to call dlg_get() in the first place, at least not if you place dlg_bye() after the call to loose_route(). Contrary, using certain dialog features (including dlg_bye()) from reply routes isn't completely possible yet which could explain your findings. Cheers, --Timo On Tue, Nov 1, 2011 at 3:21 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 01.11.2011 um 22:48 schrieb Brandon Armstead: I am attempting to tear down a call with a BYE packet generated externally (kind of similar to Kamailio fifo dlg_end_dlg). Let me describe what I am trying to do in more depth and then I will continue to tell you the problem I think I am experiencing. [PSTN SIP Proxy] - [CORE SIP Proxy] - [REGISTRAR] - [UAC] So the above layout is the normal call flow / structure of calls (incoming when originating from pstn) (outgoing when originating from uac). I then have an external host - I am attempting to generate a BYE to [CORE SIP Proxy] and have it go both directions [PSTN] + [UAC]. So far I am able to get the call to tear down in only a single direction (only kill call with PSTN) or (only kill call with UAC). I have not been able to kill both legs of the call. [snip] My Question - what am I doing wrong - or what is the best method to tackle this task? If I get you right you are trying to emulate Kamailio's dlg_end_dlg functionality without involving Kamailio at all (except for passing forward the BYE requests). This makes your question sort of off-topic as processing BYE requests is a matter of RFC 3261 alone. Apart from that, what you could do is take a look at the dialog module code and check how it implements dlg_end_dlg. An idea I have what you could possibly be doing wrong is not using the CSeq numbers that each party expects. I don't have the details at hand but if either CSeq number is off your UAs won't accept the BYE request. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Presence Dialog not being created
Hey Gnaneshwar, sorry for not replying for such a long time. Real life has been keeping me busy. :) Am 25.10.2011 um 03:04 schrieb Gnaneshwar Gatla: I have installed the patch to the kamailio source and compiled it. Thing is it does work fine to create a presentity with the obtaining the dialog-expires from the session created. It drops down to the one last problem. The presentity information is not deleted when the user hangs-up even before the dialog-expires. This presence is maintained until the Exipres timer, for my x-lite client that's 7200secs. I have attached the log about this scenario. Without knowing too much about pua_dialoginfo, I can tell from your logs that no dialog termination was observed, therefore no terminated state was published. Are you possibly not running completely stateful dialogs, e.g., replying statelessly to INVITE requests? The dialog module cannot handle such cases yet, you need to be stateful all the times. Cheers, --Timo -Original Message- From: Timo Reimann [mailto:s...@foo-lounge.de] Sent: Saturday, October 22, 2011 2:12 AM To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Cody Herzog; Gnaneshwar Gatla Subject: Re: [SR-Users] Presence Dialog not being created Hello Gnaneshwar, Am 21.10.2011 um 22:57 schrieb Gnaneshwar Gatla: Kamailio version: 3.1.5 I have been trying to use presence for Event:Dialog. I have used PUA_Dialoginfo module to accomplish this task. The PUA_dialoginfo module states that if override_lifetime is not used, the value of the expires is taken from dialog module. I have tried the module without the override_lifetime which did not create the dialog in the presentity. When used debug, I did see the xml being generated but finds the dialog expires=0 and deletes the xml(please find the log below). How do I get this module working without the override_lifetime being used. The problem seems to stem from the dialog module: Apparently, all dialog parameters (including lifetime) are set during the creation of a dialog only after create callbacks have been executed. This is why a lifetime of zero is always available to callback functions, including the one from pua_dialoginfo, no matter what the configured lifetime is. I have created a little patch for 3.1 that changes the dialog module such that dialog variables are set prior to calling creation callbacks. It's attached in this email -- would you mind giving it a try and see if it helps? In order to apply the patch, all you need to do is check out the 3.1 branch (unless you already did so) doing git clone --depth 1 -b 3.1 git://git.sip-router.org/sip-router sip-router and apply the patch inside that directory like this: cd sip-router patch -p 1 /patch/to/patch Now recompile and run as usual. Please let me know if things work now. Thanks a lot and cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog / BYE
Hey Brandon, Am 02.11.2011 um 00:32 schrieb Brandon Armstead: Thats correct - however I am calling this before loose_route, perhaps that is my problem and need for calling dlg_get? Let me give this a go - and I will respond back with my findings, thanks! Yeah, that should be it -- linking to the currently active dialog is being implemented as a callback to record-routed messages which takes place after a call to loose_route(). Looking forward to hearing your findings. :) Cheers, --Timo On Tue, Nov 1, 2011 at 4:21 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 01.11.2011 um 23:44 schrieb Brandon Armstead: Thank you for the input - I actually just figured out a resolution. Apparently dlg_bye(all) must be called after dlg_get - so what I'm doing now is simply checking for request with a special request uri with the callid / from tag / to tag in the request that correlates to the call I desire to terminate. I am then feeding $ci, $tt, and $ft into dlg_get and then calling dlg_bye(all) - in which Kamailio then proceeds to send BYE out to both legs of the call. I think we can mark this as resolved :). OK, very good. :) Let me make sure that this isn't a dialog module bug: You are now calling dlg_get() followed by dlg_bye() with proper parameters from within the Kamailio configuration script? if so, you shouldn't need to call dlg_get() in the first place, at least not if you place dlg_bye() after the call to loose_route(). Contrary, using certain dialog features (including dlg_bye()) from reply routes isn't completely possible yet which could explain your findings. Cheers, --Timo On Tue, Nov 1, 2011 at 3:21 PM, Timo Reimann s...@foo-lounge.de wrote: Hey Brandon, Am 01.11.2011 um 22:48 schrieb Brandon Armstead: I am attempting to tear down a call with a BYE packet generated externally (kind of similar to Kamailio fifo dlg_end_dlg). Let me describe what I am trying to do in more depth and then I will continue to tell you the problem I think I am experiencing. [PSTN SIP Proxy] - [CORE SIP Proxy] - [REGISTRAR] - [UAC] So the above layout is the normal call flow / structure of calls (incoming when originating from pstn) (outgoing when originating from uac). I then have an external host - I am attempting to generate a BYE to [CORE SIP Proxy] and have it go both directions [PSTN] + [UAC]. So far I am able to get the call to tear down in only a single direction (only kill call with PSTN) or (only kill call with UAC). I have not been able to kill both legs of the call. [snip] My Question - what am I doing wrong - or what is the best method to tackle this task? If I get you right you are trying to emulate Kamailio's dlg_end_dlg functionality without involving Kamailio at all (except for passing forward the BYE requests). This makes your question sort of off-topic as processing BYE requests is a matter of RFC 3261 alone. Apart from that, what you could do is take a look at the dialog module code and check how it implements dlg_end_dlg. An idea I have what you could possibly be doing wrong is not using the CSeq numbers that each party expects. I don't have the details at hand but if either CSeq number is off your UAs won't accept the BYE request. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to limit maximum number of calls
Hey, Am 28.10.2011 um 07:29 schrieb Austin Einter: I did change kamailio.cfg as below and getting some error. [snip] When I start the kamailio proxy I get below error. [root@www1 kamailio]# [root@www1 kamailio]# kamailio -T -E -n 1 -l 174.37.8.178 -l 127.0.0.1 -W epoll_et -l udp:174.37.8.178:26588 loading modules under /usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/ Listening on udp: 174.37.8.178:26588 udp: 127.0.0.1:26588 Aliases: udp: localhost:26588 udp: localhost.localdomain:26588 udp: 174.37.8.178-static.reverse.softlayer.com:26588 0(26959) INFO: usrloc [hslot.c:53]: locks array size 512 0(26959) ERROR: dialog [dialog.c:435]: no dlg flag set!! 0(26959) ERROR: core [sr_module.c:875]: init_mod(): Error while initializing module dialog (/usr/local/lib/kamailio/modules_k/dialog.so) ERROR: error while initializing modules [root@www1 kamailio]# [root@www1 kamailio]# It looks , dialog module facing problem during initialization. I am bit new to this, not getting any clue . Kindly let me know whats going wrong. no dlg flag set Using the dialog module requires either one of the following for each dialog you wish to track: - Set a certain flag. This tells the dialog module to start tracking. It only works for INVITE requests though and requires specifying the desired dialog flag as a modparam. - Call dlg_manage(). This also tells the dialog module to start tracking but may be called from non-INVITE requests too (at least theoretically; I never tried). Unfortunately, the wiki docs regarding the dialog module seem to be broken right now, so I cannot point you at the specific syntax. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] module docs broken
Hey, documentation on the dialog module seems to be broken: The master branch directory content is empty http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/ 3.1 shows close to nothing http://sip-router.org/docbook/sip-router/branch/3.1/modules_k/dialog/dialog.html Moreover, 3.0 gives me 404 on the entire modules_k path: http://sip-router.org/docbook/sip-router/branch/3.0/modules_k/ Help. :) Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] new email contact
Hey all, this is just to let everybody know that my email contact has changed to s...@foo-lounge.de . Of course, I'm still on the lists but if anyone aware of my former email address wishes to contact me directly, please refer to the new address in the future. Thanks a lot and cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] module docs broken
Hey Daniel, Am 28.10.2011 um 21:25 schrieb Daniel-Constantin Mierla: On 10/28/11 11:41 AM, Timo Reimann wrote: Hey, documentation on the dialog module seems to be broken: The master branch directory content is empty http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/ 3.1 shows close to nothing there was something broken added with the note about dlg_manage(): http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=807f07499b4875cf77463c3bdb6a47e099f18f58 Tags like b b/ br are not valid docbook tags but html. I fixed by removing them (on master and 3.2 before and just committed to 3.1). Oh OK, so it was actually me who broke it. :) Thanks for fixing. If the sip-router.org master does not appear, I will try to figure out which is the script generating the docbook html and see if can be fixed. Okay! Cheers. --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Presence Dialog not being created
Hello Gnaneshwar, Am 21.10.2011 um 22:57 schrieb Gnaneshwar Gatla: Kamailio version: 3.1.5 I have been trying to use presence for Event:Dialog. I have used PUA_Dialoginfo module to accomplish this task. The PUA_dialoginfo module states that if “override_lifetime” is not used, the value of the expires is taken from dialog module. I have tried the module without the “override_lifetime” which did not create the dialog in the presentity. When used debug, I did see the xml being generated but finds the dialog “expires=0” and deletes the xml(please find the log below). How do I get this module working without the “override_lifetime” being used. The problem seems to stem from the dialog module: Apparently, all dialog parameters (including lifetime) are set during the creation of a dialog only after create callbacks have been executed. This is why a lifetime of zero is always available to callback functions, including the one from pua_dialoginfo, no matter what the configured lifetime is. I have created a little patch for 3.1 that changes the dialog module such that dialog variables are set prior to calling creation callbacks. It's attached in this email -- would you mind giving it a try and see if it helps? In order to apply the patch, all you need to do is check out the 3.1 branch (unless you already did so) doing git clone --depth 1 -b 3.1 git://git.sip-router.org/sip-router sip-router and apply the patch inside that directory like this: cd sip-router patch -p 1 /patch/to/patch Now recompile and run as usual. Please let me know if things work now. Thanks a lot and cheers, --Timo 0001-dialog-k-Set-dialog-parameters-timeout-etc.-before-c.patch Description: Binary data ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Daily tarballs not being created anymore?
Hi all, something caught my attention today: Apparently, tarballs provided from http://sip-router.org/tarballs/sr/ do not seem to be updated automatically anymore (the latest files are from March) although the Download page states that this should happen: Tarballs for master (development) and several branches are made available daily (only if there were changes in the sources from previous tarball) Is there a reason why tarball creation has ceased? If so, I think the Download page information should be corrected. I'd be prefer to have automatic tarballs again, however, as it's easier to point people not involved into development at tarballs instead of a set of git instructions. Thanks and cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio.cfg file woes
Am 18.10.2011 um 22:26 schrieb Peter Schrock: I am wondering two things. 1. is there a place on the web that I may find a basic cfg file to at least get Kamailio running. There are a few basic configuration files within the sources. Look into the etc/ directory. 2. is there a resource that tells you what to include for what you want to use the system for. At this point, it seems like I should just include everything because I don't know what I might not need. No, don't do that. Using modules which you do not really require increases complexity, resource usage, and failure probability. On the contrary, what's the worst thing that can happen if you forgot to include a module which you required? Kamailio resists to start and barks at you. What you would do then is find the module you need and include it. Repeat until Kamailio flies. I looked at the references on the website and found the information a little overwhelming with all the options that are available. I think smaller bit sizes would be helpful at this time for me. Kamailio is quite a chunk of software with a wealth of modularity and configurability at hand. Look at the configuration files in etc/ to get a feel for what's possible. If you need help on how to implement certain features with Kamailio, feel free to ask on the mailing list on specific subjects. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Make all error
Am 17.10.2011 um 20:23 schrieb Peter Schrock: I am doing a make all and am getting this error: error: mysql/mysql.h: No such file or directory I have mysql installed and know that kamailio is having trouble finding mysql header files. Is there a configuration I can set up to help kamailio find it? Is there a resource I can be directed to find the info? You probably need to pass the right parameter to make cfg. I'd try something like this: make cfg C_INCLUDES=path to your MySQL header files directory followed by another make all run. If that doesn't work you may want to look at the config.mak file (created by make cfg) and see which other option fits. Note once more that installing dependent libraries from your (POSIX) OS'es repository (IIRC you're using a Mac, so MacPorts) will allow SIP Router to find everything by default, i.e., without having to specify path names. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Make all error
Am 18.10.2011 um 00:14 schrieb Peter Schrock: I will give it a go a see what happens. It's just weird because I am using the latest mysql install and used the generic package (OS Independent). You'd think it would install and allow kamailio to find everything it needs. We'll see what happens. Usually what happens when you do make install on source package is that the software is installed somewhere below /opt or /usr/local. To my knowledge, neither of the two locations are part of the standard path which are looked up for include headers. (The standard path is subject to distribution packages.) Cheers, --Timo On Oct 17, 2011, at 2:16 PM, Timo Reimann timo.reim...@1und1.de wrote: Am 17.10.2011 um 20:23 schrieb Peter Schrock: I am doing a make all and am getting this error: error: mysql/mysql.h: No such file or directory I have mysql installed and know that kamailio is having trouble finding mysql header files. Is there a configuration I can set up to help kamailio find it? Is there a resource I can be directed to find the info? You probably need to pass the right parameter to make cfg. I'd try something like this: make cfg C_INCLUDES=path to your MySQL header files directory followed by another make all run. If that doesn't work you may want to look at the config.mak file (created by make cfg) and see which other option fits. Note once more that installing dependent libraries from your (POSIX) OS'es repository (IIRC you're using a Mac, so MacPorts) will allow SIP Router to find everything by default, i.e., without having to specify path names. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] enabling app_python module in Kamailio
On 11.10.2011 15:08, Muhammad Nasir Bhutta wrote: I am trying to enable the app_python module in Kamailio to run a simple python script externally parallel with Kamailio proxy, While I try to load the module “app_python.so” in configuration file, the Kamailio server fails to start.. I can’t see what is the problem .. The steps, I am following are that: - Script written in python saved in home directory. - Loadmodule “app_python.so” statement in configuration file. - Modparam(“app_python”, “script_name”, “location of script”) - Python_exec(“function”, “parameters list”) .. I have also tried to check the Kamailio configuration option, It gives following warning, 0(2942) WARNING: core [sr_module.c:584]: /usr/local/lib64/kamailio/modules/app_python.so: exports dlflags interface is deprecated and it will not be supported in newer versions; consider using mod_register() instead Is there no other error message? What you provided is just a WARNING which shouldn't be a show stopper. --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Creating a database error
On 12.10.2011 20:26, Peter Schrock wrote: Yes, I was just verifying the mysql installation before I installed kamailio. Although, I do have to type the full path name to open the client. Do you think this is the problem? I will try by setting this up. This means that the mysql binary is not in a directory found in $PATH. So one way to fix this is to extend $PATH to cover the location where mysql is installed. If you installed mysql from your distribution's package manager, however, this should already be the case. You possibly didn't compile and install (or not install) mysql yourself, did you? Cheers, --Timo On Oct 12, 2011, at 1:52 AM, davy van de moere davy.van.de.mo...@gmail.com mailto:davy.van.de.mo...@gmail.com wrote: Are you sure you have mysql-client installed ? (check with just typing mysql in your shell) 2011/10/12 Peter Schrock mailto:peter.schr...@gmail.competer.schr...@gmail.com mailto:peter.schr...@gmail.com This is what I am getting: INFO: test server charset /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 105: mysql: command not found /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 106: mysql: command not found Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 71: mysql: command not found ERROR: Creating core database and grant privileges failed! I looked at the files and cannot find the problem. Please help. Peter ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Can't create a new account with kamctl
Hey, Am 13.10.2011 um 00:00 schrieb Peter Schrock: I have finally got to the section of the install section 10. Ready to Rock. Unfortunately, I did get the error message ERROR: domain unknown: use usernames with domain or set default domain in SIP_DOMAIN. I did the two steps that the instructions gave and cannot find .kamctlrc to add SIP_DOMAIN=mysipserver.com .kamctlrc is the configuration file to kamctl. It may be located in any of the following places to be considered: /etc/kamailio/kamctlrc /usr/local/etc/kamailio/kamctlrc ~/.kamctlrc (note that the last location requires a dot in front of the filename) Just create the file in any of the locations (or multiple if you like -- they are read in sequence) and add the required SIP_DOMAIN parameter. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] limiting concurrent calls with dialog module
Hey Alex, On 10.10.2011 19:53, Alex Balashov wrote: Not only that, but the fix is not trivial. Contrary to how it may appear to a non-developer, this problem cannot be solved by just making a little patch. Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes. Agreed that fixing the issue for locally sent responses is somewhat tricky. Apart from trying to link stateless responses to transactions, however, there are other, less perfect solutions. For instance, you could allow reusing dialogs on arrival of a subsequent INVITE if the initial INVITE wasn't forwarded yet (and therefore must have been replied to locally). It's probably not trivial to implement but keeps the required modifications to a single module. Then again, you can work around such cases by not tracking dialogs for which you know you are going to respond statelessly to (and therefore require no tracking) in the first place. It's not perfectly elegant from a usability point of view but it works. By the way, I came across this bug from a specific scenario where authentication takes place behind the dialog-tracking proxy; that is, a 407 was received from upstream and forwarded back to the caller. In such scenarios, the approach I devised in the bug report should do well and not involve too much work. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] limiting concurrent calls with dialog module
On 10.10.2011 19:00, Jim Lucas wrote: On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote: 2011/10/10 Jim Lucas li...@cmsws.com: On 10/8/2011 6:03 PM, Timo Reimann wrote: As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently. I'm sure the developers would welcome you to submit a patch. Humm, Time *is* the developer here ;) My apologies to Timo. The way he said it, I read that as he was suggesting that someone else should develop it. Check the Flyspray issue linked before and see who reported and is assigned to the bug. Hint: It involves me. :) Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] limiting concurrent calls with dialog module
Am 08.10.2011 um 21:44 schrieb Iñaki Baz Castillo: 2011/10/3 Jon Bonilla ma...@aholab.ehu.es: Due to a couple of bugs in the dialog module I'd suggest you to run this code after the user auth has been successfull. You'll need to call dlg_manage() function first. The other bug makes the dialog not being freed if you send a sl reply generated by the proxy. You should call t_newtran + t_reply to send a statefull reply to the user. Mixing two points above into a single one: - Just call dlg_manage() after the authentication and authorization has been made. As a recommendation, call dlg_manage() just before t_relay() and you are done (and you will avoid both bugs explained by Jon). This works around most issues w.r.t. to the dialog module. However, there's at least one case which cannot be covered: If a proxy behind the one tracking a dialog returns a status code that must not render the dialog as failed (e.g., 407), as of the current implementation the dialog *will* transition into the failure state. According to the standard, this must not occur. As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently. That's something for the long run though. For the time being, the two hints you gave can definitely be considered good practice regarding the dialog module. Cheers, --Timo [1] http://sip-router.org/tracker/index.php?do=detailstask_id=146 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog ref Error
On 05.10.2011 12:12, Uri Shacked wrote: -- Forwarded message -- From: *Uri Shacked* uri.shac...@gmail.com mailto:uri.shac...@gmail.com Date: Wed, Oct 5, 2011 at 11:48 AM Subject: dialog ref Error To: sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org Hi, i keep on getting this error: Oct 5 14:39:33 Kamailio2 /usr/sbin/kamailio[21568]: DEBUG: dialog [dlg_hash.c:247]: new dialog on hash 531 Oct 5 14:39:33 Kamailio2 /usr/sbin/kamailio[21568]: DEBUG: dialog [dlg_handlers.c:264]: route_set , contact sip:036264529@10.2.0.55:5061 http://sip:036264529@10.2.0.55:5061, cseq 1 and bind_addr udp:10.2.0.5:5060 http://10.2.0.5:5060/ Oct 5 14:39:33 Kamailio2 /usr/sbin/kamailio[21568]: DEBUG: dialog [dlg_hash.c:519]: ref dlg 0xb417f5a0 with 3 - 3 Oct 5 14:39:33 Kamailio2 /usr/sbin/kamailio[21568]: DEBUG: dialog [dlg_hash.c:600]: unref dlg 0xb417f5a0 with 1, crt ref count: 3 anyone knows what it is? Doesn't look like an error to me. You increased log verbosity to DEBUG and thus, will receive a lot dialog status updates per se. Unless you encounter anything of type WARN or worse (including a crash) there should be no reason to be concerned. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog ref Error
On 05.10.2011 14:53, Uri Shacked wrote: On Wed, Oct 5, 2011 at 2:34 PM, Uri Shacked ushac...@gmail.com mailto:ushac...@gmail.com wrote: OK... now i see the problem is some where in the cfg file... i get te following error : 0(3774) : core [cfg.y:3406]: parse error in config file //etc/kamailio/kamailio.cfg, from line 944, column 2 to line 945, column 0: syntax error 0(3774) : core [cfg.y:3406]: parse error in config file //etc/kamailio/kamailio.cfg, from line 944, column 2 to line 945, column 0: bad command ERROR: bad config file (2 errors) [snip!] here is my complete cfg file. any ideas? ... [rest of configuration] The error says you have a problem between lines 944 and 945. Show those lines, please. (Or attach a configuration file that isn't truncated!). --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Trouble Setting up Kamailio
Hey Peter, On 01.10.2011 23:23, Peter Schrock wrote: I am using the site: http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git to load up Kamailio on my ppc using Leopard X. I managed to figure out the mysql issue and got it to install, but now there are some variances to the instruction from the stated install site and I am kind of lost. If I could get some help with the following - 7. Create MySQL database This whole section seems confusing. It doesn't say what I am suppose to look for. I am sure what it says is all you need to do, but I am not sure if it is completed correctly or not. The order of what things need to be done may have been confusing, I just changed that in the wiki. First, you need to change the config file to your DB engine needs; then, you run the script to create the database. Please take a look at the section again and tell me if there are still things left which make the section hard to understand. - 8. Edit configuration file This section could use more specific information as to how to set up the configuration file. - 9. The init.d script This section says I am suppose to put /kamailio.init/ in the directory //etc/init.d/, then I am suppose chmod after it is copied. First of, I don't have that directory, am I suppose to create it or is it suppose to be created already? Also, it says to /adduser/ with some options. Every time I try, I get the error message that it doesn't recognize the /adduser/ command. The points you have mentioned are all Linux-/Unix-specific and probably cannot be transferred easily to the Mac-kind-of-Unix. Let me ask you this: What are you trying to achieve exactly? Do you want to just give Kamailio a try and play around with it? Or do you intend to run it productively on a Mac, possibly a server? If the former is the case, you don't really need to set up the init daemon script or add a specific user. In fact, you don't require MySQL either as Kamailio can run from memory alone. When it comes to just giving things a try, I suggest that as it saves you a lot of setup work. If the latter is the case though, you'll need to figure out how to set up a Unix-like service properly under a Mac (or wait and hope for someone else to reply on the mailing list). I suppose there aren't too many folks out there running Kamailio on a Mac server (why would anyone run a Mac server anyway? ;) ), so you may be on your own. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] New to Kamailio - make problem
Hey Peter, Am 01.10.2011 um 04:34 schrieb Peter Schrock: I am assuming you are talking about mysql. I downloaded a dmg from the mysql site (which has been all that helpful as far as finding what I need). I am using Server version: 6.0.11-alpha MySQL Community Server (GPL). Using MacPorts[1], it's really easy to install Unix applications on a Mac, including development packages. With regards to your problem, satisfying gcc should be as easy as installing the mysql5-devel package using ports: sudo port install mysql5-devel Alternatively, if you don't need MySQL support in your Kamailio server at all, exclude the module during the build: make exclude_modules=db_mysql your other build options or don't include anything that has a dependency at all: make group_include=standard your other build options SIP Router's build process (and therefore, Makefile) is pretty powerful. Consult the 'INSTALL' file for details. HTH, --Timo [1] http://www.macports.org/ On Fri, Sep 30, 2011 at 4:58 PM, Nick Khamis sym...@gmail.com wrote: You neet the mysql header library. What distro are you using? Nick. On Fri, Sep 30, 2011 at 7:44 PM, Peter Schrock peter.schr...@gmail.com wrote: I can't seem to get kamailio to make. I am following the directions on the wiki on how to install. I have downloaded, compiled, and installed mysql server and every time I run to make all with kamailio, I get this error message. At first, I was thinking that km_db_mysql.c couldn't find the file. The header seems to be looking for mysql.h (at #include mysql/mysql.h). I found the file from installing mysql server and I thought I'd help km_db_mysql.c to find the file, but it still gives me this error. I am using a power pc running OS X.5.1. CC (gcc) [M db_mysql.so] km_db_mysql.o km_db_mysql.c:49:19: error: mysql/mysql.h: No such file or directory km_db_mysql.c: In function ‘kam_mysql_mod_init’: km_db_mysql.c:92: warning: implicit declaration of function ‘mysql_get_client_info’ km_db_mysql.c:92: warning: format ‘%s’ expects type ‘char *’, but argument 7 has type ‘int’ km_db_mysql.c:92: warning: format ‘%s’ expects type ‘char *’, but argument 6 has type ‘int’ make[1]: *** [km_db_mysql.o] Error 1 make: *** [modules] Error 1 Peter Schrock ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey Phillip,
On 21.09.2011 13:53, Phillman25 Kyriacou wrote:
I tried what you told me below, however i'm still getting the same result.
Just to give you more details on my scenario i have 2 kamailio servers
running heartbeat for high availability on a virtual ip as well as mysql
MASTER-MASTER replication setup. All traffic is sent on this virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging to
a specific dialog reach the same Kamailio instance. (There is no notion
of distributed dialog management; the database just helps with restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann timo.reim...@1und1.de
mailto:timo.reim...@1und1.de wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close
the if statement.
You can see that the route(WITHINDLG); is called for all requests from
this config.
# MANAGE ALL DIALOGS
#===
if (is_method(INVITE))
{
if(is_method(INVITE) !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method(BYE|CANCEL))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog tracking
doesn't work for you. I tried to reproduce your setup, including the
dialog module parameters you are using. However, things keep working for
me the way they should.
A few people have had issues when starting to track dialogs before the
INVITE was authenticated. In that case, the caller could receive a 407
which isn't properly handled by the dialog module in all cases. (There's
a bug report filed on the tracker already.) Could you try moving that
if(is_method(INVITE) !has_totag()) {...} part including the call
to dlg_manage() past the location where route(AUTH) is called and see
if it helps?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey,
On 21.09.2011 14:16, Phillman25 Kyriacou wrote:
Yes the mysql replication is basically used to update the standby server
of new mysql entries in case of a switchover the secondary server will
be updated in terms of dialog restoration, dialplan update, CDR's etc...
I'm pretty sure that all messages belonging to a specific dialog reach
the same Kamailio instance.
Sounds fine to me then.
There's not much I can think of now apart from trying to get more data
on the issue. Are you able to reproduce the problem such that you could
create a trace of a call affected by the problem and provide me with
that? Even better, could you increase log verbosity to debug level
while you do the trace?
Cheers,
--Timo
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann timo.reim...@1und1.de
mailto:timo.reim...@1und1.de wrote:
Hey Phillip,
On 21.09.2011 13 tel:21.09.2011%2013:53, Phillman25 Kyriacou wrote:
I tried what you told me below, however i'm still getting the same
result.
Just to give you more details on my scenario i have 2 kamailio
servers
running heartbeat for high availability on a virtual ip as well as
mysql
MASTER-MASTER replication setup. All traffic is sent on this
virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages belonging to
a specific dialog reach the same Kamailio instance. (There is no notion
of distributed dialog management; the database just helps with restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
timo.reim...@1und1.de mailto:timo.reim...@1und1.de
mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a
} to close
the if statement.
You can see that the route(WITHINDLG); is called for all
requests from
this config.
# MANAGE ALL DIALOGS
#===
if (is_method(INVITE))
{
if(is_method(INVITE) !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method(BYE|CANCEL))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog
tracking
doesn't work for you. I tried to reproduce your setup,
including the
dialog module parameters you are using. However, things keep
working for
me the way they should.
A few people have had issues when starting to track dialogs
before the
INVITE was authenticated. In that case, the caller could
receive a 407
which isn't properly handled by the dialog module in all
cases. (There's
a bug report filed on the tracker already.) Could you try
moving that
if(is_method(INVITE) !has_totag()) {...} part including
the call
to dlg_manage() past the location where route(AUTH) is
called and see
if it helps?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey,
On 21.09.2011 14:58, Phillman25 Kyriacou wrote:
How can i increase log verbosity to debug level? Do i change the below
debug values?
You just need to change the debug parameter. It's gotta be 3 in SIP
Router to get DBG-level verbosity (the most noisy level).
You can also change the debug level on-the-fly using sercmd; this is
quite useful as you do not need to restart the server. Please see the
official documentation here:
http://sip-router.org/wiki/cookbooks/core-cookbook/devel?s[]=debug#debug
As the documentation says, a very verbose and busy Kamailio can easily
flood your logs. If that's a potential issue to you, keep verbose times
as short as possible, i.e., change the debug level [on-the-fly] only for
the duration of trace generation and revert back to a safer setting
right afterwards.
Can i use the module sip trace to produce a trace or would you rather
prefer i use ngrep -d any -P '*' -W byline -T port 5060 ?
ngrep would be perfect!
Thanks a lot and
cheers,
--Timo
On Wed, Sep 21, 2011 at 3:41 PM, Timo Reimann timo.reim...@1und1.de
mailto:timo.reim...@1und1.de wrote:
Hey,
On 21.09.2011 14 tel:21.09.2011%2014:16, Phillman25 Kyriacou wrote:
Yes the mysql replication is basically used to update the standby
server
of new mysql entries in case of a switchover the secondary server will
be updated in terms of dialog restoration, dialplan update, CDR's
etc...
I'm pretty sure that all messages belonging to a specific dialog reach
the same Kamailio instance.
Sounds fine to me then.
There's not much I can think of now apart from trying to get more data
on the issue. Are you able to reproduce the problem such that you could
create a trace of a call affected by the problem and provide me with
that? Even better, could you increase log verbosity to debug level
while you do the trace?
Cheers,
--Timo
On Wed, Sep 21, 2011 at 3:02 PM, Timo Reimann
timo.reim...@1und1.de mailto:timo.reim...@1und1.de
mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote:
Hey Phillip,
On 21.09.2011 13 tel:21.09.2011%2013
tel:21.09.2011%2013:53, Phillman25 Kyriacou wrote:
I tried what you told me below, however i'm still getting
the same
result.
Just to give you more details on my scenario i have 2 kamailio
servers
running heartbeat for high availability on a virtual ip as
well as
mysql
MASTER-MASTER replication setup. All traffic is sent on this
virtual ip.
You think that this might be the reason?
Not 100% sure but you need to guarantee that *all* messages
belonging to
a specific dialog reach the same Kamailio instance. (There is
no notion
of distributed dialog management; the database just helps with
restoring
dialogs on startup.) Is that the case for you?
Cheers,
--Timo
On Tue, Sep 20, 2011 at 8:07 PM, Timo Reimann
timo.reim...@1und1.de mailto:timo.reim...@1und1.de
mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de
mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de
mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote:
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a
} to close
the if statement.
You can see that the route(WITHINDLG); is called for all
requests from
this config.
# MANAGE ALL DIALOGS
#===
if (is_method(INVITE))
{
if(is_method(INVITE) !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method(BYE|CANCEL))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey Phillip,
On 20.09.2011 13:48, Phillman25 Kyriacou wrote:
Thanks for your email.
Yes dlg_manage(); has to now be called on INVITE and BYE/CANCEL messages.
Where would i have to call loose_route()? Only on INVITE?
On *all* in-dialog requests, i.e., all requests which contain a To tag.
This may include Re-INVITEs too (but not initial INVITEs).
My configuration did not change between 3.1.2 and 3.1.5.
Call flow example:
==
Cisco PGW === Kamailio 3.1.5 === VOIP PROVIDER or ASTERISK PABX
The below is my configuration.
Let's take a look at it:
#!KAMAILIO
#
[...]
if(is_method(BYE|CANCEL))
{
dlg_manage();
# per request initial checks
route(REQINIT);
# NAT detection
route(NAT);
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
[...]
So route[WITHINDLG] contains the logic to track in-dialog requests.
However, you seem to call that route only from BYE and CANCEL requests,
missing out ACKs, which is likely the reason why things go wrong. So
make sure you run all in-dialog requests through that route, and you
should be fine (hopefully).
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey,
On 20.09.2011 15:23, Phillman25 Kyriacou wrote:
Hey Timo
Thanks for your email.
I apologise i never copied the config properly. I missed a } to close
the if statement.
You can see that the route(WITHINDLG); is called for all requests from
this config.
# MANAGE ALL DIALOGS
#===
if (is_method(INVITE))
{
if(is_method(INVITE) !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
if(is_method(BYE|CANCEL))
{
dlg_manage();
}
[...]
# handle requests within SIP dialogs
route(WITHINDLG);
[...]
# authentication
route(AUTH);
Ok, this looks better now. Still, I cannot explain why dialog tracking
doesn't work for you. I tried to reproduce your setup, including the
dialog module parameters you are using. However, things keep working for
me the way they should.
A few people have had issues when starting to track dialogs before the
INVITE was authenticated. In that case, the caller could receive a 407
which isn't properly handled by the dialog module in all cases. (There's
a bug report filed on the tracker already.) Could you try moving that
if(is_method(INVITE) !has_totag()) {...} part including the call
to dlg_manage() past the location where route(AUTH) is called and see
if it helps?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey Phillip, you probably forgot to keep the mailing list in CC, I'll do that for you. On 19.09.2011 08:43, Phillman25 Kyriacou wrote: You are right. I added the function dlg_manage(); when there is a BYE or CANCEL and now its working perfectly. Before i had this function defined only on INVITES. The strange thing is that it was working normally before when dlg_manage(); was defined only for INVITE messages in the route block. So you are saying that before, you called dlg_manage() on INVITEs only but now, you need that function on both INVITE and BYE/CANCEL messages? That'd still qualify as a bug as the trigger to tracking the dialog (i.e., dlg_manage()) is required only once. After that, the dialog module makes sure that all dialog-related messages are properly processed. The only thing that's necessary for sequential requests to be tracked correctly is a call to loose_route() on such messages. If you are sure that your Kamailio configuration didn't change between 3.1.2 and 3.1.5 w.r.t. dialog tracking or anything that could affect it, I'd be willing to take a closer look at this issue (giving you can provide me with more information on your scenario, like call flow examples or similar). Cheers, --Timo The calls that were suppose to be terminated before where in state 3 to answer your question. However, i still see calls in state 3 now but they are valid. Regards Phillip On Fri, Sep 16, 2011 at 8:01 PM, Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote: Hey Phillip, after looking closer at what has been reported to me initially, your case may be different after all. Could you possibly use kamctl fifo dlg_list to check what state the majority of dialogs that should be terminated in your opinion are in? Being given the reference counter should be useful in debugging this as well. Thanks, --Timo On 16.09.2011 14:22, Phillman25 Kyriacou wrote: On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote: Hey Phillip, On 16.09.2011 13:35, Phillman25 Kyriacou wrote: Hello I have been facing an issue where the dialog module is showing calls as being active when in fact the call has already been completed long ago and this is giving wrong number of concurrent calls on our SNMP work station (CACTI) when polling the data from Kamailio. I realized this only started occurring after i upgraded from 3.1.2 to 3.1.5, has anyone experienced the same issue? I was *just* being notified of issues concerning dialogs not being deleted. Working on this right now to report back soon. Thanks for the note! Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio terminating after upgrading from 3.1.2 to 3.1.4
On 16.09.2011 12:00, Phillman25 Kyriacou wrote: Could you please explain in a little more detail how to compile Kamailio with debug symbols? Do i use the command make CFLAGS=-g ? then make QUIET=no all? I always add mode=debug to make, e.g.: make mode=debug my other make options HTH, --Timo On Thu, Sep 15, 2011 at 5:02 PM, marius zbihlei marius.zbih...@1and1.ro mailto:marius.zbih...@1and1.ro wrote: On 09/14/2011 07:40 PM, Phillman25 Kyriacou wrote: Hello Here is the output of the gdb commands: (gdb) core core [New Thread 18567] Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 64 -u root -g roo'. Program terminated with signal 6, Aborted. #0 0x0040a422 in __kernel_vsyscall () . . . (gdb) bt full #0 0x0040a422 in __kernel_vsyscall () No symbol table info available. #1 0x0056a651 in ?? () No symbol table info available. #2 0x00695ff4 in ?? () No symbol table info available. #3 0x0056da82 in ?? () No symbol table info available. #4 0x0006 in ?? () No symbol table info available. #5 0xbff91960 in ?? () Hello, This is not very helpful as the debug symbols weren't loaded. You have to compile Kamailio with debug symbols (make sure the -g flag is passed to CFLAGS when compiling) and then reload the core (it is not mandatory to generate another one ) make QUIET=no (to see the flags) Also don't strip the executable Marius ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey Phillip, On 16.09.2011 13:35, Phillman25 Kyriacou wrote: Hello I have been facing an issue where the dialog module is showing calls as being active when in fact the call has already been completed long ago and this is giving wrong number of concurrent calls on our SNMP work station (CACTI) when polling the data from Kamailio. I realized this only started occurring after i upgraded from 3.1.2 to 3.1.5, has anyone experienced the same issue? I was *just* being notified of issues concerning dialogs not being deleted. Working on this right now to report back soon. Thanks for the note! Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module showing calls that have already been terminated
Hey Phillip, after looking closer at what has been reported to me initially, your case may be different after all. Could you possibly use kamctl fifo dlg_list to check what state the majority of dialogs that should be terminated in your opinion are in? Being given the reference counter should be useful in debugging this as well. Thanks, --Timo On 16.09.2011 14:22, Phillman25 Kyriacou wrote: On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de wrote: Hey Phillip, On 16.09.2011 13:35, Phillman25 Kyriacou wrote: Hello I have been facing an issue where the dialog module is showing calls as being active when in fact the call has already been completed long ago and this is giving wrong number of concurrent calls on our SNMP work station (CACTI) when polling the data from Kamailio. I realized this only started occurring after i upgraded from 3.1.2 to 3.1.5, has anyone experienced the same issue? I was *just* being notified of issues concerning dialogs not being deleted. Working on this right now to report back soon. Thanks for the note! Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] planning v3.1.5
On 13.09.2011 16:50, Jon Bonilla wrote: El Thu, 08 Sep 2011 17:16:24 +0200 Daniel-Constantin Mierla mico...@gmail.com escribió: Hello, it's being quite some time since we released 3.1.4, so I am thinking of packaging soon v3.1.5 out of stable branch 3.1. My plan is to release it Wednesday, September 14, 2011. Any other opinions? Cheers, Daniel There's a bug in the dialog module (146) but I don't know if it will be handled in 3.1 branch. Don't think it's release critical neither. http://sip-router.org/tracker/index.php?do=detailstask_id=146 I had been working on this bug but got interrupted by other tasks. Once done, my plan is to push the finished work to both master and 3.1 as it qualifies as a bug fix IMHO. (The dialog module is violating the standard in this particular regards.) It'll certainly take a little more time to finish though, so it's not going to be part of tomorrow's 3.1.5 release. In accordance with Jon's opinion, however, I agree that it isn't mission-critical. After all, people have been using the module with the bug as it was already there from the very start of the module's lifetime. :) Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Resend INVITE in case of failure
On 31.08.2011 10:58, Mino Haluz wrote: Hi, I would like to resend the INVITE to another gateway if the original fails (503, 500, etc.). Is there any module or mechanism which could do this ? That's what built-in failure routes are good for: http://sip-router.org/wiki/cookbooks/core-cookbook/devel#failure_route HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Persistent dialog
Hey Andreas, Am 27.08.2011 um 11:39 schrieb Andreas Granig: On 08/16/2011 07:59 PM, Timo Reimann wrote: On 16.08.2011 19:43, Timo Reimann wrote: So you'll either have to dig into the commit yourself and separate the fix, get a hold of my entire branch, or wait for 3.1.5 to release. ...or check out master: I just merged treimann/acc-cdr into master which was supposed to happen before the 3.2 feature freeze anyway. Following up on this, I've seen couple of commits to dialog and merges to 3.1 yesterday. Is my assumption correct that this should actually work in the latest 3.1 branch now? Unfortunately not: The patches committed yesterday primarily fix a bug in reference counting management of the dialog module that could lead to segmentation faults in certain scenarios. The issue which Jon brought up initially requires modifications to the dialog state machine with expectingly larger code changes. I haven't found the time to address this one yet but created a Flyspray entry which I assigned myself to: http://sip-router.org/tracker/index.php?do=detailstask_id=146 If you'd like to be informed when the bug is fixed, please register yourself as a watcher. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Freezes and no calls are processed
On 22.08.2011 14:04, Morten Isaksen wrote: On Sat, Aug 20, 2011 at 10:16 PM, Omar o...@321communications.com wrote: The only difference is we have added some AVPs variables to process, and kamailio stops processing new calls, is not regular, but seems is related to the number of calls received. No additional calls can be processed after certain time, or maybe some amount of calls. we were unable to isolate the problem, but kamailio.fifo is removed, which never happened before. No core dump created. did anybody have a similar issue. I had a similar issue some time ago. Look in the archives and you will find som backtraces from gdb. The problem went away when I changed the dialog module not to write to DB but only use memory. I added a few fixes to the DB part of the dialog module, so chances are the problem doesn't show up anymore when using sip-router master or a recent copy of the 3.1 branch. If you want to give DB mode another try and encounter these lock ups again, feel free to post to the mailing list and add me in CC so I can take a closer look. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] new functionality: CDR-based accounting
Hello, On 17.08.2011 11:46, Daniel-Constantin Mierla wrote: On 8/11/11 10:12 AM, Timo Reimann wrote: Hey Graham, On 10.08.2011 14:27, Graham Wooden wrote: I would be interested in the 1.5 backported module. Is that available for the masses? I personally wouldn't mind publishing the backport code. One interesting question, however, is in what form to do that. Several approaches come to my mind: - A separate branch with just the patch. - A separate Kamailio 1.5 branch with the modified code. - Distribution via the mailing list. - Distribution in private. Naturally, I'd favor something centralized to allow more people access to the code. @Daniel: What's your thought on this? Do you have a preferred way? Maybe uploading it (a tarball if big or just the patch file) on the tracker is another quite easy possibility. Either on the one from sip-router.org, or, since it is 1.5, can be even on the sourceforge.net. This will allow to upload new versions of the files if changes are needed in the future. Then provide the link to the tracker item on the mailing list. I would prefer no commit on the mainstream SVN branches, so we do not open past releases, that will create lot of confusion. As Daniel suggested, I put the patch on the Sourceforge tracker: http://sourceforge.net/tracker/?func=detailaid=3394470group_id=139143atid=743022 If something's not working as expected, please let me know. Note, however, that support for the 1.5 branch cannot be guaranteed and will discontinue very soon from my side. Cheers, --Timo Note, however, that the time frame we (as in my company) are going to use, support, and maintain the 1.5 backport code is already now foreseeable. Cheers, --Timo On 8/4/11 1:08 AM, Timo Reimanntimo.reim...@1und1.de wrote: Hi all, as announced quite a while ago, I finally checked in code that allows to produce CDRs (Call Data Records) directly from SIP-Router and generate logs accordingly. The main code portion resides in modules_k/acc and provides a switch to enable basic CDR generation including start time, end time, and duration. Analogous to the existing logging approach, you may define an extra parameter covering to-be-included dialog pseudo-variables that must be assigned in the configuration script. The new code will take care of transforming the basic and custom CDR fields into CDR logs at the end of a dialog. Speaking of dialogs: The implementation relies heavily on the dialog module. It takes advantage of dialog variables introduces by Carsten Bock and adds a few more features. Most notably, we had to change the dialog callback signature to provide both request and response messages. Having only one of them proved to be insufficient in certain cases; for instance, a locally generated 408 returned a FAKED_REPLY, thus rendering it impossible to access dialog variables through the PV framework. Other modules using dialog callbacks have been updated along the commit, third-party modules outside the repository will need to do so too (and think about whether using the request or response is the Right Thing to do). Due to the changes brought to the dialog module, I pushed the new acc and dialog code into a separate branch called treimann/acc-cdr. Feel free to give it a try by consulting the updated documentation and suggesting (or, if it's good enough, implementing :) ) improvements. A Kamailio 1.5 backport of the code has been in usage for quite some time with us, so generally there shouldn't be any major logical flaws. SIP-Router certainly needs more testing, however, so I'd be glad for any feedback. My plan is to merge the code into master branch prior to the 3.2 feature freeze, unless significant objections arise. Finally, big-time credits go to my co-worker Sven Knoblich who is the main contributor of the code. He's been working on this stuff for the past few months and dreams in CDRs by now. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Persistent dialog
Hey, On 16.08.2011 17:43, Jon Bonilla wrote: After configured the proxy I've tested a call and I realize that the dialog list is not empty after the call ends. Here's a sample call log and the dialog list while the call was being stablished and 3 minutes after that: root@proxy1a:~# grep fbrzjkplmvlauty@quenya /var/log/kamailio.log New request - M=INVITE Dialog set mark TOTAL Proxy authentication failed New request - M=INVITE Dialog set mark TOTAL [snip!] While the call was being stablished or just after it was dropped (quickly) sercmd dlg.list hash:3837:638039689 state:1 timestart:0 timeout:0 hash:3837:638039690 state:5 timestart:0 timeout:0 After a couple of minutes: hash:3837:638039689 state:1 timestart:0 timeout:0 Obviously, there's no such a call. But my dialog profile TOTOAL say's there's one, which is listed by sercmd. The dialog is persistent, I guess it will be destroyed after 12 hours, but I'd like to know why it's still there if I received a negative response and the ACK for it. Looks pretty much like two dialog entries were created for the same dialog. One of them got cleaned up nicely on call termination while the other one keeps dangling until the dialog timer kicks in (12 hours in your case). Most notably, this situation may happen when spiraling calls without using the spiral detection feature in the dialog module. (A spiral is a scenario where a proxy is processing the same request twice, e.g., to implement call forwardings.) Did you possibly toggle the default spiral detection setting from enabled to disabled? If that's not the case: Can you check the Kamailio logs for any suspicious dialog-related log messages, particularly those with WARN or higher log verbosity? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Persistent dialog
Hey Jon, On 16.08.2011 18:14, Jon Bonilla wrote: Looks pretty much like two dialog entries were created for the same dialog. One of them got cleaned up nicely on call termination while the other one keeps dangling until the dialog timer kicks in (12 hours in your case). Most notably, this situation may happen when spiraling calls without using the spiral detection feature in the dialog module. (A spiral is a scenario where a proxy is processing the same request twice, e.g., to implement call forwardings.) Did you possibly toggle the default spiral detection setting from enabled to disabled? No I didn't Here's the dialog modparams: modparam(dialog,dlg_flag, 9) modparam(dialog,profiles_no_value,total ;emergency) modparam(dialog,profiles_with_value,peer ; user ; type ; peerout ; userout) Maybe setting the dialog to TOTAL twice is the problem? I set it before proxy authentication. I asume that dialog is erased when sending the 407 back and a new one is created for the second INVITE. That's what spiral detection is supposed to prevent, i.e., the creation of multiple structures for the same dialog. However, it only works if you use the flag to track dialogs, not if you call dlg_manage() explicitly. I see you have actually configured flag #9 as dialog flag but just to make sure: Are you using that flag only, not dlg_manage() ? Even if you did not use dlg_manage(), however, dialogs would likely not be tracked properly if you started doing so on unauthenticated calls. The reason is that terminated calls do not get removed until the associated transaction is deleted. When that second, authenticated INVITE is handled by the dialog module, it will find a dialog structure already in the DELETED state (as the dialog ID matches) and refuse further processing on it. This may be considered as a shortcoming of the current implementation. On the other hand, do you actually need to track unauthenticated calls? They could just be SIP attacks trying to disrupt your infrastructure and shouldn't be accounted as real calls whatsoever. If you start tracking dialogs after authentication, things should look better. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Persistent dialog
On 16.08.2011 19:32, Jon Bonilla wrote: I think it's worth a try to see if my git branch already does better for your use case. If you could give it a shot I'd be glad to know how it works or whether it needs further work on. I'll try to get the patch (or the whole dialog module) from your branch and merge it into my 3.1.3 build. I'll make some tests tomorrow and I'll report back to you. The fix is part of the bigger commit c021559e41. I tried to apply the entire patch to both 3.1.3 and 3.1.4 but it produces too many failures each time. So you'll either have to dig into the commit yourself and separate the fix, get a hold of my entire branch, or wait for 3.1.5 to release. Sorry for any inconveniences. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Persistent dialog
On 16.08.2011 19:43, Timo Reimann wrote: So you'll either have to dig into the commit yourself and separate the fix, get a hold of my entire branch, or wait for 3.1.5 to release. ...or check out master: I just merged treimann/acc-cdr into master which was supposed to happen before the 3.2 feature freeze anyway. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] new functionality: CDR-based accounting
Hey Graham, On 10.08.2011 14:27, Graham Wooden wrote: I would be interested in the 1.5 backported module. Is that available for the masses? I personally wouldn't mind publishing the backport code. One interesting question, however, is in what form to do that. Several approaches come to my mind: - A separate branch with just the patch. - A separate Kamailio 1.5 branch with the modified code. - Distribution via the mailing list. - Distribution in private. Naturally, I'd favor something centralized to allow more people access to the code. @Daniel: What's your thought on this? Do you have a preferred way? Note, however, that the time frame we (as in my company) are going to use, support, and maintain the 1.5 backport code is already now foreseeable. Cheers, --Timo On 8/4/11 1:08 AM, Timo Reimann timo.reim...@1und1.de wrote: Hi all, as announced quite a while ago, I finally checked in code that allows to produce CDRs (Call Data Records) directly from SIP-Router and generate logs accordingly. The main code portion resides in modules_k/acc and provides a switch to enable basic CDR generation including start time, end time, and duration. Analogous to the existing logging approach, you may define an extra parameter covering to-be-included dialog pseudo-variables that must be assigned in the configuration script. The new code will take care of transforming the basic and custom CDR fields into CDR logs at the end of a dialog. Speaking of dialogs: The implementation relies heavily on the dialog module. It takes advantage of dialog variables introduces by Carsten Bock and adds a few more features. Most notably, we had to change the dialog callback signature to provide both request and response messages. Having only one of them proved to be insufficient in certain cases; for instance, a locally generated 408 returned a FAKED_REPLY, thus rendering it impossible to access dialog variables through the PV framework. Other modules using dialog callbacks have been updated along the commit, third-party modules outside the repository will need to do so too (and think about whether using the request or response is the Right Thing to do). Due to the changes brought to the dialog module, I pushed the new acc and dialog code into a separate branch called treimann/acc-cdr. Feel free to give it a try by consulting the updated documentation and suggesting (or, if it's good enough, implementing :) ) improvements. A Kamailio 1.5 backport of the code has been in usage for quite some time with us, so generally there shouldn't be any major logical flaws. SIP-Router certainly needs more testing, however, so I'd be glad for any feedback. My plan is to merge the code into master branch prior to the 3.2 feature freeze, unless significant objections arise. Finally, big-time credits go to my co-worker Sven Knoblich who is the main contributor of the code. He's been working on this stuff for the past few months and dreams in CDRs by now. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] new functionality: CDR-based accounting
Hi all, as announced quite a while ago, I finally checked in code that allows to produce CDRs (Call Data Records) directly from SIP-Router and generate logs accordingly. The main code portion resides in modules_k/acc and provides a switch to enable basic CDR generation including start time, end time, and duration. Analogous to the existing logging approach, you may define an extra parameter covering to-be-included dialog pseudo-variables that must be assigned in the configuration script. The new code will take care of transforming the basic and custom CDR fields into CDR logs at the end of a dialog. Speaking of dialogs: The implementation relies heavily on the dialog module. It takes advantage of dialog variables introduces by Carsten Bock and adds a few more features. Most notably, we had to change the dialog callback signature to provide both request and response messages. Having only one of them proved to be insufficient in certain cases; for instance, a locally generated 408 returned a FAKED_REPLY, thus rendering it impossible to access dialog variables through the PV framework. Other modules using dialog callbacks have been updated along the commit, third-party modules outside the repository will need to do so too (and think about whether using the request or response is the Right Thing to do). Due to the changes brought to the dialog module, I pushed the new acc and dialog code into a separate branch called treimann/acc-cdr. Feel free to give it a try by consulting the updated documentation and suggesting (or, if it's good enough, implementing :) ) improvements. A Kamailio 1.5 backport of the code has been in usage for quite some time with us, so generally there shouldn't be any major logical flaws. SIP-Router certainly needs more testing, however, so I'd be glad for any feedback. My plan is to merge the code into master branch prior to the 3.2 feature freeze, unless significant objections arise. Finally, big-time credits go to my co-worker Sven Knoblich who is the main contributor of the code. He's been working on this stuff for the past few months and dreams in CDRs by now. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] new to ser
On 07.07.2011 00:46, Pradeep Sharma wrote: I am installed ser 0.9.6 onto my mac machine and with following command i get it to listen to 5060 port. but when i use a sip client and send register message i get a 501 not implemented as a response from the server. i am attaching ser.cfg. your help is appreciated. 0.9.6? Unless this is your way of celebrating SER's upcoming 10th anniversary, please consider upgrading to a recent version first. :) Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog module question
Hey Javier, On 28.06.2011 17:53, Javier Gallart wrote: I have little experience with the dialog module -so sorry if the quesiton is silly-, and I was wondering if I could use it for doing accounting (acc works just fine, but I was looking for a unique stop record that includes all the call information). The basic idea would be to assign the initial INVITE to a profile; and then, when BYE is received, build a cdr based of the dialog attributes...but afaik , upon reception of the BYE the dialog is destroyed. is there a way to access the dlg attributes inside the script when the BYE transaction is processed? Basically, what you are referring to is dialog-based CDR generation. Although it's not possible to do in the current Kamailio, a co-worker of mine and me have been working hard lately to implement this specific feature. It requires changes to the dialog module (such as allowing access to dialogs even after the BYE message is processed, just as you mentioned) and extending the acc module by a CDR mode. The plan is to get the new code into the project ASAP, certainly by the time SR 3.2 is released. So watch out for a new repository branch and an announcement on the mailing list to get your hands dirty with the new stuff soon. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] callback function of tm module
Hi Bruno, On 03.06.2011 20:00, Bruno Bresciani wrote: Actually I'm migrating my call routing module of version 1.5.0 of kamailio to version 3.1.2. I want to understand why the tm module registers an event callback after the INVITE message is processed by my routing module. When I use the dispatcher module for routing, no event callback is registered by the tm module. I am certain that the tm module isn't doing any callback registrations itself -- at least not by calling register_tmcb() which is used by other modules exclusively. Some grep'ing and cscope'ing acknowledges that. It seems to me that some other, intermediary module registers a callback instead. If it's not a problem for you, run SR in gdb and post a backtrace from the instance the callback you are wondering about is allegedly registered. That way, we can take a look at the call flow and figure out how things work. Cheers, --Timo 2011/6/3 Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de Hey Bruno, On 03.06.2011 16:21, Bruno Bresciani wrote: In file t_hook.c line 386 *cbp-callback( trans, cbp-types, params )* calls the function to record register_tmcb when I received a INVITE. I'd like to now how register_tmcb function is call by the function callback. register_tmcb() isn't called by a callback function, it rather works the other way around. For clarity, here's the call flow: (1) A user is interested in being called back on a particular tm event, e.g., TMCB_DESTROY. To be notified of such events, he calls tmcb_register() and passes the set of events (callback types) he is interested in (e.g., TMCB_DESTROY and possibly others) together with the desired callback function and a few other parameters. (2) In tmcb_register(), a few sanity checks are done first (e.g., callback type is valid, callback function is not NULL, transaction exists, etc.). If they pass, the callback function and the parameters are stored in a list of callbacks (called cb_list in register_tmcb()). (3) When a particular tm event occurs, the tm module checks if any callbacks were registered for that specific event. If so, it executes each registered callback function in sequence, with each function being passed the callback type and callback-specific parameter. The call of the callback is exactly what cbp-callback( trans, type, params ) does, at least for call types other than TMCB_REQUEST_IN. For TMCB_REQUEST_IN, the handling is slightly different because callbacks for new SIP requests cannot be associated with an already existing transaction (after all, they are new). With regards to how TMCB_REQUEST_IN-typed callback functions are called, the only difference is that the callback function is being passed the set of all callback types the registering user was interested in, and not just TMCB_REQUEST_IN: cbp-callback( trans, cbp-types, params ) (This is line 386.) Actually, I am not quite sure why the extent of returned callback types differs here. I'm using tm callbacks myself but never had to take advantage of that. Anyways, if all you want to do is use tm callbacks from a module of yours, just call register_tmcb() passing - a callback function, - a transaction cell (unless you're registering for TMCB_REQUEST_IN), - a void pointer to something you want to be passed back on callback execution, and - an optional release function for cleanup purposes. Implement your callback-specific logic in the callback function, and that's it. Naturally, your callback function must fit the callback signature defined in t_hooks.h. I hope this answers your question. If not, let us know what you specifically have in mind, i.e., whether you would like to use tm callbacks, change the framework, or whatever. Cheers, --Timo 2011/6/3 Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de mailto:timo.reim...@1und1.de Hi Bruno, On 03.06.2011 00:07, Bruno Bresciani wrote: I'm having doubts in the implementation of the callback function module tm. As she calls the function to record register_tmcb ()? Can someome help me? Could you be more specific on which part of the tm module you are having trouble with? If you need an example on how to use tm's callbacks you may take a look at the dialog module, specifically the files dialog.c and dlg_handlers.c. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip
Re: [SR-Users] callback function of tm module
Hi Bruno, On 03.06.2011 00:07, Bruno Bresciani wrote: I'm having doubts in the implementation of the callback function module tm. As she calls the function to record register_tmcb ()? Can someome help me? Could you be more specific on which part of the tm module you are having trouble with? If you need an example on how to use tm's callbacks you may take a look at the dialog module, specifically the files dialog.c and dlg_handlers.c. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] callback function of tm module
Hey Bruno, On 03.06.2011 16:21, Bruno Bresciani wrote: In file t_hook.c line 386 *cbp-callback( trans, cbp-types, params )* calls the function to record register_tmcb when I received a INVITE. I'd like to now how register_tmcb function is call by the function callback. register_tmcb() isn't called by a callback function, it rather works the other way around. For clarity, here's the call flow: (1) A user is interested in being called back on a particular tm event, e.g., TMCB_DESTROY. To be notified of such events, he calls tmcb_register() and passes the set of events (callback types) he is interested in (e.g., TMCB_DESTROY and possibly others) together with the desired callback function and a few other parameters. (2) In tmcb_register(), a few sanity checks are done first (e.g., callback type is valid, callback function is not NULL, transaction exists, etc.). If they pass, the callback function and the parameters are stored in a list of callbacks (called cb_list in register_tmcb()). (3) When a particular tm event occurs, the tm module checks if any callbacks were registered for that specific event. If so, it executes each registered callback function in sequence, with each function being passed the callback type and callback-specific parameter. The call of the callback is exactly what cbp-callback( trans, type, params ) does, at least for call types other than TMCB_REQUEST_IN. For TMCB_REQUEST_IN, the handling is slightly different because callbacks for new SIP requests cannot be associated with an already existing transaction (after all, they are new). With regards to how TMCB_REQUEST_IN-typed callback functions are called, the only difference is that the callback function is being passed the set of all callback types the registering user was interested in, and not just TMCB_REQUEST_IN: cbp-callback( trans, cbp-types, params ) (This is line 386.) Actually, I am not quite sure why the extent of returned callback types differs here. I'm using tm callbacks myself but never had to take advantage of that. Anyways, if all you want to do is use tm callbacks from a module of yours, just call register_tmcb() passing - a callback function, - a transaction cell (unless you're registering for TMCB_REQUEST_IN), - a void pointer to something you want to be passed back on callback execution, and - an optional release function for cleanup purposes. Implement your callback-specific logic in the callback function, and that's it. Naturally, your callback function must fit the callback signature defined in t_hooks.h. I hope this answers your question. If not, let us know what you specifically have in mind, i.e., whether you would like to use tm callbacks, change the framework, or whatever. Cheers, --Timo 2011/6/3 Timo Reimann timo.reim...@1und1.de mailto:timo.reim...@1und1.de Hi Bruno, On 03.06.2011 00:07, Bruno Bresciani wrote: I'm having doubts in the implementation of the callback function module tm. As she calls the function to record register_tmcb ()? Can someome help me? Could you be more specific on which part of the tm module you are having trouble with? If you need an example on how to use tm's callbacks you may take a look at the dialog module, specifically the files dialog.c and dlg_handlers.c. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] has_tran_tmcbs function
Hey Bruno, On 01.06.2011 16:48, Bruno Bresciani wrote: I can't understand the has_tran_tmcbs function... Can someone tell me how it works? The function checks if, for a given transaction T and a bitfield of callbacks, any of the callbacks are registered for T. It does so my logically ANDing the transaction bitfield (which represents the set of registered callbacks) with the bitfield of callbacks you would like to be checked. For each callback actually registered, the corresponding pair of bits will yield one w.r.t. to the AND operation. Therefore, if at least one of the given callbacks is registered, the entire AND operation will result in a value greater zero, thereby indicating that the transaction does have at least one of the given callbacks registered. For instance, if the bitfield of registered callbacks for T is 1011, and it is to be checked whether the callback bitfield 0110 matches, the outcome of 1011 0110 = 0010 0, meaning that at least one of the given callbacks is registered (which, in this example, happens to be the second transaction callback defined in t_hooks.h). HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6
Hey Jon, On 20.05.2011 17:31, Jon Farmer wrote: How do I represent the following if the address was IPv6? if(src_ip ==127.0.0.1) If I specify the IPv6 address with our without [] I get WARNING:core:fix_socket_list: could not rev. resolve ipv6_addr Maybe Iñaki's brand new ipops module is something for you: http://sip-router.org/docbook/sip-router/branch/master/modules/ipops/ipops.html HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] core in dialog module
Hey Anton,
On 12.05.2011 15:55, Anton Roman wrote:
my answer is inline:
2011/5/12 Timo Reimann timo.reim...@1und1.de
mailto:timo.reim...@1und1.de
As to the reason of the segfault, the dialog structure or hash table may
already be gone when unref_dlg() is called. Can you go to stack #0 and
tell us what the value of each of the following data structures is (use
p data structure in gdb):
*dlg
d_table
d_table-entries
Here you have:
(gdb) p *dlg
$1 = {ref = 793790803, next = 0xa0d4b4f20303032, prev =
0x504953203a616956, h_id = 808333871, h_entry = 1346655535, state =
775174432,
lifetime = 841888562, start_ts = 892219952, dflags = 808794678, sflags
= 1648046134, toroute = 1668178290, toroute_name = {
s = 0x62344768397a3d68 Address 0x62344768397a3d68 out of bounds,
len = 946221643}, from_rr_nb = 1886534457, tl = {
next = 0x72460a0d30363035, prev = 0x6f6e4122203a6d6f, timeout =
1869445486}, callid = {
s = 0x6f6e613a7069733c Address 0x6f6e613a7069733c out of bounds,
len = 1869445486}, from_uri = {
s = 0x3230322e33322e34 Address 0x3230322e33322e34 out of bounds,
len = 1043739950}, to_uri = {
[...]
As I suspected, your dialog seems outdated already: The reference count
is 793790803, and the Call-ID is supposed to have a rough 2 billions
characters. That's what I call unique. :)
I could ask you for more details on the dump but it'd probably be
easiest if I could take a direct (gdb-)look at it. Would you mind
sending it to me in private (i.e., no CC to the mailing list) to the
address I am writing from?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] core in dialog module
Hey,
On 12.05.2011 12:37, Anton Roman wrote:
we got a core in dialog module. We are using kamailio 3.1.2. Below you
can find a full backtrace from the dump and the Kamailio compilation
options. Please, if you need further information don't hesitate to ask
me for it. I can't precise the situation when it is generated because
we have a quite high load in this server.
The call path seems to be like this:
transaction timer fires - tm module walking through callback list finds
unref_dlg() - tm module calls unref_dlg() - boom.
I wonder why unref_dlg() was registered as a tm callback in the first
place -- the dialog module shouldn't do that. Are you using any custom
modules that would possibly do such registrations?
As to the reason of the segfault, the dialog structure or hash table may
already be gone when unref_dlg() is called. Can you go to stack #0 and
tell us what the value of each of the following data structures is (use
p data structure in gdb):
*dlg
d_table
d_table-entries
Cheers,
--Timo
(gdb) bt full
#0 unref_dlg (dlg=0x7f08a9f67da8, cnt=1) at dlg_hash.c:598
d_entry = (struct dlg_entry *) 0x7f10304b8b68
#1 0x7f08ce92fa02 in run_trans_callbacks_internal
(cb_lst=0x7f08aa203e98, type=32768, trans=0x7f08aa203e28,
params=0x7fff49059a10)
at t_hooks.c:290
cbp = (struct tm_callback *) 0x7f08a9f6e7e0
backup_from = (avp_list_t *) 0x8b3330
backup_to = (avp_list_t *) 0x8b3338
backup_dom_from = (avp_list_t *) 0x8b3340
backup_dom_to = (avp_list_t *) 0x8b3348
backup_uri_from = (avp_list_t *) 0x8b3320
backup_uri_to = (avp_list_t *) 0x8b3328
#2 0x7f08ce92fc56 in run_trans_callbacks (type=32768, trans=value
optimized out, req=0x1, rpl=0x7f10304b8b68, code=-868566200)
at t_hooks.c:317
params = {req = 0x0, rpl = 0x0, param = 0x7f08a9f6e7f0, code = 0,
flags = 0, branch = 0, t_rbuf = 0x0, dst = 0x0, send_buf = {
s = 0x0, len = 0}}
#3 0x7f08ce915b36 in free_cell (dead_cell=0x7f08aa203e28) at
h_table.c:136
b = value optimized out
i = value optimized out
rpl = value optimized out
tt = value optimized out
foo = value optimized out
cbs = value optimized out
---Type return to continue, or q return to quit---
__FUNCTION__ = free_cell
#4 0x7f08ce9319f1 in wait_handler (ti=value optimized out,
wait_tl=value optimized out, data=value optimized out) at timer.c:645
p_cell = (struct cell *) 0x7f08aa203e28
#5 0x00513d8f in timer_main () at timer.c:894
No locals.
#6 0x0046501b in main_loop () at main.c:1618
i = 4
pid = value optimized out
si = (struct socket_info *) 0x0
si_desc = udp receiver child=3
sock=XXX.XXX.XXX.XX:\000\000\000\210�\231\000\000\000\000\000\031,
'\0' repeats 15 times, \001\000\000\000\000\000\000\000�\215\213,
'\0' repeats 13 times, \004, '\0' repeats 15 times,
\b\236\005I�\177\000\000\227%J\000\000\000\000
#7 0x00467873 in main (argc=value optimized out,
argv=0x7fff49059e08) at main.c:2398
cfg_stream = (FILE *) 0x12e1010
c = value optimized out
r = value optimized out
tmp = 0x7fff4905ae90
tmp_len = 32520
port = value optimized out
proto = value optimized out
ret = value optimized out
seed = 1235801225
---Type return to continue, or q return to quit---
rfd = 4
debug_save = value optimized out
debug_flag = 0
dont_fork_cnt = 0
n_lst = value optimized out
p = value optimized out
(gdb)
(gdb) quit
kamailio2:/var/kamailio# kamailio -V
version: kamailio 3.1.2 (x86_64/linux) eb24c1-dirty
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: eb24c1 -dirty
compiled on 09:35:52 Apr 28 2011 with gcc 4.3.2
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] New developer: Jason Penton
On 21.04.2011 14:54, Daniel-Constantin Mierla wrote: I want to announce Jason Penton as a new registered developer, with write access to GIT repository - his username id is 'jason.penton'. Jason already submitted an IMS-related module that Carsten added to his IMS branch in the last days, therefore expect contributions from Jason in the IMS extensions. First Timo (me), then Timo (no, not me again; the other one, Teräs), now Jason -- this place is growing! World domination is closing in! Welcome, Jason -- may your git commits be bug-free and feature-ful! Cheers! --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] planning next major release 3.2
Hey, On 20.04.2011 08:48, Daniel-Constantin Mierla wrote: On 12.04.2011 12:57, Daniel-Constantin Mierla wrote: soon we should sketch the roadmap for the next major release 3.2. There are some private git branches with lot of work on it, so we need to synchronize a bit and decide about the proper time: before or after summer. Several devels will be in Berlin for Linuxtag, but no so much overlapping for a big face to face meeting, therefore might be better to have a IRC chat conference sometime in the near future. Next week will be fine for me, say Wednesaday till Friday, in the afternoon to allow fair time of the day for US timezones. Is the virtual meeting going to take place some day this week? Or shall I postpone it to next week after Easter? I forgot was the week before the Easter and proved that it is vacation in many countries or busy shopping times. I do not know about the availability in the week after the Easter. If there are many devs ready to join, it is fine for me, otherwise we can postpone after the LinuxTag, so we can sum up discussions done by the people present there. Sounds absolutely reasonable. Thanks and cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] planning next major release 3.2
Hey, On 12.04.2011 12:57, Daniel-Constantin Mierla wrote: soon we should sketch the roadmap for the next major release 3.2. There are some private git branches with lot of work on it, so we need to synchronize a bit and decide about the proper time: before or after summer. Several devels will be in Berlin for Linuxtag, but no so much overlapping for a big face to face meeting, therefore might be better to have a IRC chat conference sometime in the near future. Next week will be fine for me, say Wednesaday till Friday, in the afternoon to allow fair time of the day for US timezones. Is the virtual meeting going to take place some day this week? Or shall I postpone it to next week after Easter? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] TLS certificate on sip-router.org expired
Heya, just noticed that the TLS certificate on sip-router.org has expired since 9.8.2010. Try an HTTPS connection to the web-page, i.e., https://sip-router.org to see. It seems to be self-signed though. Anyways, I just wanted to let you know. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] off-topic: jobs projects - figuring out the best solution
On 06.04.2011 19:38, Klaus Darilion wrote: I think a website does not give any benefit over the business mailing list. I think it does -- nobody is going to go through mailing list archives (particularly not for Mailman lists) to search for VoIP-specific job opportunities. And a job's/project's status (open/closed, contact, deadline, etc.) can be easily changed through a website which you cannot do with email. The business mailing list will still useful for announcing new jobs and possibly post a short summary though. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] RES: Suggestion dialog module / $dlg_ctx() problem.
Hey Carsten, On 31.03.2011 22:40, Carsten Bock wrote: from my part of view, that part is quite ready. Some more testing would be appreciated though, i only did a few hundred calls from a load generator with the code... But i think it should be fairly ready. I don't want to merge the whole branch into the trunk, since there are several parts not really ready for production (such as the RFC3680 support, where the saving of published data to usrloc is missing). I haven't looked too much on how to merge only dedicated directories into master, maybe someone already has experience with this? Suggestions welcome... :-) Never did it myself but there are a few pointers on the web, especially Stack Overflow . This how-to found in one SO thread looks both effective and plain easy to apply: http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ Another, more commit-oriented way: http://plasmasturm.org/log/530/ HTH, --Timo 2011/3/31 Timo Reimann timo.reim...@1und1.de: On 31.03.2011 11:43, Klaus Darilion wrote: On 30.03.2011 19:05, Alexandre Abreu wrote: Hi Timo, Maybe I wasn't clear but access dialog data in the script it's not the issue right now. My goal at this moment is to add a variable from the script into the dialog _and_ make this information available from 'dlg_list_ctx' fifo command. I am justing parsing the output of 'dlg_list_ctx' and I am trying to include the user-agent information in the attributes list. The user-agent information is available from the script ($ua). IIRC there is no such feature at the moment, but Carsten Bock recently started working on dialog-variables (see mailing list archive) in his ims branch. I agree with Klaus that Carsten's approach seems most appropriate. In fact, we have been taking his dialog variable code, fixed a few issues, and extended it. The code we use is for Kamailio 1.5, however, as we need to get it running there first. Getting the changes into the master branch is something we definitely have on our schedule though. @Carsten: Can you tell us what the status of your dialog variable code basis is? Depending on what you may have changed list I checked your branch, we may merge in our modifications. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Suggestion dialog module / $dlg_ctx() problem.
Hey, On 30.03.2011 17:55, Alexandre Abreu wrote: Using K 3.1.2. Before the setflag() that creates the dialog, I tried to use: $dlg_ctx(flags) = 1; Mar 30 12:29:03 devel kamailio: ERROR: dialog [dlg_var.c:165]: unknown PV name flags I think the problem is that when using the flag to track dialogs, the module function that's actually responsible for starting the tracking (dlg_onreq()) kicks in only after the script has finished, which, unfortunately, is too late. Does this suggestion make sense? Using another approach is it possible to execute this today? Try calling dlg_manage() before you access dialog context data in the script. I can't tell if it works for context data but it does for dialog profiles. If it still fails, an approach I'd suggest is to automatically trigger dialog creation when the user tries to access dialog data for the first time. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Installation Problem: stun feature is not compile in.
Hey Derrick, On 15.03.2011 20:39, Derrick Ding wrote: I find there are several links that show installation or store directory of Kamailio. But this link works: http://www.kamailio.org/dokuwiki/doku.php/packages:debs However it’s not complete. The last step is: #apt-get install kamailio Well, what does that command say? Now I have another question. I need support stun When I set stun_allow_stun=1 It says: stun feature is not compile in. Does that mean I need compile src to get this function work? Most presumably. If you prefer to have Debian/Ubuntu distribution packages, you may opt to download the Debian source package, adjust the debian/rules file, and re-build a STUN-supporting package. I'm not sure though why STUN isn't built in by default; maybe someone else more familiar with our Debian packages can answer that question. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio setup
On 10.03.2011 19:38, Amit Nepal wrote: Looks like the mysql server is not running. Permission denied indicates that, well, you don't have permission to connect to that MySQL server. Fix credentials, extend MySQL user permissions, or call a database operator, whichever helps first. Cheers, --Timo On 3/9/2011 2:52 PM, ro...@dmytriv.com wrote: Hello there! I’m in the process of setting my first kamailio server and run into dead end. I was following your instructions very closely at http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git I’m using Centos 5.5 i386. Everything vent pretty much fine until step 7 were I had to create MySQL database. When I run /usr/local/kamailio-3.1/etc/kamailio/kamctlrc it gives me “Permission denied” error. I was able to access kamctlrc with a text editor and uncommented DBENGINE=MYSQL. Now when I run /usr/local/kamailio-3.1/sbin/kamdbctl create I have ERROR 2002. Please take a look at the attachment. Please help. Roman ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] set_dlg_profile() in failure_route
Hey 侯旭光,
please keep SR-Users in CC so others can share in some assistance and
benefit from a solution.
On 04.03.2011 08:29, 侯旭光 wrote:
I did trace the dialog in the initial REQUEST
my script:
...
modparam(dialog,dlg_flag,4)
...
route{
if (is_method(INVITE)){
dlg_setflag(2);
dlg_manage();
...
if(avp_db_load($ruri/username,$avp(s:busyforward)))
{
setflag(26);
t_on_failure(FAIL_ONE);
}
...
}
failure_route[FAIL_ONE]{
...
if(isflagset(26)t_check_status(486))
{
$ru=$avp(s:busyforward);
append_branch();
dlg_setflag(2);
avp_delete($avp(s:busyforward));
resetflag(26);
lookup(location);
route(RELAY);
}
...
}
route[RELAY]{
if(!t_relay()){
sl_reply_error();
}
}
#--#
Is anything wrong?
You set flag 2 but showed flag 4 to be modparam'ed to the dialog flag.
Is that intentional?
Anyways, since you are doing dlg_manage() in the INVITE transaction, you
should still be fine. Just for the sake of debugging, can you set flag 4
in your 'is_method(INVITE)' block and see if it makes a difference? I
have no in-depth experience with on demand dialog tracking as we use the
dialog flag exclusively.
By the way, I see no calls to set_dlg_profile() in your route logic. Is
this really an excerpt of the configuration you are having trouble with?
Cheers,
--Timo
2011/3/3 Timo Reimann timo.reim...@1und1.de:
Hi,
On 03.03.2011 14:47, 侯旭光 wrote:
set_dlg_profile() function carshed in failure_route when I need do the
call-forwarding.
When in busy-call-forward or no-answer-forward mode ,it'll run into
the failure_route.But at the time , the route_type of the dialog is
FAILURE_ROUTE and the get_current_dialog() return NULL,
then the set_dlg_profile() function won't work.
How can I set dialog profile in the busy or no-answer call-forwarding ?
CRITIAL dialog [dlg_profile.c]: BUG - dialog not found in non
REQUEST route
ERROR dialog [dialog.c] : failed to set profile
I think you did not track the dialog in the first place, i.e., when the
initial request associated to the dialog you seek to profile was
processed.
Are you using dlg_flag, and if so, have you enabled it in REQUEST_ROUTE?
If you want to track dialogs on demand instead, try calling dlg_manage()
prior to calling set_dlg_profile(). I'm not sure if this is the most
elegant approach for your use case but it might at least work.
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] problem unreferencing dialog in dialog module
Hey,
On 03.03.2011 10:19, Anton Roman wrote:
Checking the time staps from the acc and the crash log, the BYE for
the dialog was before the crash but the To-tag is not printed from
dlg_hash.c, although it is in the acc for INVITE and BYE. Do you
have parallel forking in front of this SIP server? I mean, is there
another proxy that can do parallel forking then send two or more
branches to this instance?
AFAIK the the client who is sending that calls is not doing parallel
forking, they are sending calls over a SIP trunk to our Kamailio. They
are calling to PSTN numbers and we are sending that calls to a gateway,
so they shouldn't do parallel forking, I'll get some traces to check it.
Your trace shows that there are two worker processes dealing with the
segfault-triggering dialog, process ID 32155 and 32158. I cannot see
from your trace what module caused the latter process to execute
unref_dlg() in dlg_hash.c, however.
What I can tell though is that the crash happens because too much dialog
reference counter decrementing takes place. Although I have no clue why,
I believe the implementation of unref_dlg_unsafe() (a macro) could be
somewhat more robust by not unlinking and destroying a dialog when the
counter drops below zero. That is, instead of running the following block
if ((_dlg)-ref=0) { \
unlink_unsafe_dlg( _d_entry, _dlg);\
LM_DBG(ref =0 for dialog %p\n,_dlg);\
destroy_dlg(_dlg);\
}\
for _dlg-ref = 0, I see no reason to change the compare operator to ==.
Of course, that just cures the symptoms. A coredump would be really
helpful in identifying the root of the crash problem but I don't know
why it wasn't generated in your case. Your configuration looks good to me.
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] problem unreferencing dialog in dialog module
Argh:
On 03.03.2011 11:11, Timo Reimann wrote:
What I can tell though is that the crash happens because too much dialog
reference counter decrementing takes place. Although I have no clue why,
^
...the crash happens,
I believe the implementation of unref_dlg_unsafe() (a macro) could be
somewhat more robust by not unlinking and destroying a dialog when the
counter drops below zero. That is, instead of running the following block
if ((_dlg)-ref=0) { \
unlink_unsafe_dlg( _d_entry, _dlg);\
LM_DBG(ref =0 for dialog %p\n,_dlg);\
destroy_dlg(_dlg);\
}\
for _dlg-ref = 0, I see no reason to change the compare operator to ==.
I see no reason *not* to change compare operator to ==. That is, I want
the block to execute iff the reference counter is found to be zero.
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 1.5.5 No TLS Segmentation Fault
f:cCm:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W: rand_source = 0x4b7d9c /dev/urandom seed = 3664355638 __FUNCTION__ = main --Stagg On Feb 15, 2011, at 4:39 AM, Timo Reimann wrote: Hi Stagg, with regards to the failing function, there was a bugfix in the dialog module which, unfortunately, didn't make it into 1.5.5 in time (revision 6049). Could you try the latest SVN of 1.5 and see if it solves the issue? Thanks. Cheers, --Timo On 14.02.2011 21:07, Stagg Shelton wrote: Hello, We have been having a problem with Kamilio faulting and dumping core files on occasion. I have not been able to reproduce the failure at will, but notice the back trace seems to point toward actions with the dialogue. Below is from a backtrace of a core file from just a few minutes ago. Can anyone determine what may have caused the system to error and stop processing? Thanks Stagg Core was generated by `/sbin/kamailio -m 512'. Program terminated with signal 11, Segmentation fault. #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 474 d_entry = (d_table-entries[dlg-h_entry]); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-5.fc11.x86_64 db4-4.7.25-11.fc11.x86_64 e2fsprogs-libs-1.41.9-2.fc11.x86_64 elfutils-libelf-0.147-1.fc11.x86_64 glibc-2.10.2-1.x86_64 keyutils-libs-1.2-5.fc11.x86_64 krb5-libs-1.6.3-31.fc11.x86_64 libacl-2.2.49-3.fc11.x86_64 libattr-2.4.43-3.fc11.x86_64 libcap-2.16-4.fc11.1.x86_64 libconfuse-2.6-2.fc11.x86_64 libgcc-4.4.1-2.fc11.x86_64 libselinux-2.0.80-1.fc11.x86_64 lm_sensors-3.1.0-1.fc11.x86_64 lua-5.1.4-3.fc11.x86_64 mysql-libs-5.1.46-1.fc11.x86_64 net-snmp-libs-5.4.2.1-13.fc11.x86_64 nspr-devel-4.8.4-1.3.fc11.x86_64 nss-devel-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 openssl-0.9.8n-1.fc11.x86_64 pcre-7.8-2.fc11.x86_64 perl-libs-5.10.0-82.fc11.x86_64 popt-1.13-5.fc11.x86_64 radiusclient-ng-0.5.6-4.fc11.x86_64 rpm-libs-4.7.2-1.fc11.x86_64 tcp_wrappers-libs-7.6-55.fc11.x86_64 xz-libs-4.999.9-0.1.beta.20091007git.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64 (gdb) bt full #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 d_entry = 0x0 __FUNCTION__ = unref_dlg #1 0x7f8a11d5180f in unref_dlg_from_cb (t=0x7f89f7d9c660, type=4096, param=0x7f8a1836a6e0) at dlg_handlers.c:622 dlg = 0x7f89f7e07470 #2 0x7f8a18138ea3 in run_trans_callbacks (type=4096, trans=0x7f89f7d9c660, req=0x0, rpl=0x0, code=0) at t_hooks.c:240 cbp = 0x7f89f7dc30e8 backup = 0x71a9d0 trans_backup = 0x __FUNCTION__ = run_trans_callbacks #3 0x7f8a181273cc in free_cell (dead_cell=0x7f89f7d9c660) at h_table.c:132 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x7fff4282f190 p = 0x7f89f7d3b068 #4 0x7f8a18127bb6 in free_hash_table () at h_table.c:345 p_cell = 0x7f89f7d9c660 tmp_cell = 0x0 i = 4075 #5 0x7f8a181342a4 in tm_shutdown () at t_funcs.c:109 __FUNCTION__ = tm_shutdown #6 0x004529f6 in destroy_modules () at sr_module.c:321 t = 0x7349d0 foo = 0x734910 __FUNCTION__ = destroy_modules #7 0x0041f6b4 in cleanup (show_status=1) at main.c:331 No locals. #8 0x00420597 in handle_sigs () at main.c:517 chld = 0 chld_status = 134 i = 12 do_exit = 1 ---Type return to continue, or q return to quit--- shutdown_time = 60 __FUNCTION__ = handle_sigs #9 0x004217b5 in main_loop () at main.c:859 chd_rank = 12 i = 4 pid = 21442 si = 0x0 __FUNCTION__ = main_loop #10 0x00423410 in main (argc=3, argv=0x7fff4282f498) at main.c:1321 cfg_log_stderr = 0 cfg_stream = 0x1fe1010 c = -1 r = 0 tmp_len = 0 port = 0 proto = 4910128 ret = -1 rfd = 4 tmp = 0x7fff4282ff8a options = 0x4b77e0 f:cCm:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W: rand_source = 0x4b7d9c /dev/urandom seed = 3628387751 __FUNCTION__ = main (gdb) (gdb) quit ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 1.5.5 No TLS Segmentation Fault
Hi Stagg, with regards to the failing function, there was a bugfix in the dialog module which, unfortunately, didn't make it into 1.5.5 in time (revision 6049). Could you try the latest SVN of 1.5 and see if it solves the issue? Thanks. Cheers, --Timo On 14.02.2011 21:07, Stagg Shelton wrote: Hello, We have been having a problem with Kamilio faulting and dumping core files on occasion. I have not been able to reproduce the failure at will, but notice the back trace seems to point toward actions with the dialogue. Below is from a backtrace of a core file from just a few minutes ago. Can anyone determine what may have caused the system to error and stop processing? Thanks Stagg Core was generated by `/sbin/kamailio -m 512'. Program terminated with signal 11, Segmentation fault. #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 474 d_entry = (d_table-entries[dlg-h_entry]); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-5.fc11.x86_64 db4-4.7.25-11.fc11.x86_64 e2fsprogs-libs-1.41.9-2.fc11.x86_64 elfutils-libelf-0.147-1.fc11.x86_64 glibc-2.10.2-1.x86_64 keyutils-libs-1.2-5.fc11.x86_64 krb5-libs-1.6.3-31.fc11.x86_64 libacl-2.2.49-3.fc11.x86_64 libattr-2.4.43-3.fc11.x86_64 libcap-2.16-4.fc11.1.x86_64 libconfuse-2.6-2.fc11.x86_64 libgcc-4.4.1-2.fc11.x86_64 libselinux-2.0.80-1.fc11.x86_64 lm_sensors-3.1.0-1.fc11.x86_64 lua-5.1.4-3.fc11.x86_64 mysql-libs-5.1.46-1.fc11.x86_64 net-snmp-libs-5.4.2.1-13.fc11.x86_64 nspr-devel-4.8.4-1.3.fc11.x86_64 nss-devel-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 openssl-0.9.8n-1.fc11.x86_64 pcre-7.8-2.fc11.x86_64 perl-libs-5.10.0-82.fc11.x86_64 popt-1.13-5.fc11.x86_64 radiusclient-ng-0.5.6-4.fc11.x86_64 rpm-libs-4.7.2-1.fc11.x86_64 tcp_wrappers-libs-7.6-55.fc11.x86_64 xz-libs-4.999.9-0.1.beta.20091007git.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64 (gdb) bt full #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 d_entry = 0x0 __FUNCTION__ = unref_dlg #1 0x7f8a11d5180f in unref_dlg_from_cb (t=0x7f89f7d9c660, type=4096, param=0x7f8a1836a6e0) at dlg_handlers.c:622 dlg = 0x7f89f7e07470 #2 0x7f8a18138ea3 in run_trans_callbacks (type=4096, trans=0x7f89f7d9c660, req=0x0, rpl=0x0, code=0) at t_hooks.c:240 cbp = 0x7f89f7dc30e8 backup = 0x71a9d0 trans_backup = 0x __FUNCTION__ = run_trans_callbacks #3 0x7f8a181273cc in free_cell (dead_cell=0x7f89f7d9c660) at h_table.c:132 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x7fff4282f190 p = 0x7f89f7d3b068 #4 0x7f8a18127bb6 in free_hash_table () at h_table.c:345 p_cell = 0x7f89f7d9c660 tmp_cell = 0x0 i = 4075 #5 0x7f8a181342a4 in tm_shutdown () at t_funcs.c:109 __FUNCTION__ = tm_shutdown #6 0x004529f6 in destroy_modules () at sr_module.c:321 t = 0x7349d0 foo = 0x734910 __FUNCTION__ = destroy_modules #7 0x0041f6b4 in cleanup (show_status=1) at main.c:331 No locals. #8 0x00420597 in handle_sigs () at main.c:517 chld = 0 chld_status = 134 i = 12 do_exit = 1 ---Type return to continue, or q return to quit--- shutdown_time = 60 __FUNCTION__ = handle_sigs #9 0x004217b5 in main_loop () at main.c:859 chd_rank = 12 i = 4 pid = 21442 si = 0x0 __FUNCTION__ = main_loop #10 0x00423410 in main (argc=3, argv=0x7fff4282f498) at main.c:1321 cfg_log_stderr = 0 cfg_stream = 0x1fe1010 c = -1 r = 0 tmp_len = 0 port = 0 proto = 4910128 ret = -1 rfd = 4 tmp = 0x7fff4282ff8a options = 0x4b77e0 f:cCm:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W: rand_source = 0x4b7d9c /dev/urandom seed = 3628387751 __FUNCTION__ = main (gdb) (gdb) quit ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Proposal to extend acc/dialog modules in order to log CDRs
Hey Daniel, On 01.02.2011 21:15, Daniel-Constantin Mierla wrote: On 2/1/11 8:18 PM, Timo Reimann wrote: [...] Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. From header URI is not accounted automatically, you can specify any variable that can contain caller id as you need (e.g., it can be an AVP that you previously set for in config) -- see *_extra parameters of acc module. I initially thought about having a cdr_extra parameter similar to log_extra. However, I see a problem with AVPs which live in single transactions to work with dialogs that span multiple transactions. Say you want to have a CDR field that contains combined or concatenated data from multiple transactions, e.g., all Kamailio flags set in the INVITE, ACK, and BYE transaction. How could that be accomplished with a log_extra-like module parameter? At what times would AVP be parsed? IMHO, you will need to keep such data per dialog which is why I came up with the idea of storing CDR-specific data in the dialog. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. Not sure what you mean here with acc module will make sure ..., but I hope is not going to be cross reference/dependency, so that acc has to walk through dlg structures. If I get you right, by cross reference/dependency you mean that A requires B and vice versa, i.e., cyclic dependency. I do not intend to let that happen. Instead, the acc module would use getter functions attached to the dialog interface (which is what I mean by acc module will make sure). dialog would never touch the acc module or even know about the fact that the acc module is using it. In order to accomplish this, the dialog module would need to be extended such that dialog-specific data may be stored for the duration of a dialog (which is not possible to this day AFAICS). Carsen committed some code in this regard in his IMS branch, as I could see from commit log, check: http://lists.sip-router.org/pipermail/sr-dev/2011-January/010197.html Missed that one. Will take a look at it. Regarding the acc module, a couple of new features need to be implemented: First, the introduction of another module parameter called something like cdr_fields that comprises the set of key names designated for CDR inclusion. Hence, a line like modparam(acc, cdr_fields, caller, callee, foo, bar) The db_extra has the format of 'key=variable', where the 'key' is the db column name and the 'variable' is the name of PV holding the value to be stored. I think the format is better than just providing the names of the dialog keys. See my comment above for why binding PVs to CDR fields does not seem appropriate in this case. Third, the CDR is persisted to either log file, database, or both. If this new thing is not going to support what acc module API has for backends (radius is missing), then will not make sense to tie the two. dialog module can do its accounting alone. Of course, I would want to take advantage of acc's existing backend connectors. There's no need to re-invent the wheel, acc will still be responsible for writing out CDRs; the difference is that a few additional calls to a well-defined dialog interface will be used in order to collect the data that constitute the CDR. Regarding db accounting: - I have in my todo list the plan to enhance acc to export a functions like acc_start() and acc_stop(), with the goal of storing the initial record for start of the call (acc_start() for INVITE) then at the end of the call (BYE) acc_stop() will just set extra details (end time, duration, etc) - practically then dialog module can call acc_start() and acc_stop() via some inter-module api. The benefit is that even sip server crashes suddently, there is an acc start event to indicate a call Regarding server crashes/restarts, instead of persisting events ASAP via acc module I would recommend using dialog's existing feature to store dialog data in a database. That way, every piece of CDR-specific data stored in dialogs in my approach will be saved automatically (as governed by dialog module configuration), and there will be no need to produce partial CDRs in the first place. - such functionality is independent of dlg module or any new call tracking extension in the future, also writing full CDR can be achieved from config file by tracking INVITE and BYE, calling acc_start()/acc_stop() from cfg Tracking INVITE and BYE messages from
Re: [SR-Users] Proposal to extend acc/dialog modules in order to log CDRs
On 02.02.2011 14:03, Daniel-Constantin Mierla wrote: On 01.02.2011 21:15, Daniel-Constantin Mierla wrote: On 2/1/11 8:18 PM, Timo Reimann wrote: [...] Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. From header URI is not accounted automatically, you can specify any variable that can contain caller id as you need (e.g., it can be an AVP that you previously set for in config) -- see *_extra parameters of acc module. I initially thought about having a cdr_extra parameter similar to log_extra. However, I see a problem with AVPs which live in single transactions to work with dialogs that span multiple transactions. well, some of the avps are transaction persistent, but there are also global avps which are available as long as kamailio runs. None of these should be used, I gave avp just as generic PV example. The idea was to make new PV available with the data stored by dlg module. Ok, so instead of providing getter/setter functions, let's use PVs. However, users will have varying needs regarding the to-be-defined CDR fields next to the canonical ones (start time, end time, duration, etc.). We, for example, use a rather large number of fields, many of them being too specific for general integration into upstream Kamailio. That's why I would rather see a way to dynamically specify CDR fields. Carsten's new code would be the right approach to do this, right? His dlg_var PV takes arbitrary key/value pairs which looks just like what is needed. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. Not sure what you mean here with acc module will make sure ..., but I hope is not going to be cross reference/dependency, so that acc has to walk through dlg structures. If I get you right, by cross reference/dependency you mean that A requires B and vice versa, i.e., cyclic dependency. I do not intend to let that happen. Instead, the acc module would use getter functions attached to the dialog interface (which is what I mean by acc module will make sure). dialog would never touch the acc module or even know about the fact that the acc module is using it. But then acc has to know the dialog internals, what the getter function will return and how to access those structures. PV framework is exactly the same, but available for all components/modules, no need to develop specif ones each time. Agreed, let's use PVs. If you think of Carsten's new dlg_var PV, it's basically just a way to get/set arbitrary values; so I suppose this is what I should have expressed. With your solution, dialog module has to know acc api to call the recording function, and acc has to know dialog module to know its exported structures. This is cross dependency imo. I think this point shows the major difference between our solutions: My approach doesn't make the dialog module call the recording function. Instead, the recording function is called by the acc module as soon as the dialog terminates where call termination can is observed by means of using dialog callbacks. (Sorry, I should have possibly mentioned the words dialog callback before.) Therefore, module dependency is unidirectional: acc registers for some dialog callbacks and, upon execution of a callback, records the CDR. Third, the CDR is persisted to either log file, database, or both. If this new thing is not going to support what acc module API has for backends (radius is missing), then will not make sense to tie the two. dialog module can do its accounting alone. Of course, I would want to take advantage of acc's existing backend connectors. There's no need to re-invent the wheel, acc will still be responsible for writing out CDRs; the difference is that a few additional calls to a well-defined dialog interface will be used in order to collect the data that constitute the CDR. What will happen if a new call tracking module will be available, should acc be changed again? I am not completely convinced that call tracking is such a flexible thing even though you gave a few examples below. A call is pretty much a dialog, and proper tracking of a dialog should be dialog module's job. Moreover, I believe your approach has some dependency issues as well -- see my comment at the very end of this mail. - such functionality is independent of dlg module or any new call tracking extension in the future, also writing full CDR can be achieved from config file by tracking INVITE and BYE, calling
Re: [SR-Users] set_dlg_profile not working?
Hi Ricardo,
first of all: What version of Kamailio are you using?
On 11.01.2011 22:17, Ricardo Martinez wrote:
I’m trying to count the calls to a specific gateway. So I’m using the
dialog module. This route is done before the final relay.
*if ( set_dlg_profile(gws,$rd) ) {*
*xlog(L_INFO,set_dlg_profile exitoso);*
What could be happening?
Have you set up the profile named gws using modparam and
profiles_with_values?
Have you enabled dialog tracking, either by specifying dlg_flag
generally or calling dlg_manage() specifically on calls that matter?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] set_dlg_profile not working?
Hi Ricardo, On 12.01.2011 13:38, Ricardo Martinez wrote: I'm using the kamailio versión 3.1.0. The profile gws is a profile with_values # dialog params -- modparam(dialog, dlg_flag, 4) modparam(dialog, profiles_with_value, gws) I'm not using the last two parameters that you mention. Could you guide me on how to use them? dlg_manage() allows you to track the dialog currently being processed, i.e., on-demand dialog tacking. However, since you have already defined flag 4 as dialog flag, you don't need dlg_manage(): It's supposed to happen automatically for all calls. This requires enabling the configured flag (4 in your case) though. Have you done so prior to assigning the call to the profile? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] set_dlg_profile not working?
Hey, On 12.01.2011 15:45, Ricardo Martinez wrote: Timo. I'm asking, because in a previous test with Kamailio 1.5 I never used dlg_manage() and I was sure it was working that time. It may have worked before because you enabled the dialog flag back then (see below on how to do that). So.. anyway.. I used dlg_manage() before the set_dlg_profile(gws,$rd) and now it is working ok. If I wanted to do the same but with the flags, how can this be done? Simply enable the flag that you have specified in the dialog module parameter labeled dlg_flag like this: setflag(4); (It's 4 here because you assigned flag 4 to dlg_flag). See also the first paragraph of section 2 in the module documentation http://sip-router.org/docbook/sip-router/branch/3.1/modules_k/dialog/dialog.html#id2552194 and the description on dlg_manage(): http://sip-router.org/docbook/sip-router/branch/3.1/modules_k/dialog/dialog.html#id2524314 Cheers, --Timo -Mensaje original- De: sr-users-boun...@lists.sip-router.org [mailto:sr-users-boun...@lists.sip-router.org] En nombre de Timo Reimann Enviado el: miércoles, 12 de enero de 2011 11:11 Para: Ricardo Martinez CC: sr-users@lists.sip-router.org Asunto: Re: [SR-Users] set_dlg_profile not working? Hi Ricardo, On 12.01.2011 13:38, Ricardo Martinez wrote: I'm using the kamailio versión 3.1.0. The profile gws is a profile with_values # dialog params -- modparam(dialog, dlg_flag, 4) modparam(dialog, profiles_with_value, gws) I'm not using the last two parameters that you mention. Could you guide me on how to use them? dlg_manage() allows you to track the dialog currently being processed, i.e., on-demand dialog tacking. However, since you have already defined flag 4 as dialog flag, you don't need dlg_manage(): It's supposed to happen automatically for all calls. This requires enabling the configured flag (4 in your case) though. Have you done so prior to assigning the call to the profile? Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio logging
On 02.01.2011 20:48, Noa Resare wrote: Is there a way to get a sensible amount of logging done from kamailio? Being new to the VoIP space (but with plenty of experience with i.e. web and email servers) I tried to get a running system by installing the kamailio package and starting up, trying to get it to behave by looking at log output. I use the blink SIP client in OSX, that has a SIP data dump log view and from that I can deduce that the server returns SIP/2.0 483 Too Many Hops, however there is nothing helpful in the server logs. If I set debug=2 i get nothing useful, and if I set debug=3 I get insane amounts of logging, thousands of lines per connection attempt. Finding something meaningful in there seems like a herculean task. I agree with you that debug level 3+ is not for the faint of heart due to the fact that every single module turns very verbose at these levels. What I'd found really useful to have is module- and core-specific log switching; that is, be able to set debug levels on a per-module basis in addition to turning it on and off in the Kamailio core. That would surely ease finding issues when you know that a problem is likely related to a specific (set of) module(s), especially in a high-load productive environment. Not sure about the feasibility of such a change and possible implications to overall runtime but I suppose it could be done in a performance-friendly fashion. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [dialog] No dialog stored if Via has no branch
Hey Iñaki, On 22.12.2010 17:44, Iñaki Baz Castillo wrote: I receive llamadas from a Cisco pre-RFC 3261 (non symmetric SIP and no ;branch parameter). It seems that dialog module cannot account such calls. Maybe branch parameter is required? The dialog module shouldn't need the Via header or branch parameter for dialog tracking. All that is required for building an initial dialog is Call-ID, To URI, From URI, and From tag (see dlg_onreq() and dlg_new_dialog() in dlg_handlers.c). Do you see any error messages in the log files when receiving such pre-RFC 3261 calls? Cheers, --Timo PS: llamadas? Calls? Hablo solo un poco de español. :) ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [dialog] No dialog stored if Via has no branch
On 23.12.2010 11:37, Iñaki Baz Castillo wrote: 2010/12/23 Timo Reimann timo.reim...@1und1.de: The dialog module shouldn't need the Via header or branch parameter for dialog tracking. All that is required for building an initial dialog is Call-ID, To URI, From URI, and From tag (see dlg_onreq() and dlg_new_dialog() in dlg_handlers.c) Hi Timo, sorry, a stupid error of mine: I removed the dlg_manage() call for PSTN inbound calls some weeks ago :( Ok -- good to hear the state of the dialog code is fine (at least to one regard :) ). Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Crash on processing dialog BYE
On 20.10.2010 16:47, Ovidiu Sas wrote: mediaproxy and qos: http://www.kamailio.org/docs/modules/3.1.x/modules/mediaproxy.html#id3080297 http://www.kamailio.org/docs/modules/3.1.x/modules_k/qos.html#id2747034 sst too, AFAIK. Cheers, --Timo On Wed, Oct 20, 2010 at 10:31 AM, Alex Balashov abalas...@evaristesys.com wrote: Not that I know of. Remind me which modules have dialog dependency? On 10/20/2010 09:27 AM, Ovidiu Sas wrote: Are you using any module on top of the dialog module? Regards, Ovidiu Sas On Tue, Oct 19, 2010 at 7:00 PM, Alex Balashov abalas...@evaristesys.com wrote: We had another one of these today, under high call volume: (gdb) where #0 0x003a60430265 in raise () from /lib64/libc.so.6 #1 0x003a60431d10 in abort () from /lib64/libc.so.6 #2 0x00530a91 in qm_free (qm=0x2b343e1aa000, p=0x2b343eddf6e8, file=0x2b343dd860c3 dialog: dlg_hash.c, func=0x2b343dd86b42 destroy_dlg, line=176) at mem/q_malloc.c:447 #3 0x2b343dd6a2ea in destroy_dlg (dlg=0x2b343fe1d6f8) at dlg_hash.c:176 #4 0x2b343dd6d33a in unref_dlg (dlg=0x2b343fe1d6f8, cnt=1) at dlg_hash.c:591 #5 0x2b343dd73a04 in profile_cleanup (msg=value optimized out, flags=value optimized out, param=0x6) at dlg_profile.c:317 #6 0x004be9a1 in exec_post_script_cb (msg=0xa06e80, type=value optimized out) at script_cb.c:195 #7 0x004989f0 in receive_msg ( buf=0x8b6300 BYE sip:15746317...@yyy.yyy.yyy.yyy:5060 SIP/2.0\r\nRecord-Route: sip:yyy.yyy.yyy.yyy;lr;ftag=gK0ebaf6d4\r\nRecord-Route: sip:67.231.8.89;lr;ftag=gK0ebaf6d4\r\nVia: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bKd757, len=value optimized out, rcv_info=0x7fff4a043230) at receive.c:221 #8 0x0052576a in udp_rcv_loop () at udp_server.c:532 #9 0x00468dcd in main_loop () at main.c:1554 #10 0x0046be9f in main (argc=value optimized out, argv=0x7fff4a043508) at main.c:2398 Is this a regression, or memory corruption from something else? This is with CANCEL_REASON_SUPPORT #undef'd in tm_reply.h, btw. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog Module - how???
Hi,
On 14.10.2010 17:50, Nicolas Rüger wrote:
I'm trying to get dialog module working..
...my problem is that nothing is stored in the database in table dialog
yet. I'm looking for CDRs there...
I inserted in kamailio.cfg:
[...]
loadmodule dialog.so
[...]
modparam(dialog, db_url, mysql://XXX:x...@localhost/openser)
modparam(dialog, db_mode, 1)
modparam(dialog, dlg_flag, 4)
modparam(dialog, dlg_match_mode, 1)
[...]
route {
if (is_method(INVITE)) {
dlg_manage();
}
}
[...]
I'm actually not sure what dlg_flag is good for, but kamailio doesn't start
without.
Flag to be used for marking if a dialog should be constructed for the
current request (this make sense only for initial requests).
dlg_flag marks the flag which, when enabled, causes the module to
track the dialog.
I've never used dlg_manage() to start tracking myself but cannot
recognize any wrong usage. Can you enable flag 4 at the top of your
route block and check if it fills the DB then?
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dialog Module - how???
Hey,
On 14.10.2010 18:22, Nathan Angelacos wrote:
Actually, you want dlg_manage() to be called for every message, not just
INVITES
route {
dlg_manage();
}
[...]
Are you sure dlg_manage() is really required to be called on every
message of the dialog (or supposed to be used that way)?
If you look at dialog.c, w_dlg_manage() simply call's dlg_handlers.c's
dlg_new_dialog() which is also called for new INVITE messages when the
flag is set. So AFAICS, it should set up dialog tracking quite similarly
and have it work without any further interaction.
Cheers,
--Timo
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Is this a BUG?
Hey Brian, On 11.08.2010 13:01, dotnetdub wrote: I see this in every call setup.. CRITICAL: dialog [dlg_hash.c:591]: bogus event 6 in state 2 for dlg 0xaf933bd0 [3739:1530909163] with clid '5959362a340dfa7938cf52ae1ba4b...@my.proxy.com mailto:5959362a340dfa7938cf52ae1ba4b...@my.proxy.com' and tags 'as5b636a8a' '' I am running SIP-Router 3.01 I note this thread: http://www.mail-archive.com/sr-...@lists.sip-router.org/msg05668.html but it's inconclusive. The conclusion took place in a different thread: Daniel committed a patch to master on 2 July http://lists.sip-router.org/pipermail/sr-dev/2010-July/008097.html and asked people to test the patch on 5 July prior to backporting it into 3.0: http://lists.sip-router.org/pipermail/sr-dev/2010-July/008109.html Klaus Feichtinger took the time for validation, and things seem to be looking good. However, AFAICS the patch wasn't brought into 3.0 which means that you still run on a race-conditioned version of SIP-Router that causes the log message to appear quite frequently yet. Daniel, considering Klaus' successful test runs would it be acceptable to get the patch (commit f1c35c1325) into 3.0 from your point of view? It doesn't seem to cause any issue but I would like to get it sorted. It definitely doesn't cause any critical issues to the proper working of SIP-Router. The worst it can do is mess up a call's dialog state when the race condition kicks in. Once the race condition is ruled out, occurrences of the message boil down to broken UAs as Henning pointed out already. HTH, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Is this a BUG?
On 11.08.2010 23:39, dotnetdub wrote: The same endpoint never causes our Kamailio 1.4.1 servers to generate this message. I have watched the SIP transactions and the ACK always seems to arrive at the correct point in the dialog. The endpoint is Asterisk 1.4.22. The reason why you never saw the message show up on Kamailio 1.4 was probably that the same race condition was fixed in Kamailio at some point (I believe the thread you referred to in your initial mail mentioned that, specifically by Ovidiu). However, when the tm module changed in SIP-Router 3 somewhat, the fix was left out and only brought back in by Daniel at the beginning of July. As I pointed out in my last mail, this fix apparently didn't make it into any branch other than master yet. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] freezing for major release 3.1
Iñaki Baz Castillo wrote: 2010/7/21 Carsten Bock li...@bock.info: Hi, it is rather simple: The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol) states the following: Update session, creating a new one if it doesn't exist. U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]] The NATHelper Module currently does not send the optional notify socket to the RTPProxy. The enhancement makes this notify_socket configurable and will send it to the RTP-Proxy, if set. On the other end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket (XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it does now. If the Socket starts with http://;, it will query the Proxy by executing dlg_list with the Call-ID and the From-Tag. If the dialog is found, it will call dlg_end_dlg with the according parameters... It's great :) However take into account that dlg_end_dlg just works for confirmed dialogs (state 4). There are new fixes about it by Timo so it doesn't leak when running dlg_end_dlg for an in-progress dialog. Also I think that a new commit from Time makes dlg_end_dlg just to work in case the dialog state is 4 so nothing would be required from the Rtpproxy. Terminating in-progress dialog is still not implemented (but planned AFAIK). All correct; little addendum: Proxy-initiated dialog termination works both in state 3 (2xx response received but ACK request from UAC yet missing) and 4 (2xx response and ACK request received) because the dialog module stores caller data already in state 3. I neglected that detail in the commit message as both states are denoted committed in Kamailio but it doesn't make much of a difference. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] freezing for major release 3.1
Timo Reimann wrote: Iñaki Baz Castillo wrote: 2010/7/21 Carsten Bock li...@bock.info: Hi, it is rather simple: The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol) states the following: Update session, creating a new one if it doesn't exist. U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]] The NATHelper Module currently does not send the optional notify socket to the RTPProxy. The enhancement makes this notify_socket configurable and will send it to the RTP-Proxy, if set. On the other end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket (XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it does now. If the Socket starts with http://;, it will query the Proxy by executing dlg_list with the Call-ID and the From-Tag. If the dialog is found, it will call dlg_end_dlg with the according parameters... It's great :) However take into account that dlg_end_dlg just works for confirmed dialogs (state 4). There are new fixes about it by Timo so it doesn't leak when running dlg_end_dlg for an in-progress dialog. Also I think that a new commit from Time makes dlg_end_dlg just to work in case the dialog state is 4 so nothing would be required from the Rtpproxy. Terminating in-progress dialog is still not implemented (but planned AFAIK). All correct; little addendum: Proxy-initiated dialog termination works both in state 3 (2xx response received but ACK request from UAC yet missing) and 4 (2xx response and ACK request received) because the dialog module stores caller data already in state 3. I neglected that detail in the commit message as both states are denoted committed in Kamailio but it doesn't make much of a difference. s/committed/confirmed/ --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
