[asterisk-dev] [svn-commits] jrose: branch 1.8 r369750 - /branches/1.8/channels/chan_sip.c

[Jonathan Rose]

Kevin Fleming wrote:
> From: "Kevin P. Fleming" <kpfleming at digium.com>
> To: asterisk-dev at lists.digium.com
> Sent: Tuesday, July 10, 2012 11:05:53 AM
> Subject: Re: [asterisk-dev] [svn-commits] jrose: branch 1.8	r369750	-	/branches/1.8/channels/chan_sip.c
> 
> On 07/09/2012 09:31 AM, Jonathan Rose wrote:
> 
> > I agree handing receipt of an event but not having a way to send it
> > is
> > iffy, but since I'm not trying to change behavior in any meaningful
> > way
> > that just falls beyond the scope of what I was working on. It will
> > continue to be sent through audio once res is set to -1 I think.
> 
> There is no 'audio' equivalent of a flash-hook; 'flash' is not an
> audio
> event, it's a line event (and one of the reasons it was dropped in
> the
> move from RFC 2833 to RFC 4733, I think).

Hmmm, I guess changing the return code from sip_indicate to mirror what
it was before didn't really matter a whole lot then. I was thinking
about the documentation for sip_indicate() when I mentioned the audio
stuff.

/*! \brief Play indication to user
 * With SIP a lot of indications is sent as messages, letting the device play
   the indication - busy signal, congestion etc
   \return -1 to force ast_indicate to send indication in audio, 0 if SIP can handle the indication by sending a message
*/

I had inadvertently switched the return from -1 to 0... which is why I thought
that audio might have come into play. I guess not though.

--
Jonathan R. Rose
Digium, Inc. | Software Engineer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct +1 256 428 6139 

Check us out at: http://digium.com & http://asterisk.org