[Serdev] Re: [Devel] session termination
JF
jfkavaka at gmail.com
Mon Jan 16 20:55:39 CET 2006
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
> > > >
> > >
> > >
> >
> >
>
More information about the Devel
mailing list