[Serdev] Re: [Devel] session termination
JF
jfkavaka at gmail.com
Thu Jan 12 12:52:41 CET 2006
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
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlgm.c
Type: application/octet-stream
Size: 7562 bytes
Desc: not available
Url : http://openser.org/pipermail/devel/attachments/20060112/47a42396/dlgm.obj
More information about the Devel
mailing list