21 Jul
2010
21 Jul
'10
6:31 p.m.
Hi, it would be very useful if custom variables could be attached to a
dialog, and also the possibility of retreving, via MI, the list of
dialogs with a specific variable value and also terminating it.
In my case when my kamailio handles a call it sets it a "client_name"
profile which is enough to list/terminate all the calls belonging to
such client.
But sometimes I need to terminate those calls with a specific CLI, and
the CLI is not the From username but a custon PAI inserted by
Kamailio. This info is not stored with the dialog.
A workaround could be settting the dialog in two profiles: client_name
and PAI, but I think it's not very elegant.
Also I think that storing custom variables within each dialog could be
very useful for other subjects.
Opinions? Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
21 Jul
21 Jul
7:53 p.m.
Hey Iñaki,
Iñaki Baz Castillo wrote:
Hi, it would be very useful if custom variables could
be attached to a
dialog, and also the possibility of retreving, via MI, the list of
dialogs with a specific variable value and also terminating it.
In my case when my kamailio handles a call it sets it a "client_name"
profile which is enough to list/terminate all the calls belonging to
such client.
But sometimes I need to terminate those calls with a specific CLI, and
the CLI is not the From username but a custon PAI inserted by
Kamailio. This info is not stored with the dialog.
A workaround could be settting the dialog in two profiles: client_name
and PAI, but I think it's not very elegant.
Also I think that storing custom variables within each dialog could be
very useful for other subjects.
Opinions? Thanks.
Have you considered using profiles that are associated to specific
values? I haven't tried them myself but it looks pretty much like what
you seek. Consider exported functions *profile(profile, value), and the
MI function "profile_list_dlgs":
http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2532160
Let me know what you think of this.
Cheers,
--Timo
10:03 p.m.
2010/7/21 Timo Reimann <timo.reimann(a)1und1.de>de>:
Ops, really sorry, in fact I *alreay* use it! and it's a good
solution. Sorry, not sure what I was thinking about when asked the
question XD
However I still think that having custom variables associated to
dialogs could be useful for some other cases.
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
In my case
when my kamailio handles a call it sets it a "client_name"
profile which is enough to list/terminate all the calls belonging to
such client.
But sometimes I need to terminate those calls with a specific CLI, and
the CLI is not the From username but a custon PAI inserted by
Kamailio. This info is not stored with the dialog.
A workaround could be settting the dialog in two profiles: client_name
and PAI, but I think it's not very elegant.
Also I think that storing custom variables within each dialog could be
very useful for other subjects.
Opinions? Thanks.
Have you considered using profiles that are associated to specific
values? I haven't tried them myself but it looks pretty much like what
you seek. Consider exported functions *profile(profile, value), and the
MI function "profile_list_dlgs":
22 Jul
22 Jul
8:37 p.m.
Hey,
Iñaki Baz Castillo wrote:
2010/7/21 Timo Reimann <timo.reimann(a)1und1.de>de>:
Ops, really sorry, in fact I *alreay* use it! and it's a good
solution. Sorry, not sure what I was thinking about when asked the
question XD
However I still think that having custom variables associated to
dialogs could be useful for some other cases.
Hmm, not sure if I get you. According to the docs, you can pass
pseudo-variables to profiles already now. How would the current dialog
interface need to differ in your opinion?
Could be elaborate a bit please?
Thanks,
--Timo
In my
case when my kamailio handles a call it sets it a "client_name"
profile which is enough to list/terminate all the calls belonging to
such client.
But sometimes I need to terminate those calls with a specific CLI, and
the CLI is not the From username but a custon PAI inserted by
Kamailio. This info is not stored with the dialog.
A workaround could be settting the dialog in two profiles: client_name
and PAI, but I think it's not very elegant.
Also I think that storing custom variables within each dialog could be
very useful for other subjects.
Opinions? Thanks.
Have you considered using profiles that are associated to
specific
values? I haven't tried them myself but it looks pretty much like what
you seek. Consider exported functions *profile(profile, value), and the
MI function "profile_list_dlgs":
9:23 p.m.
2010/7/22 Timo Reimann <timo.reimann(a)1und1.de>de>:
Hey,
Iñaki Baz Castillo wrote:
Yes, sure:
Actually you can set a dialog into profiles and also set a value for
such profiles. Imagine I want to add a custom header "X-Client-Id:
NNNN" to the BYE depending on a profile value set in for the dialog in
the initial INVITE. Then I must do:
if is_in_profile("client_id", "1000")
hf_append("X-Client-Id: 1000\r\n");
else if is_in_profile("client_id", "1001")
hf_append("X-Client-Id: 1001\r\n");
else if is_in_profile("client_id", "1002")
hf_append("X-Client-Id: 1002\r\n");
[...]
end
Do you get the point? There is no way to get all the profiles/values a
dialog belongs to, so in my example (really a stupid example, I know)
I should create a very big "if" statement with all the possible values
in a fixed way (not feasible in most of the real cases).
What I would like is something like:
# In the initial INVITE after setting the dialog:
$dlg("client_id") = 1000;
# When processing the BYE:
hf_append("X-Client-Id: $dlg("client_id")\r\n");
Do you get the point? :)
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2010/7/21 Timo Reimann
<timo.reimann(a)1und1.de>de>:
Ops, really sorry, in fact I *alreay* use it! and it's a good
solution. Sorry, not sure what I was thinking about when asked the
question XD
However I still think that having custom variables associated to
dialogs could be useful for some other cases.
Hmm, not sure if I get you. According to the docs, you can pass
pseudo-variables to profiles already now. How would the current dialog
interface need to differ in your opinion?
Could be elaborate a bit please? In my
case when my kamailio handles a call it sets it a "client_name"
profile which is enough to list/terminate all the calls belonging to
such client.
But sometimes I need to terminate those calls with a specific CLI, and
the CLI is not the From username but a custon PAI inserted by
Kamailio. This info is not stored with the dialog.
A workaround could be settting the dialog in two profiles: client_name
and PAI, but I think it's not very elegant.
Also I think that storing custom variables within each dialog could be
very useful for other subjects.
Opinions? Thanks.
Have you considered using profiles that are associated to
specific
values? I haven't tried them myself but it looks pretty much like what
you seek. Consider exported functions *profile(profile, value), and the
MI function "profile_list_dlgs": 
10:53 p.m.
Hi,
More ideas:
- store the original From-Header in a Dialog-Parameter in order to replace
the "From"-Header in subsequential requests (e.g. the uac-Module stores this
in the RR-Headers, would be nice to store this in a Dialog-Parameter
instead)
- validate subsequential "Routes" by comparing them with the defined Route
in the original request?
Just some ideas,
Carsten
11:03 p.m.
2010/7/22 Carsten Bock <lists(a)bock.info>fo>:
- store the original From-Header in a Dialog-Parameter
in order to replace
the "From"-Header in subsequential requests (e.g. the uac-Module stores this
in the RR-Headers, would be nice to store this in a Dialog-Parameter
instead)
Nice, this avoids xtra params in Route header (some gateways complain
against long Route or Record-Route headers).
- validate subsequential "Routes" by
comparing them with the defined Route
in the original request?
Yes, but note that SIP URI comparison (RFC 3261 19.1.4) is a complex
task. If it's weel done it could be a good security addition (avoid
spoofed BYE's and so).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
23 Jul
23 Jul
11:16 a.m.
Hey,
Iñaki Baz Castillo wrote:
2010/7/22 Timo Reimann <timo.reimann(a)1und1.de>de>:
Yeah, got it now and endorsing your proposal -- your use case shows that
trying to solve certain dialog issues with profiles can become quite
hackish. So what we need in addition to existing value-specific profiles
is dialog-specific custom variables/attribute.
Cheers,
--Timo
Hey,
Iñaki Baz Castillo wrote:
Yes, sure:
Actually you can set a dialog into profiles and also set a value for
such profiles. Imagine I want to add a custom header "X-Client-Id:
NNNN" to the BYE depending on a profile value set in for the dialog in
the initial INVITE. Then I must do:
if is_in_profile("client_id", "1000")
hf_append("X-Client-Id: 1000\r\n");
else if is_in_profile("client_id", "1001")
hf_append("X-Client-Id: 1001\r\n");
else if is_in_profile("client_id", "1002")
hf_append("X-Client-Id: 1002\r\n");
[...]
end
Do you get the point? There is no way to get all the profiles/values a
dialog belongs to, so in my example (really a stupid example, I know)
I should create a very big "if" statement with all the possible values
in a fixed way (not feasible in most of the real cases).
What I would like is something like:
# In the initial INVITE after setting the dialog:
$dlg("client_id") = 1000;
# When processing the BYE:
hf_append("X-Client-Id: $dlg("client_id")\r\n");
Do you get the point? :) 2010/7/21 Timo Reimann
<timo.reimann(a)1und1.de>de>:
Hmm, not sure if I get you.
According to the docs, you can pass
pseudo-variables to profiles already now. How would the current dialog
interface need to differ in your opinion?
Could be elaborate a bit please? > In my case when my kamailio handles a call it
sets it a "client_name"
> profile which is enough to list/terminate all the calls belonging to
> such client.
> But sometimes I need to terminate those calls with a specific CLI, and
> the CLI is not the From username but a custon PAI inserted by
> Kamailio. This info is not stored with the dialog.
>
> A workaround could be settting the dialog in two profiles: client_name
> and PAI, but I think it's not very elegant.
> Also I think that storing custom variables within each dialog could be
> very useful for other subjects.
>
> Opinions? Thanks.
Have you considered using profiles that are associated to specific
values? I haven't tried them myself but it looks pretty much like what
you seek. Consider exported functions *profile(profile, value), and the
MI function "profile_list_dlgs":
Ops, really sorry, in fact I *alreay*
use it! and it's a good
solution. Sorry, not sure what I was thinking about when asked the
question XD
However I still think that having custom variables associated to
dialogs could be useful for some other cases. 
11:51 a.m.
On Thursday 22 July 2010, Iñaki Baz Castillo wrote:
[..]
Do you get the point? There is no way to get all the profiles/values a
dialog belongs to, so in my example (really a stupid example, I know)
I should create a very big "if" statement with all the possible values
in a fixed way (not feasible in most of the real cases).
What I would like is something like:
# In the initial INVITE after setting the dialog:
$dlg("client_id") = 1000;
# When processing the BYE:
hf_append("X-Client-Id: $dlg("client_id")\r\n");
Do you get the point? :)
Hi Iñaki,
did you also looked into the $dlg_ctx PV? At least you can set here some
arbitrary flags, maybe this could be extended to also allow the storage
of some other values? Have not used it so far, the docs are also a bit
spare in this regards:
http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:1.5.x#dlg_ctx_attr
Cheers,
Henning
11:56 a.m.
2010/7/23 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
Hi Iñaki,
did you also looked into the $dlg_ctx PV? At least you can set here some
arbitrary flags, maybe this could be extended to also allow the storage
of some other values? Have not used it so far, the docs are also a bit
spare in this regards:
http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:1.5.x#dlg_ctx_attr
Yes, extending such structure to allow other values is exactly what
would make sense IMHO :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5236
days inactive
5238
days old
9 comments
4 participants
participants (4)
-
Carsten Bock -
Henning Westerholt -
Iñaki Baz Castillo -
Timo Reimann