Ringback tone

[David Wilkie]

Hi guys,

Before I post an issue / feature request on Adhearsion I just wanted to get your thoughts about a ringback tone. In FreeSwitch you can set  <action application="ring_ready" /> or <action application="set" data="ringback=%(2000,4000,440.0,480.0)"/> just before you bridge so my guess is that it would make sense to make this an option in the :dial command. According the the FreeSwitch wiki here: http://wiki.freeswitch.org/wiki/Custom_Ring_Back_Tones "Ringback will not be sent unless the variable is set *and* there's a ringing indication from the party that is being called. " so this should prevent a ringback being played when there is no actual ringing from the third party, but I'm not sure if Asterisk would support this or not.

Just incase i'm missing something obvious, when I try to dial out using the `dial` command or even just using FreeSwitch bridge I cannot hear anything until someone picks up the phone.

[David Wilkie]

Just a quick update on this, I assumed wrongly that you have to set <action application="ring_ready" /> in order to hear a ringback tone when bridging on FreeSwitch. I tried this again today without setting <action application="ring_ready" /> and I still heard the ringback tone when bridging. Therefore I think it's an issue with the way Adhearsion uses the originate command. I filed an issue here: https://github.com/adhearsion/adhearsion/issues/298

[Ben Langfeld]

So ring_ready won't work because we don't actually bridge directly (in order to handle confirmation controllers, though it's possible we might work in this optimisation when you don't want a confirmation controller). What we do is originate a new call, park it, and then bridge after the new call is answered.

Unfortunately I don't have a solution off the top of my head.

Regards,
Ben Langfeld

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adhearsion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Wilkie]

Hi Ben,

I was on the IRC channel today talking about this. So we were looking at the source code of Punchblock, and from the #dial command here https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L152 I can see it does an originate to park, which is where the problem lies as you said. We thought that we might be able to get around the problem by originating a new call, then calling #join, which looks like it does a uuid_bridge https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L196, but I guess that this is essentially the same because the first originate will park the call as well.

If the only reason to originate to park is to handle confirmation controllers, I might have a go at making a pull request that only performs this behaviour if a :confirm option is specified (https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L196), otherwise it will just perform the bridge without the park. I assume that this just means removing the & park() at the end of that originate command?

What do you think about that approach? I'm very new to Adhearsion and FreeSwitch but this might be a good way to get more involved.

Dave

[Ben Langfeld]

Dave,

It would indeed be awesome if you were willing/able to contribute such an optimisation. If you'd like to discuss it on IRC, I'm online during working hours in Brasil. I'll give a brief overview of things you'll need to consider:

1) The way you bridge in a FS dialplan is actually a combination of originating a new call, tying its lifecycle to the original call, and bridging them at the appropriate time. CallController#dial does some of this, but separates origination from bridging for flexibility.

2) Adhearsion speaks the Rayo protocol, and Punchblock translates this to FreeSWITCH EventSocket. The rayo protocol can be found at xmpp.org/extensions/inbox/rayo.html. Check out the sections on outbound calling, join (bridge) and specifically look at nested joins. These are the optimisation that combines origination and bridging.

3) Changes will have to be made to Punchblock to support nested joins on FreeSWITCH and Asterisk, and to Adhearsion to use a nested join when possible.

4) Here there be dragons. Expect blood.

Regards,
Ben Langfeld

[David Wilkie]

Hi Ben, thank for the info, I'm based in Cambodia so ill try to work out the tume difference and jump on irc when your there.

Can you possibly point out where, adhearsion finally Briges the call after originating then parking.

Also I'm slightly confused about the difference between originate and bridge in fs. I've done some googling and apparently they are the same thing except originate is used from a controlling client e.g. fs_cli but bridge is used in a dialplan. From my understanding from reading a bit about rayo, in a nested join you specify the target of the join, so in the fs case I think this just means removing the & park at the end of the originate.
Also I have no idea about Asterisk, but I can ways make an attempt at the rest  and maybe someone can help with that part.

[Ben Langfeld]

On 3 May 2013 15:31, David Wilkie <dwi...@gmail.com> wrote:

Hi Ben, thank for the info, I'm based in Cambodia so ill try to work out the tume difference and jump on irc when your there.

 Awesome

Can you possibly point out where, adhearsion finally Briges the call after originating then parking.

That would be here: https://github.com/adhearsion/adhearsion/blob/develop/lib/adhearsion/call_controller/dial.rb#L126 

