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.
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
2010/7/21 Timo Reimann timo.reimann@1und1.de:
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.
Thanks a lot.
Hey,
Iñaki Baz Castillo wrote:
2010/7/21 Timo Reimann timo.reimann@1und1.de:
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.
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
2010/7/22 Timo Reimann timo.reimann@1und1.de:
Hey,
Iñaki Baz Castillo wrote:
2010/7/21 Timo Reimann timo.reimann@1und1.de:
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.
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?
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.
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
2010/7/22 Carsten Bock lists@bock.info:
- 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.
Hey,
Iñaki Baz Castillo wrote:
2010/7/22 Timo Reimann timo.reimann@1und1.de:
Hey,
Iñaki Baz Castillo wrote:
2010/7/21 Timo Reimann timo.reimann@1und1.de:
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.
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?
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? :)
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
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
2010/7/23 Henning Westerholt henning.westerholt@1und1.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 :)
-
Carsten Bock -
Henning Westerholt -
Iñaki Baz Castillo -
Timo Reimann