Hi,
Raphael and me were discussing how to improve the invocation and
starting of DSM applications, which was prompted by general
modifications in the way calls start introduced with the offer_answer
branch.
Through the rewrite of the SDP offer/answer implementation in the
offer_answer branch, we are now e.g. getting proper support for call
flows with delayed SDP negotiation, which also means that the API to
applications changes a bit: the onSessionStart event handler may be
run when processing INVITE, 200 or ACK, and is actually triggered by
completed SDP exchange.
Now, for an application implemented in DSM state chart, there is
always an initial state, which the DSM engine jumps into when the call
is started. The question now is when this should be, finding a good
balance between simplicity, flexibility and correctness in the
representation of the actuall call model; we are actually not really
satisfied with the run_invite_event configuration and the
connect_session parameters work currently.
The simple solution would be to start the DSM in the initial state
when the session starts, i.e. in the onSessionStart handler. At that
time the INVITE is already replied with 200, and the session is
already set up and ready to do something with the call. This is what
is the default now with run_invite_event=no.
On the other hand, for more interesting call flows (B2B, checking DB
or another server first for e.g. a call profile of the incoming call),
the DSM script writer should have the opportunity to react in custom
way to e.g. INVITE. The proper solution would be to jump into the
initial state when the thread starts (onStart()), and then have
transitions for invite/sessionStart/... . The drawback being that this
makes the scripts for even simple applications look complicated, and
also the issue that in the beginning, not even the most basic selects
are valid (e.g. @remote_uri and @local_uri are set only when
processing the first message, which comes after onStart()).
Three more beautiful solutions came to our mind:
1. A DSM application .conf (or dsm.conf) key which sets which should
be the first event to be processed, e.g.
startup_event=sessionStart (or: start, invite)
2. An explicit statement in the script which sets the startup event, e.g.
#set_property(startup_event=sessionStart)
3. deciding on the name of the initial state:
If "initial state START", then start with onStart()
If "initial state INVITE" then start with onInvite()
else start with onSessionStart() ("simple mode").
Which one do you like best?
Stefan
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
