[OpenSER-Devel] dialog callbacks: mi enhancements

[Ovidiu Sas]

Hello Dan,

The problem that I'm trying to solve was described at the beginning of
this thread, maybe with not enough clarity (please follow also
http://sourceforge.net/tracker/index.php?func=detail&aid=1933630&group_id=139143&atid=743022).

I will use as an example the sst module.  The sst module has a call
specific context:
typedef struct sst_info_st {
    enum sst_flags requester;
    enum sst_flags supported;
    unsigned int interval;
} sst_info_t;

The pointer to the sst call specific context is saved inside the
dialog callbacks.
I would like to be able to interrogate - via the mi interface - the
content of the sst call specific context, but the only way to do it is
via the dialog module.  Therefore, I need a callback from the dialog
module into the sst module in order to be able to retrieve the sst
call specific context.

As an example, here's the output of the dlg_list mi command, with the
content of the sst call specific context (see the last line: "sst::
requester_flags=4 supported_flags=0 interval=2400"):
dialog::  hash=898:913256572
        state:: 2
        timestart:: 0
        timeout:: 0
        callid:: 1-24613 at 10.11.10.148
        from_uri:: sip:sipp at 10.11.10.148:5050
        from_tag:: 1
        caller_contact:: sip:sipp at 10.11.10.148:5050
        caller_cseq:: 1
        caller_route_set::
        caller_bind_addr:: udp:10.11.10.63:5060
        to_uri:: sip:4165555001 at 10.11.10.63:5060
        to_tag::
        callee_contact::
        callee_cseq::
        callee_route_set::
        callee_bind_addr::
        sst::  requester_flags=4 supported_flags=0 interval=2400


Hope this answer your question.


Regards,
Ovidiu Sas


On Thu, Apr 17, 2008 at 5:31 PM, Dan Pascu <dan at ag-projects.com> wrote:
> On Thursday 17 April 2008, Ovidiu Sas wrote:
>
> > Well ... define generic.
>  > This particular callback is meant to be used via the MI interface.
>  > You can define other type of callbacks and reuse the extra pointer
>  > that was defined (see void **x_param inside struct dlg_cb_params).
>
>  That's exactly my point. I was asking the question with a purpose, that is
>  to highlight that the proposed change would define a dialog callback that
>  can only be used by one module and in a very specific context, callback
>  that is on the other hand made public. What is the use of a callback that
>  is advertised as public, but can only be used by one module for a very
>  specific task?
>
>  I mean, can't that module export a public API that the dialog module can
>  use to get the information it needs? That would be more clean, yet it
>  would still be an awkward reverse dependency.
>
>  IMO, I still find such a dependency to be very problematic to be forged
>  into any kind of generic interface. The direct dependency is fine. Any
>  module built on top of the dialog module can use the dialog's public API
>  to access the dialog state/events. But when you have it the other way
>  around, the dialog module cannot possibly know what modules will be built
>  on top of it to be able to generically extract information from them.
>  This kind of dependency is not only awkward, but it is very narrow in its
>  scope, which hardly justifies it being put in a public API that none
>  uses, except that module.
>
>  I'm sure that if we would know in more detail what problem you are trying
>  to solve (as opposed to how you try to solve it), many people here could
>  offer good suggestions that may turn into a better design.
>
>  --
>  Dan
>