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 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 mean changes to the container plug-ins as well. If this is addressed in the master branch then I'll live with it. Thoughts? Great platform by the way. Very easy to understand and use. 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] _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
