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?
> 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?
> 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:: [EMAIL PROTECTED]
> from_uri:: sip:[EMAIL PROTECTED]:5050
> from_tag:: 1
> caller_contact:: sip:[EMAIL PROTECTED]:5050
> caller_cseq:: 1
> caller_route_set::
> caller_bind_addr:: udp:10.11.10.63:5060
> to_uri:: sip:[EMAIL PROTECTED]: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.
--
Dan
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
