[OpenSER-Devel] dialog callbacks: mi enhancements

Ovidiu Sas osas at voipembedded.com
Fri Apr 18 01:03:21 CEST 2008


see inline

On Thu, Apr 17, 2008 at 6:52 PM, Dan Pascu <dan at ag-projects.com> wrote:
> On Friday 18 April 2008, Ovidiu Sas wrote:
>  > 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).
>
>  Maybe I missed or overlooked it.
>
>
>  >
>  > 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.
>
>  Here by the saved context inside the dialog module, you mean the param
>  that is passed to the dialog callbacks?

Yes, the param that is passed during the dialog callback registration.
As an example, see:
       dlg_binds->register_dlgcb(did, DLGCB_MI_CTX_QUERY,
                       sst_dialog_mi_ctx_query_CB, info, NULL);

"info" is the pointer to the sst call specific context


>
>  > 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
>
>  Forgive me if I ask some obvious question here, but why can't the sst
>  module implement a MI interface and offer that information directly,
>  instead of going through an awkward reverse dependency? From the
>  description it looks like if the dialog module would implement a function
>  in the public API to retrieve this context, then the sst module could
>  implement the MI interface itself? Maybe I just miss something obvious.
>  Because it is clear the dialog module is ill equipped to serve information
>  from other modules of which it knows nothing, without it having to
>  implement code to deal with such foreign information from other modules.
>  Can you elaborate a bit why this MI interface cannot be implemented in
>  the sst module and it has to be in the dialog module?

The sst module doesn't keep the pointer to the call specific context.
It relies on the dialog callbacks to retrieve the pointer to it's own
context.
The dialog module is already keeping track of all existing
dialogs/calls.  There's no need for all the modules sitting on top of
the dialog module to keep their own list (it will be redundant).


>  > 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.
>
>  I think I'm getting close. If you clarify that last bit I asked above, I
>  think I will have a pretty good picture.


Thank you for you time spent trying to understand this particular
issue and the proposed solution.


Regards,
Ovidiu Sas



More information about the Devel mailing list