Hi,
o Jerome Martin [03/13/09 14:43]:
Hi Again Stephan,
I've just read the dsm docs you sent to me, and decided to try to use
dsm to recreate my app instead of just porting it.
It will be a good exercise to learn more about dsm, and get a headstart
into it.
thats cool!
So now I have several questions :-)
thanks for the input. I am always interested in making it useful for
actual applicability (also outside of what specifically I am using it for).
The dsm mods in 1.1.0 seem to lack many modules. Should I use rev 1312
of dsm app with 1.1.0 core or go for the whole svn
tree ? Is the current svn rev. stable enough for production ?
monitoring is only available in svn, for this you would need it (though
you can backport patches).
apart from this, adds to dsm, and removing of unixsock, not much
difference 1.1/trunk yet. so I would use it for production.
DSM seems to depend on the dsm mods enabled, and not import any standard
set of functions from the sems apps available, nor core ....
the idea is to implement core functionality as dsm module, and thus be
able to (re)implement all standard applications easily. where module
export DI API, this can be used with DI() action (e.g. I am using xmlrpc
client from xmlrpc2di from DSM; voicebox should be easy to reimplement
using msg_storage DI functions).
I have seen the nice example using mod_conference, but am unsure what
kind of mods I would need to write in order to access
the functions needed for my application. Tha app is basically a
click2dial scenario. Let's call the "caller" leg A and "callee" leg B.
uh. I already feared it is b2b...
What I need is :
- Trigger from an external app the call to caller, leg A. I will do this
via xmlrpc.
Should I call auth_dial and pass it the dsm as target application, or
directly implement a dialout in my dsm app ?
I think it's fine to use dial_auth for DI interface. We should add a
function that takes some dictionary as parameter, which then is fed into
the variables of the dsm session. lets see...
- Wait for caller to key in some DTMF while being played an audio file
before starting leg B
- Be able to control both legs from the DSM app
you have two legs (calls), with separate state machines. you can send
events to the other leg using the normal
postEvent(session_id, variable_name)
posts event with variable as DSM event parameter
postEvent(session_id, var)
posts event with complete current variable set as DSM event parameter
- Playback various audio files to A, in reaction to the progress /
release causes in B
that requires onOtherBye and onOtherReply to be exposed as DSM event
- Be able to be in the RTP path (obviously) while B leg is not
connected, but re INVITE and leave the RTP path when B connects
Am I supposed to select the Factories needed for those functionnalities
and map them to dsm writing dsm mods ?
hm. there is something needed for this, the last point from the DSM todo:
o session creation from module
that would allow to have other types of DSMSession created in module,
for example b2bua sessions. another solution is, like in IVR, to just
use B2BSession as standard. that is probably the simplest to do.
(besides, I would guess I can come up with a solution for b2b with
stream relay, that does not require amb2absession.)
Well, this is all for the "starting points" I need to adress before
actually working on the (rather complex) logic of my app :-)
Stefan
Regards,
*Jérôme Martin **| **LongPhone*
*Responsable Architecture Réseau*
122, rue la Boetie | 75008 Paris
Tel : +33 (0)1 56 26 28 44
Fax : +33 (0)1 56 26 28 45
Mail : *[email protected]
Web : www.longphone.com <http://www.longphone.com>
--
Stefan Sayer
VoIP Services
[email protected]
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
