[Serdev] Re: [Devel] session termination
JF
jfkavaka at gmail.com
Tue Jan 17 20:01:28 CET 2006
Sounds great!
Is this feature (dialog serialization and db storage/retrieval) also
available in OpenSER?
JF
On 1/17/06, Vaclav Kubart <vaclav.kubart at iptel.org> wrote:
> Hi all,
> the dialog module is still under development :-), but I think, that the
> serialization function will stay there. (PA and RLS modules need and will
> need to store confirmed dialogs.)
>
> This function stores dialog into string (but it may contain binary
> zeros!) and this string can be stored into database in BLOB (like from
> PA and RLS modules). I thought, that the storing and reloading of the
> dialog should do dialog module itself, but it seems, that it is better
> to leave it on the caller (pa, rls, ...).
>
> You can see the usage in functions set_watcher_db_data (db_add_watcher)
> and db_read_watcherinfo in modules/pa/watcher.c or a bit cleaner code
> in modules/rls/db_rls.c (rls_db_add, db_load_rls).
>
> I'm going to add into dialog module some functions for quick dialog finding
> (according to ID using hash table).
>
> There is short incomplete documentation for CDS library which is on the
> bottom of serialization in source form under lib/cds/doc (you can
> translate it into html using xmlto ("xmlto html cds.xml" in that
> directory).
>
> Vaclav
>
> On Mon, Jan 16, 2006 at 09:44:38PM +0100, Greger V. Teigre wrote:
> > Hi JF,
> >
> > Good to hear that you figured it out!
> >
> > Yes, you should definitely look at the dialog module. It's used by the new
> > presence awareness module (PA). Have a look at pa_mod.c in modules/pa for
> > an example of how it is used. It uses the new cds lib for serializing a
> > dialog. I don't think it's quite finished yet, but don't think it's much.
> > Vaclav could probably help you out here and probably point out if there are
> > anything obvious missing.
> > g-)
> >
> > ----- Original Message -----
> > From: "JF" <jfkavaka at gmail.com>
> > To: "Greger V. Teigre" <greger at teigre.com>
> > Cc: <serdev at iptel.org>; <devel at openser.org>
> > Sent: Monday, January 16, 2006 8:55 PM
> > Subject: Re: [Serdev] Re: [Devel] session termination
> >
> >
> > >Hi Greger, all,
> > >
> > >I think I got that CANCELing early dialogs issue fixed. I think I was
> > >confused before. Just by correctly adding the t_cancel function from
> > >the previous mail to the TM API, an early dialog (I actually tested it
> > >while the call was in the Ringing state) was cancelled correctly!
> > >
> > >This still needs reviewing, but the next step I guess should be
> > >discussing how best to store the dialog table. This could potencially
> > >waste a lot of resources if kept in memory as the calls in progress
> > >grow in number. So maybe a database storage mode would be appropriate.
> > >I recently tripped on some code in SER HEAD which partially kinda does
> > >just that. It's the 'dialog' module. Maybe it can be used here.
> > >
> > >What do people think about all this?
> > >
> > >JF
> > >
> > >
> > >On 1/16/06, JF <jfkavaka at gmail.com> wrote:
> > >>Hi,
> > >>Pls find comments inline:
> > >>
> > >>On 1/14/06, Greger V. Teigre <greger at teigre.com> wrote:
> > >>> Sounds like a good start. I'm not an expert on the tm module, far from,
> > >>> so
> > >>> I'm afraid I cannot help you much on new_dlg_uas(). I'm not sure how
> > >>> provisional responses with dialog info are actually handled. However,
> > >>> this
> > >>> is what i suggest:
> > >>> - I give you cvs access to experimental(HEAD) for your new module
> > >>
> > >>Great! I created a berlios account with username: jfkavaka
> > >>
> > >>> - Hopefully Andrei has some time to provide some feedback on your code
> > >>> so
> > >>> far and how it can be adapted to use new functionality in HEAD
> > >>> - Anybody interested (I know there are quite some number) can get the
> > >>> code
> > >>> and provide feedback and suggestions
> > >>
> > >>Yes, I hope core SER / OpenSER developers (and everyone interested)
> > >>provide some feedback :-)
> > >>I can't dedicate full time to this work, but I'll be glad to put it on
> > >>CVS and with help I think it can evolve into a kind of
> > >>"session-statefulness" module for SER.
> > >>
> > >>>
> > >>> As to initiating messages etc, as you have already started doing, the
> > >>> "state-near" operations can (and probably should) be done as a module.
> > >>> However, the more complex B2BUA functionality is probably better
> > >>> handled in
> > >>> a process external to SER. I have been thinking about this and wonder
> > >>> whether SEMS can be used. SER communicates quite efficiently through
> > >>> socket
> > >>> to sems, and a sems module could be made to receive a header from SER,
> > >>> ex.
> > >>> P-B2BUA-Script: some_name_for_a_script
> > >>> The SEMS module could use a python script to receive the message and
> > >>> initate
> > >>> actions.
> > >>
> > >>Well, I'm not at all familiar with SEMS. But the idea of moving the
> > >>more complex B2BUA processing out of SER and integrating through a
> > >>socket API sounds nice.
> > >>
> > >>> g-)
> > >>>
> > >>
> > >>JF
> > >>
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "JF" <jfkavaka at gmail.com>
> > >>> To: "Greger V. Teigre" <greger at teigre.com>
> > >>> Cc: <serdev at iptel.org>; <devel at openser.org>;
> > >>> <daniel.junkmail at gmail.com>;
> > >>> <andrei at iptel.org>
> > >>> Sent: Thursday, January 12, 2006 12:52 PM
> > >>> Subject: Re: [Serdev] Re: [Devel] session termination
> > >>>
> > >>>
> > >>> Thank you, Greger.
> > >>>
> > >>> I think I found the thread you mentioned:
> > >>> http://mail.iptel.org/pipermail/serdev/2005-October/005954.html
> > >>>
> > >>> Last month I made some experiments building a module for storing
> > >>> dialog info and terminating sessions. Attached is the (very
> > >>> experimental) code. I used openser 1.0.0 (but I guess TM and module
> > >>> building are basically equal). It uses the TM API, as suggested in
> > >>> that thread. The module currently handles only one dialog at a time,
> > >>> but a dialog table can and should be added.
> > >>> I was able to make it work for terminating an established call (tested
> > >>> it by calling the terminate_dialog function from the script, when
> > >>> receiving an OPTIONS test message).
> > >>> Now I was looking at termination of early dialogs, which would involve
> > >>> sending CANCELs. For this I tried extending the TM API by adding the
> > >>> following function to t_cancel.c:
> > >>>
> > >>> int t_cancel(str *callid, str *cseq) {
> > >>> struct cell *t;
> > >>> if( t_lookup_callid(&t, *callid, *cseq) < 0 ) {
> > >>> LOG(L_ERR,"ERROR: t_cancel: lookup failed\n");
> > >>> return -1;
> > >>> }
> > >>> /* tell tm to cancel the call */
> > >>> DBG("DEBUG: t_cancel: now calling cancel_uacs\n");
> > >>> (*cancel_uacs)(t,~0);
> > >>>
> > >>> /* t_lookup_callid REF`d the transaction for us, we must UNREF
> > >>> here!
> > >>> */
> > >>> UNREF(t);
> > >>> }
> > >>>
> > >>> and exposing it on the API (tm_load.h). But then I realised that some
> > >>> changes to new_dlg_uas() function in TM would be needed (check
> > >>> previous mail). Since things were getting too much into TM changes, I
> > >>> decided to request guidance from the developers.
> > >>>
> > >>> So I propose to continue the discussion on the list on how this whole
> > >>> feature of enabling call stateful behaviour (probably not full B2BUA)
> > >>> in (Open)SER should be implemented (and hope the attached code helps),
> > >>> including the most difficult part, as Andrei mentioned in the
> > >>> referenced thread:
> > >>>
> > >>> > The reallly difficult part is coming with some meaningfull script
> > >>> > commands /special configuration language / api so that you end up
> > >>> > with a
> > >>> > very flexible solution (like redirect the call to x, after 30s
> > >>> > redirect
> > >>> > to y and after another 120s terminate the call).
> > >>>
> > >>> With best regards,
> > >>>
> > >>> JF
> > >>>
> > >>> On 1/12/06, Greger V. Teigre <greger at teigre.com> wrote:
> > >>> > Yes, there was somebody looking into that. Andrei also provided an
> > >>> > overview
> > >>> > of the requirements for implementing this and offered his support.
> > >>> > Since
> > >>> > then I have heard nothing from that person, so I don't know anything
> > >>> > about
> > >>> > status.
> > >>> > I don't have the time to search for the thread right now, but it's
> > >>> > on
> > >>> > serdev and not too many months back.
> > >>> > g-)
> > >>> >
> > >>> > ----- Original Message -----
> > >>> > From: "JF" <jfkavaka at gmail.com>
> > >>> > To: <devel at openser.org>; <serdev at iptel.org>
> > >>> > Sent: Tuesday, January 10, 2006 12:46 PM
> > >>> > Subject: [Serdev] Re: [Devel] session termination
> > >>> >
> > >>> >
> > >>> > > Hi all,
> > >>> > >
> > >>> > > Maybe someone can have a look at this issue and provide some
> > >>> > > comments/guidance.
> > >>> > > It's about building a module to store dialog information in order
> > >>> > > to
> > >>> > > allow SER to terminate sessions.
> > >>> > >
> > >>> > > Thanks in advance.
> > >>> > >
> > >>> > > JF
> > >>> > >
> > >>> > >
> > >>> > > On 12/6/05, JF <jfkavaka at gmail.com> wrote:
> > >>> > >> Hi Bogdan,
> > >>> > >>
> > >>> > >> Thank you for that. I managed to add a t_cancel function to tm
> > >>> > >> api,
> > >>> > >> but now I realize that in tm/dlg.c the code to create EARLY
> > >>> > >> dialogs is
> > >>> > >> missing in new_dlg_uas() (only 2xx replies are handled, creating
> > >>> > >> CONFIRMED dialogs). To clarify, I'm using new_dlg_uas() via tm api
> > >>> > >> to
> > >>> > >> create this dlg structure from within a TMCB_RESPONSE_IN callback
> > >>> > >> within this new "dialog management" module.
> > >>> > >>
> > >>> > >> Now, according to RFC 3261, on section 13.2.2.1:
> > >>> > >> "If a provisional response has a tag in the To field, and if the
> > >>> > >> dialog ID of the response does not match an existing dialog, one
> > >>> > >> is
> > >>> > >> constructed"
> > >>> > >>
> > >>> > >> So first a check must be done for To tag presence, then try to
> > >>> > >> find a
> > >>> > >> dialog (by ID) in the dialog table the module maintains.
> > >>> > >> So I would have to change new_dlg_uas() to create EARLY dialogs
> > >>> > >> also
> > >>> > >> and only call it if previous checks pass.
> > >>> > >>
> > >>> > >> Does this seem reasonable? Could you (or the other core
> > >>> > >> developers)
> > >>> > >> provide some guidance here? I have read somewhere in the list that
> > >>> > >> there were plans to implement a similar module...
> > >>> > >>
> > >>> > >> JF
> > >>> > >>
> > >>> > >> On 12/6/05, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> > >>> > >> > Hi,
> > >>> > >> >
> > >>> > >> > The TM API does not export any cancel function right now.
> > >>> > >> > Instead
> > >>> > >> > there
> > >>> > >> > is a FIFO function for generating cancels: t_uac_cancel (see
> > >>> > >> > modules/tm/tm.c +553) . maybe this will help you in adding an
> > >>> > >> > API
> > >>> > >> > function.
> > >>> > >> >
> > >>> > >> > regards,
> > >>> > >> > bogdan
> > >>> > >> >
> > >>> > >> > JF wrote:
> > >>> > >> >
> > >>> > >> > >Hi,
> > >>> > >> > >
> > >>> > >> > >I've been playing around with TM callbacks and the TM API
> > >>> > >> > >trying to
> > >>> > >> > >build a module which mantains dialog info in order to permit
> > >>> > >> > >session
> > >>> > >> > >termination. For now I managed (in a very experimental way) to
> > >>> > >> > >have
> > >>> > >> > >a
> > >>> > >> > >function exposed to the script which initiates (appropriately
> > >>> > >> > >built
> > >>> > >> > >with dialog info) BYE transactions to UAs and effectively
> > >>> > >> > >terminates
> > >>> > >> > >the call. Later this could be done via FIFO or unix socket
> > >>> > >> > >command
> > >>> > >> > >taking some kind of "dialog identifier" parameter...
> > >>> > >> > >But sending BYEs to terminate calls only works if the dialog is
> > >>> > >> > >already in the CONFIRMED state.
> > >>> > >> > >For early dialogs, CANCELs should be used. But in the TM API
> > >>> > >> > >there
> > >>> > >> > >is
> > >>> > >> > >no cancel function. Is there any other way of canceling a
> > >>> > >> > >request on
> > >>> > >> > >behalf of an UA from within an openser module? Or would the TM
> > >>> > >> > >API
> > >>> > >> > >need to be extended?
> > >>> > >> > >
> > >>> > >> > >Thanks in advance for any insights.
> > >>> > >> > >
> > >>> > >> > >JF
> > >>> > >> > >
> > >>> > >> > >_______________________________________________
> > >>> > >> > >Devel mailing list
> > >>> > >> > >Devel at openser.org
> > >>> > >> > >http://openser.org/cgi-bin/mailman/listinfo/devel
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> >
> > >>> > >> >
> > >>> > >>
> > >>> > >
> > >>> > > _______________________________________________
> > >>> > > Serdev mailing list
> > >>> > > Serdev at iptel.org
> > >>> > > http://mail.iptel.org/mailman/listinfo/serdev
> > >>> > >
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>
> > >
> >
> > _______________________________________________
> > Serdev mailing list
> > Serdev at iptel.org
> > http://mail.iptel.org/mailman/listinfo/serdev
>
> ----- End forwarded message -----
>
> _______________________________________________
> Serdev mailing list
> Serdev at iptel.org
> http://mail.iptel.org/mailman/listinfo/serdev
>
More information about the Devel
mailing list