Also I'm slightly confused about the difference between originate and bridge in fs. I've done some googling and apparently they are the same thing except originate is used from a controlling client e.g. fs_cli but bridge is used in a dialplan. From my understanding from reading a bit about rayo, in a nested join you specify the target of the join, so in the fs case I think this just means removing the & park at the end of the originate.

That sounds right. Thinking about it, though, this is not going to make any difference to the A leg, since the join is then simply performed automatically on answering the B leg, but you've not done anything to cause the A leg to send ringing. The solution to the ringback problem will be entirely separate, and should work with or without a nested join.

Ideally, a SIP 180 Ringing message will cause the remote party to generate their own ringback. We trigger that in the Adhearsion router when a route is selected (https://github.com/adhearsion/adhearsion/blob/develop/lib/adhearsion/router/route.rb#L37) and that gets translated to FS here: https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L178.

In cases where FS needs to generate ringback for the remote party, you can do SIP 183 Session Progress, which sets up one way audio (early media) and allows you to send ringing audio. You can do this either by playing back audio in your CallController (which is not a generic solution) or by modifying the implementation of Accept to execute ring_ready (http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_ring_ready).

You will have to make sure that your controller does not answer the call before doing CallController#dial.

See this relevant link also: http://wiki.freeswitch.org/wiki/180_vs._183_vs._Early_Media

Also I have no idea about Asterisk, but I can ways make an attempt at the rest  and maybe someone can help with that part.

Cool, I'm sure someone will. Bear in mind that this would block merging changes to Adhearsion, since we have to maintain support across all three platforms. 

[David Wilkie]

Hi Ben,

I've been doing some more tests with this today to try to figure out what exactly I need to do in Adhearsion / Punchblock to get B to send it's own ringback to leg A. As you said sending a SIP 180 will cause the remote party to generate their own ringback, however I couldn't get it to work.

After reading this article: http://blog.godson.in/2010/12/use-of-returnringready-originate.html, I tried removing the `return_ring_ready` option which is specified here: https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L139. As expected this waits for either a 183 or 200 before returning to park. My theory was that if return_ring_ready=true, then it will go to park as soon as the 180 is received and therefore leg A won't hear the ringback of B. Removing return_ring_ready didn't seem to have any affect on the ringback, however it did ensure that the correct status was set in the dial_status returned by the dial_command. My guess is that due to the return_ring_ready=true the dial_status will always return in_progress even if leg B doesn't pick up the call. I'm not sure if this is by design or not.

I also tried adding a the line "application 'respond', '180 Ringing'" just after this line https://github.com/adhearsion/punchblock/blob/develop/lib/punchblock/translator/freeswitch/call.rb#L152 in punchblock, which also didn't work.

Thoughts?

[Polysics]

Sorry to resurrect the thread, but was this ever resolved or turned into a Github issue?

I happen to have run into the same problem.

Thanks!

Luca

[David Wilkie]

Hey Luca,

Here's the relevant Github issues:

https://github.com/adhearsion/adhearsion/issues/298
https://github.com/adhearsion/punchblock/issues/146

I ended up just playing back a fake ringback tone, as the changes required in Adhearsion / Punchblock were are too difficult for me to fully comprehend at the moment

[Neeraj Nagi]

I am exactly looking for how to play a custom ringback until call is answered by b-party

[as...@asifskalam.com]

 

I'm fairly sure you can do this right now, but havn't tested it:
play! 'tt-monkeys', repeat_times: 100
Infinite repeat is allowed in the Rayo specification (-1) but is not currently implemented in Punchblock.
Regards,
Ben Langfeld

I learnt in the music on hold thread that you could use #play! with the repeat_times option to loop over an audio clip. I'm using this approach to simulate ringback, by looping a "ringing" sound clip while dialling the outbound call. #play! is async and returns the output component, which can later be stopped when the outbound call joins or hangs up.

Cheers,

Asif Kalam.

[Neeraj Nagi]

thanks , will try it out.

--
You received this message because you are subscribed to a topic in the Google Groups "Adhearsion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adhearsion/ppvcCZKcNU0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adhearsion+...@googlegroups.com.

[Neeraj Nagi]

worked perfectly, I did nothing to stop asynchronous play! . Somehow it exited with certain playback error, but end result is neat and clean moh. Thanks everyone, love this group