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]
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
