o Greg Doerr on 02/01/2012 05:28 PM:
Thanks Stefan.
I know this could be implemented as a DSM application. It could also be
implemented as a single C++ application as well. My preference is to achieve
as much functional separation in the code as possible. I'll probably stick
then use DSM. It allows you to separate nicely your code into reusable
and separately testable functions (actions/conditions). Also, your
audio processing code (if any) can be separated easily, and you
already get lots of the things that you otherwise need to do by hand
or with lots of boilerplate code (playlist, file object handling,
variables, inter-call events, monitoring, interfacing with RPC etc).
Further, it allows you to quickly do updates in the running server.
You don't need to do everything in the DSM script language (even if
that's a valid, and still pretty performant approach), it's already
very useful if you just use DSM to structure the pieces of C++ code.
with a single C++ application for now and then separate them once the 1.5
branch becomes stable.
One last question regarding support for WAV containers in 1.5. With the
current branch, WAV container handling is "broken" if the WAV contains the
audio data in non-contiguous chunks. While these files comply with the
standard, when they pare played in sems, there is an audible click when the
stream encounters the non-audio chunks. I can implement a fix but it would
likely mean changing the implementation of AmCachedAudioFile to no longer
use mmap and process the PCM stream into a buffer for playback. Would likely
I haven't thought it through in the details, but it seems to me that
the simplest solution would be in amci_inoutfmt_t a function to
return chunks (their byte indices indices) to read (or, to skip).
These could then be taken into account in both
AmCachedAudioFile/AmAudioFile. OTOH, it could be much more flexible to
really decouple the I/O from the file format, then also other means of
I/O could be used (I did this some time back with playing mp3 streams).
mean changes to the container plug-ins as well. If this is addressed in the
no problem with that.
master branch then I'll live with it. Thoughts?
It's unfoirtunately not adressed in master.
Great platform by the way. Very easy to understand and use.
thanks!
Stefan
Greg
-----Original Message-----
From: Stefan Sayer [mailto:[email protected]]
Sent: Wednesday, February 01, 2012 9:39 AM
To: Greg Doerr
Cc: [email protected]
Subject: Re: [Semsdev] Sems Session Transfer
Hello Greg,
o Greg Doerr on 02/01/2012 06:26 AM:
Greetings,
I am working on several sems applications and would like to know if
there is a (relatively) easy way to transfer a session between
applications within the same sems instance. I understand from reading
the lists that AmSipDialog:: transfer works to transfer between
instances (this is something I need to try) but it doesn't work
between applications on the same instance. When I try a transfer to
the same instance, I receive a 481 error Call leg/Transaction does not
exist.
there is no simple way (yet) to transfer one call between different
applications in sems. The simplest solution, in 1.4, is to use the
connectCallee function of the B2BUA, creating a looped call leg to the same
instance (over lo), or even to use AmB2ABSession for connecting legs on the
audio path internally.
There is in master (to be 1.5) branch quite some work to separate the actual
SIP dialog handling further out from the call/application logic processing,
there it will be relatively straightforward to do this, but we are not there
completely yet.
The AmSipDialog::transfer works by dropping and forgetting the call after it
was transferred away from this instance. In that case, this would break
processing of your new application I suppose.
What is the applications you are using? There is a very good possibility
that they can be rewritten and combined using DSM.
Stefan
I'm going to try parsing the call flow through
parse_sip_uri/handle_sip_request code but wanted to check if there was
an obvious answer.
I'm on the 1.4.2 branch.
Regards and Thanks,
Greg Doerr
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
tel:+491621366449
sip:[email protected]
mailto/xmpp:[email protected]
--
tel:+491621366449
sip:[email protected]
mailto/xmpp:[email protected]
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
