[OpenSER-Devel] dialog callbacks: mi enhancements

[Ovidiu Sas]

Forgot to mention, the callback is generic and it can be used by any
module sitting on top of the dialog module.
In the extra pointer from the callback structure I expect to find a
pointer to a mi_node structure (which is not module specific).  Each
module is responsible of providing it's data in a well known format,
in this particular case, an mi_node structure.

As an example, I'm working on a module that will track the sdp for
both caller and callee (using the openser integrated sdp parser).
Here's the output of the dlg_list mi command with both sst and qos
(the module that I'm working on) loaded (see both sst and qos nodes
attached to the mi tree structure):

dialog::  hash=364:1735939007
        state:: 2
        timestart:: 0
        timeout:: 0
        callid:: 1-30200 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
        qos:: negotiated_sdp
                sdp::  m_dir=1 m_id=1 method=INVITE cseq=1 negotiation=1
                        session:: callee cnt_disp= streams=1
                                stream:: 0 media=audio port=18074
transport=RTP/AVP payloads_num=2
                                        payload:: 100 codec=X-NSE
sendrecv= ptime=
                                        payload:: 0 codec=PCMU sendrecv= ptime=
                        session:: caller cnt_disp=session streams=1
                                stream:: 0 media=audio port=6002
transport=RTP/AVP payloads_num=3
                                        payload:: 18 codec= sendrecv= ptime=
                                        payload:: 1 codec= sendrecv= ptime=
                                        payload:: 0 codec=PCMU
sendrecv=inactive ptime=



Regards,
Ovidiu Sas

On Thu, Apr 17, 2008 at 6:23 PM, Ovidiu Sas <osas at voipembedded.com> 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).
>
>  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
>  >
>