Hi,
SZOKOVACS Robert wrote:
On Thursday 15 April 2010, Stefan Sayer wrote:
Hi,
the threadpool is optional (compile time), so that doesn't need to be
a problem.
But I, too, wonder whethere it should be necessary to block in the
event handler; for example, if you think you need to block in
onInvite, you can most probably defer the processing to later, e.g.
call AmSession::onInvite and add to media processor later, when you
In this case, I can't even send an OK with sdp without consulting the 3rd
party server, because the ports and ip's will change. I'm not sure if SEMS
supports renegotiating those and if it does I certainly don't know how to do
it :)
you can also send a 100 from onInvite, and send the 200 with the SDP
later when you have got the port/IP. just save the request from
onInvite somewhere, and do what in DSM mod_dlg dlg.acceptInvite does;
or have a look at early_announce (you could just replace 183 with 200).
I think that's cleaner than letting the thread sleep, e.g. if
something happens in between (e.g. you receive CANCEL while waiting
for the 3rd party server), you can react properly.
Stefan
br
Szo
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
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
