Hello.
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
Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:565]: pvar "dlg_ctx" has an invalid name param [flags]
Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:720]: wrong char [)/41] in [$dlg_ctx(flags)] at [14 (5)]
Mar 30 12:29:03 devel kamailio: : <core> [cfg.y:3409]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 308, column 9-23: unknown script pseudo variable $dlg_ctx(flags)
Right now, my goal is to add the user-agent content header ($ua) from caller/callee and list them through 'dlg_list_ctx'.
I would suggest something like that:
Request route:
$dlg_ctx(set->ua_src) = $ua;
On reply route:
$dlg_ctx(set->ua_dst) = $ua;
dlg_list_ctx:
.
ua_src:: X-Lite 3.0 build 666
ua_dst:: Linksys PAP2
.
Does this suggestion make sense? Using another approach is it possible to execute this today?
Thanks,
Alexandre
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
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).
Thanks, Alexandre
-----Mensagem original----- De: Timo Reimann [mailto:timo.reimann@1und1.de] Enviada em: quarta-feira, 30 de março de 2011 13:24 Para: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Alexandre Abreu Assunto: 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
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.
regards klaus
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
Hi Timo,
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... :-)
Greetings from Hamburg/Munich, Carsten
2011/3/31 Timo Reimann timo.reimann@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
On 31.03.2011 22:40, Carsten Bock wrote:
(such as the RFC3680 support, where the saving of published data to usrloc is missing).
Why saving the data to usrloc? Do you want to use this as an replication mechanism?
regards klaus
Hi Klaus,
yes, that is a possible use-case. You could, for example, use dedicated machine for offline message storage with MSilo. When the message was stored, you could SUBCRIBE for the registration status at the registrar and one the user gets online, the user will get his message delivered. That is one possible use-case... Or if you want to keep the registration status synchronized on different registrars, you could use this as well...
Carsten
2011/4/1 Klaus Darilion klaus.mailinglists@pernau.at:
On 31.03.2011 22:40, Carsten Bock wrote:
(such as the RFC3680 support, where the saving of published data to usrloc is missing).
Why saving the data to usrloc? Do you want to use this as an replication mechanism?
regards klaus
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-...
Another, more commit-oriented way:
http://plasmasturm.org/log/530/
HTH,
--Timo
2011/3/31 Timo Reimann timo.reimann@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
Hi,
i've just pushed my extensions to dialog (and minor changes to rr) into master. Worked like a charm, with the exception, that the changelog does not contain my original commit notices....
Carsten
2011/4/1 Timo Reimann timo.reimann@1und1.de:
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-...
Another, more commit-oriented way:
http://plasmasturm.org/log/530/
HTH,
--Timo
2011/3/31 Timo Reimann timo.reimann@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
Hello
So this means that I can copy the dialog extensions from master-git into branch 3.1 and test the stuff (like I did with rtpproxy).
Alexandre
-----Mensagem original----- De: kaiserbock2@googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome de Carsten Bock Enviada em: segunda-feira, 4 de abril de 2011 12:09 Para: Timo Reimann Cc: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List; Klaus Darilion; Alexandre Abreu Assunto: Re: [SR-Users] RES: Suggestion dialog module / $dlg_ctx() problem.
Hi,
i've just pushed my extensions to dialog (and minor changes to rr) into master. Worked like a charm, with the exception, that the changelog does not contain my original commit notices....
Carsten
2011/4/1 Timo Reimann timo.reimann@1und1.de:
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.reimann@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
-- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com
Hi Alexandre,
yes, that should do...
Carsten
2011/4/4 Alexandre Abreu alexandre.abreu@redt.com.br:
Hello
So this means that I can copy the dialog extensions from master-git into branch 3.1 and test the stuff (like I did with rtpproxy).
Alexandre
-----Mensagem original----- De: kaiserbock2@googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome de Carsten Bock Enviada em: segunda-feira, 4 de abril de 2011 12:09 Para: Timo Reimann Cc: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List; Klaus Darilion; Alexandre Abreu Assunto: Re: [SR-Users] RES: Suggestion dialog module / $dlg_ctx() problem.
Hi,
i've just pushed my extensions to dialog (and minor changes to rr) into master. Worked like a charm, with the exception, that the changelog does not contain my original commit notices....
Carsten
2011/4/1 Timo Reimann timo.reimann@1und1.de:
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.reimann@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
-- Carsten Bock http://www.ng-voice.com mailto:carsten@ng-voice.com
-
Alexandre Abreu -
Carsten Bock -
Klaus Darilion -
Timo Reimann