David J. wrote: > Stefan, > > I had a similar question, we don't play ads to the caller, but we do > locate the callee while the caller is waiting or "on hold", so we could > use the B2BUA functionality. what does the desired call flow actually look like?
> > Is there an example available of this functionality in the SEMS examples? pre-call RBT is readily available (e.g. early_announce - early media then final reply or early media then B2BUA) or a simple DSM script (see e.g. early_media.dsm or test_b2b.dsm in doc/dsm/examples); also see http://ftp.iptel.org/pub/sems/doc/current/AppDoc.html Mixing destination RBT with announcement would need some hacking; though in webconference application something similar is done, early media from outgoing call mixed into conference, and you could add that code to b2b_connect application. If you want to get destination RBT to your media server, you need to send media server address in outgoing INVITE - which means after the call is established you relay RTP through your media server (at least until you do some reinvites do drop out of the call, which can be a little complex and does not necessarily work too well in all constellations). > > (Sorry to post a SEMS question on the OpenSIPs mailing list, I will > gladly post to SEMS list if one exists.) mailing lists are at http://lists.iptel.org/ (see http://iptel.org/sems). Regards Stefan > > > Thanks. > > > > On 5/18/10 1:41 PM, Stefan Sayer wrote: >> Hi Bogdan, >> >> Bogdan-Andrei Iancu wrote: >> >>> Hi Stefan, >>> >>> There is a built in functionality for this in OpenSIPS: see the >>> minor_branch_flag() >>> http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id271212 >>> >>> This can be used when you parallely fork a branch to a media server to >>> get media via 183 (like ring back tone), but you do not want the >>> transaction engine to wait for the completion of that branch (if all >>> other did end with negative answer). >>> Again this is mainly for parallel forking scenarios. >>> >> thanks for the pointer, thats interesting for RBT. It understood >> (possibly wrong) that the OP wanted to have his ads completed before >> the call continues. not that I would personally like it much to listen >> to long ads before the call, but if the ads are only played while its >> connecting/ringing, thats probably ok (for a free service). If I were >> the OP, I would send the call through SEMS B2BUA and mix the actual >> RBT audio from destination with the ad from DB, that way the caller >> knows what's happening with the call while listening to ad, and >> listens probably with much more attention. >> >> Regards >> Stefan >> >> >>> Regards, >>> Bogdan >>> >>> Stefan Sayer wrote: >>> >>>> Albert Paijmans wrote: >>>> >>>> >>>>> Hi Andreas, >>>>> >>>>> Thanks for the reply. The reason we do not want to use Asterisk, but >>>>> SEMS, is because SEMS offers the possibility to play a different >>>>> announcement (could be from database) to every extension. This ofcourse >>>>> makes it more attractive to our sponsors. We want to do both sponsor >>>>> messages for outgoing calls and we will have some discreet advertisement >>>>> on our website. We think we can offer free phonecalls to most >>>>> international destinations thanks to Open Source and we are all >>>>> volunteers :) >>>>> >>>>> So forwarding calls to Asterisk and using Asterisk as a media server for >>>>> voicemail or busy tones I understand that part. But how could I send >>>>> outgoing (pstn) calls to SEMS first and then to Asterisk? Is there >>>>> something like a service route for this? >>>>> >>>>> >>>> whether you are using SEMS or Asterisk for pre call/early media >>>> announcement, you would first send the call to the media server of >>>> your choice, have an announcement played with 183, then the media >>>> server replies with negative final reply, which you catch in your >>>> proxy and add as another branch the final destination (pstn/asterisk). >>>> >>>> alternatively, you can send the call to SEMS, have the announcement >>>> played there in early media, and then continue the call in B2BUA mode >>>> through SEMS (see ann_b2b application, you can modify that a little to >>>> use 183 instead of 200; or use a simple DSM script and connectCallee >>>> action). >>>> >>>> Regards >>>> Stefan >>>> >>>> >>>> >>>> >>>>> Thanks >>>>> >>>>> Albert >>>>> >>>>> >>>>> >>>>> On Sat, May 15, 2010 at 2:06 AM, Andreas Sikkema<[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> On May 14, 2010, at 11:13 PM, Albert Paijmans wrote: >>>>> >>>>> > Is it possible to add an extra announcement server in the call >>>>> path? >>>>> > So OpenSIPS acts as registrar/proxy, Asterisk does pstn, >>>>> voicemail etc. But on certain destinations the call is relayed >>>>> through an announcement server before continuing to Asterisk. >>>>> >>>>> I'd just use the existing Asterisk for it (providing it has a >>>>> reliable timing source) and have it play a wav file during "ringing >>>>> phase" and after the WAV file ends do the rest of the dialplan and >>>>> have the outgoing call answer the incoming call. >>>>> >>>>> This sudden influx of "let's do add before the call" business plans >>>>> of late really takes me back to my first VoIP operator job, they >>>>> just stopped doing that (in the Netherlands and Germany) because >>>>> there was no money around 2002 after the whole 9/11 thing when there >>>>> was an economic crisis and advertisers stopped advertising ;-) >>>>> >>>>> I must be getting old.... >>>>> >>>>> -- >>>>> Andreas >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected]<mailto:[email protected]> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> >>> >> > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Stefan Sayer VoIP Services Consulting and Development Warschauer Str. 24 10243 Berlin tel:+491621366449 sip:[email protected] email/xmpp:[email protected] _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
