[asterisk-dev] MeetMe: Development Request (and Bounty)

[Olle E. Johansson]

7 mar 2011 kl. 23.08 skrev Kevin P. Fleming:

> On 03/07/2011 03:29 PM, Olle E. Johansson wrote:
>> 
>> 7 mar 2011 kl. 19.08 skrev Klaus Darilion:
>> 
>>> 
>>> 
>>> Am 07.03.2011 18:23, schrieb Nicholas Blasgen:
>>>> I'm looking for someone to patch MeetMe to support presence information on
>>>> the state of the phone line.  In short, a phone call with ringing out of
>>>> band is not heard on a MeetMe channel.  If you were to create
>>>> an extension similar to this:
>>>> 
>>>> 500,1,Answer()
>>>> 500,2,Dial(SIP/100)
>>>> 
>>>> And then originate a call between that extension and a meetme channel, there
>>>> would be silence heard on the meetme channel.  The desired outcome would be
>>>> to hear the ring, ring sound.  I've seen this "bug" brought up on Asterisk's
>>>> bug tracker but it seems that it's intended for some reason (due to MeetMe
>>>> not caring about the state of the phone line), but I would like to change
>>>> that.  We're all not a fan of added configuration flags, but if it's true
>>>> that this is an intended outcome, then I see no other suggestion than to add
>>>> a new flag.  So I'd propose adding a flag to the MeetMe configuration file
>>>> that allows the admin to configure whether MeetMe generattes sound for out
>>>> of band calls.
>>> 
>>> IMO it is not Meetme's task to generate a ringback tone. As the "bad
>>> thing" happens on the other side.
>>> 
>>> What about:
>>> 
>>> 500,1,Answer()
>>> 500,2,Dial(SIP/100,r)
>>> 
>>> or
>>> 
>>> 500,1,Answer()
>>> 500,2,PlayTones(ring)
>>> 500,3,Dial(SIP/100)
>>> 
>> What you're doing here is faking ringing, which is not what was needed...
>> One really needs to hear media, busy or ringback tone from the other end.
> 
> If the other end is not providing any, because they are using signaling instead of media to indicate call progress (or failure), then there isn't anything to hear.
If the channel is UP, Asterisk normally generates tones inband instead of sending control frames. In this case, we haven't got a normal bridge, so normal bridge rules might not apply ;-)

> 
> This could probably be addressed by modifying chan_local to have an option that causes it to turn signaling for call progress into audible indications, and then dialing out through chan_local instead of directly through the destination channel driver.
I suggested chan_local off-list :-)

/O