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 <[EMAIL PROTECTED]> wrote: > Hi, > Pls find comments inline: > > On 1/14/06, Greger V. Teigre <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > To: "Greger V. Teigre" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]>; <[email protected]>; <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > To: <[email protected]>; <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > >> > >[email protected] > > > >> > >http://openser.org/cgi-bin/mailman/listinfo/devel > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > > > > > _______________________________________________ > > > > Serdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mail.iptel.org/mailman/listinfo/serdev > > > > > > > > > > > > > > > _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
